Subject: Re: [paws] Question: Encode slopes?

From: <[email-masked]>
Date: Fri, 1 Nov 2013 14:50:19 +0000

Even if things are hard coded in firmware, an update to firmware could bring the product up-to-date with the changed rules. Of course, it might be more flexible to have that info delivered over paws, but the discussions on this list do not indicate any consensus on what and how to encode.
Most people resist to changing the current encoding in draft -06. Since we were not able to conclude this discussion in time and submit a revised version of the document before the deadline, we can keep continue discussing this encoding issue for a few more days, but I'd like to conclude it by the F2F. So far, no conclusion in changing the current encoding, and unless a miracle happens in the next few days, this will be the conclusion, as we need to move forward.
There will be a separate discussion sometime in the future on whether to create a paws version 2, and if yes, then what should be included in there. But before that discussion happens we need to get the current protocol out of the door.
-Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Andy Lee
Sent: Tuesday, October 29, 2013 1:51 PM
To: Peter Stanforth
Cc: [email-masked]
Subject: Re: [paws] Question: Encode slopes?

Hi Peter,

I think that channels 36 and 38 were merely being offered as examples, hence the "e.g.".  Perhaps it's a matter of interpretation, but it seems pretty clear to me that the purpose of this note is to allow the device under test (DUT) to use information from the database to meet compliance requirements, if it so chooses.  It is not forced to have those constraints hard-coded in the firmware.

This leaves open the possibility for the FCC to change, add, or remove the constrains around channel 37 in the future.  If a device chooses to have hard-coded constraints in their firmware, they may end up missing out on some spectrum opportunities that might be permitted in future rule modifications.

Best regards,

Andy Lee |

 Google Inc. |

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

 408-230-0522

On Tue, Oct 29, 2013 at 1:33 PM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
The note you reference in the test procedure is ambiguous, there is no reference to channels 36-38 in part two and no mention of tests to lock out unauthorized channels, or a definition of what that really means. So I can only base our interpretation on what we have been required to do to pass WSD certification. The FCC being the final judge of that. The way we have been required (By we I mean the DUT) to operate it that the DUT cannot have it's compliance overridden by the database. A specific example. A DUT was having trouble complying with the channel 37 requirement and the manufacturer made the decision to block any use of channels around it in the firmware - to get a product out and allow them to rework the RF later. A test was required to prove that if the database provided those blocked channels as options that the DUT would in fact not operate on them, in order to get FCC certification.
Further the requirement you reference is about permission to use a channel not OOB emissions. (15.709(c)(4) which is what I was referring to.

I still don't think defining the mask is a bad idea, though I think there are  better ways of doing it than we are talking about, but I do think this discussion belongs in a new version of PAWS where we can describe the requirements and define the behavior comprehensively. It is not required to support FCC or Ofcom management of WSDs. Which was the basis of the current PAWS requirements.

From: Andy Lee <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 29, 2013 at 4:07 PM
To: Peter Stanforth <[email-masked]<mailto:[email-masked]>>
Cc: Ray Bellis <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Subject: Re: [paws] Question: Encode slopes?

Hi Peter,

Thanks for the link.  The rules actually DO allow for these constraints to come from the database (and defer to Part 2 for testing).  The rules in Part 1 are as follows:

Best regards,

Andy Lee |

 Google Inc. |

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

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

On Tue, Oct 29, 2013 at 12:02 PM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
Andy
The statement "White space devices must comply one way or another" is inconsistent with the testing process we have been required to use to get FCC certification (5 WSDs so far), and I suggest that you cannot currently certify a device that does not have the conformance encoded in the firmware. Specifically: In order to certify a White Space Device the device must be certified against the FCC test process (https://apps.fcc.gov/kdb/GetAttachment.html?id=Rnszbl7%2BTh%2FUqEwk%2FztsOQ%3D%3D   ), which consists of two independent parts.  Part 1: Radio Frequency (RF) Certification Tests,  tests the RF characteristics independent of the database, and includes conformance with channel 37 limits (iv. Measurements in the 602-620 MHz band ( TV channels 36-38)) - which means the behavior has to be encoded in the device.
It is only after they have completed the Part 1 test that they run the Part 2 test: Database Interface Certification Tests, which is to validate the behavior of the radio with the database.
So to permit constraints to be managed by a WSDB, as you suggest, would require changes to the current TCB process defined by the FCC.
Peter S.

From: Andy Lee <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 29, 2013 at 2:23 PM
To: Ray Bellis <[email-masked]<mailto:[email-masked]>>

Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Question: Encode slopes?

Hi,

A couple of comments:

  *   The constraints on channels 36 and 38 are part of the current FCC rules.  White space devices must comply with this requirement one way or another, whether this information comes from the database or if it's somehow encoded into the device firmware.  The FCC allows for either kind of implementation, and PAWS should be supportive of this.
  *   PAWS is not limited to the FCC or the TV band.  We want to be cognizant of emerging rules in other jurisdictions, in other bands, and with the current state of radio technologies.  This is (hopefully) an international standard that is not bound to any one country's rules or any one company's implementation.
  *   All else being equal, why not choose an encoding that is a better match for all currently known rules and radio technologies?

Respectfully,

Andy Lee |

 Google Inc. |

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

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

On Tue, Oct 29, 2013 at 9:57 AM, Ray Bellis <[email-masked]<mailto:[email-masked]>> wrote:

On 29 Oct 2013, at 15:57, Vincent Chen <[email-masked]<mailto:[email-masked]>> wrote:

> Just to make it more concrete, I've included the proposed change to the text and examples:
I do NOT support this change.  All of the observations I made in my message of 9th October still apply.

The only potentially valid use case I've seen for non-zero slopes are the FCC limits for channels 36 and 38, and we've heard from Spectrum Bridge that this isn't an issue.

Ray

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

---

From: Andy Lee <[email-masked]>
Date: Fri, 1 Nov 2013 13:17:17 -0700

What and how to encode is already defined in the FCC rules (the values have
been referenced in previous messages).  The values are explicitly given to
us, and we just need a way to include it in a PAWS message.

The current encoding does not support the encoding of those values
(including slopes).  A new encoding has been proposed that does support the
FCC parameters.

What is the justification for sticking with the less capable encoding?  The
old encoding is incapable of supporting a use case that's been identified
in the current rules.

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

On Fri, Nov 1, 2013 at 7:50 AM, <[email-masked]> wrote:

>  Even if things are hard coded in firmware, an update to firmware could
> bring the product up-to-date with the changed rules. Of course, it might be
> more flexible to have that info delivered over paws, but the discussions on
> this list do not indicate any consensus on what and how to encode.
>
> Most people resist to changing the current encoding in draft -06. Since we
> were not able to conclude this discussion in time and submit a revised
> version of the document before the deadline, we can keep continue
> discussing this encoding issue for a few more days, but I’d like to
> conclude it by the F2F. So far, no conclusion in changing the current
> encoding, and unless a miracle happens in the next few days, this will be
> the conclusion, as we need to move forward.
>
> There will be a separate discussion sometime in the future on whether to
> create a paws version 2, and if yes, then what should be included in there.
> But before that discussion happens we need to get the current protocol out
> of the door.
>
> -Gabor
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Andy Lee
> *Sent:* Tuesday, October 29, 2013 1:51 PM
> *To:* Peter Stanforth
> *Cc:* [email-masked]
>
> *Subject:* Re: [paws] Question: Encode slopes?
>
>
>
> Hi Peter,
>
>
>
> I think that channels 36 and 38 were merely being offered as examples,
> hence the "e.g.".  Perhaps it's a matter of interpretation, but it seems
> pretty clear to me that the purpose of this note is to allow the device
> under test (DUT) to use information from the database to meet compliance
> requirements, if it so chooses.  It is not forced to have those constraints
> hard-coded in the firmware.
>
>
>
> This leaves open the possibility for the FCC to change, add, or remove the
> constrains around channel 37 in the future.  If a device chooses to have
> hard-coded constraints in their firmware, they may end up missing out on
> some spectrum opportunities that might be permitted in future rule
> modifications.
>
>
>
> Best regards,
>
>
>
>
> Andy Lee |
>
>  Google Inc. |
>
>  [email-masked] |
>
>  408-230-0522
>
>
>
> On Tue, Oct 29, 2013 at 1:33 PM, Peter Stanforth <[email-masked]>
> wrote:
>
> The note you reference in the test procedure is ambiguous, there is no
> reference to channels 36-38 in part two and no mention of tests to lock out
> unauthorized channels, or a definition of what that really means. So I can
> only base our interpretation on what we have been required to do to pass
> WSD certification. The FCC being the final judge of that. The way we have
> been required (By we I mean the DUT) to operate it that the DUT cannot have
> it’s compliance overridden by the database. A specific example. A DUT was
> having trouble complying with the channel 37 requirement and the
> manufacturer made the decision to block any use of channels around it in
> the firmware – to get a product out and allow them to rework the RF later.
> A test was required to prove that if the database provided those blocked
> channels as options that the DUT would in fact not operate on them, in
> order to get FCC certification.
>
> Further the requirement you reference is about permission to use a channel
> not OOB emissions. (15.709(c)(4) which is what I was referring to.
>
>
>
> I still don’t think defining the mask is a bad idea, though I think there
> are  better ways of doing it than we are talking about, but I do think this
> discussion belongs in a new version of PAWS where we can describe the
> requirements and define the behavior comprehensively. It is not required to
> support FCC or Ofcom management of WSDs. Which was the basis of the current
> PAWS requirements.
>
>
>
>
>
> *From: *Andy Lee <[email-masked]>
> *Date: *Tuesday, October 29, 2013 at 4:07 PM
> *To: *Peter Stanforth <[email-masked]>
> *Cc: *Ray Bellis <[email-masked]>, "[email-masked]" <
> [email-masked]>
>
>
> *Subject: *Re: [paws] Question: Encode slopes?
>
>
>
> Hi Peter,
>
>
>
> Thanks for the link.  The rules actually DO allow for these constraints to
> come from the database (and defer to Part 2 for testing).  The rules in
> Part 1 are as follows:
>
>
>
>
>
>
> Best regards,
>
>
>
>
> Andy Lee |
>
>  Google Inc. |
>
>  [email-masked] |
>
>  408-230-0522
>
>
>
> On Tue, Oct 29, 2013 at 12:02 PM, Peter Stanforth <
> [email-masked]> wrote:
>
> Andy
>
> The statement “White space devices must comply one way or another” is
> inconsistent with the testing process we have been required to use to get
> FCC certification (5 WSDs so far), and I suggest that you cannot currently
> certify a device that does not have the conformance encoded in the
> firmware. Specifically: In order to certify a White Space Device the device
> must be certified against the FCC test process (
> https://apps.fcc.gov/kdb/GetAttachment.html?id=Rnszbl7%2BTh%2FUqEwk%2FztsOQ%3D%3D
>  ), which consists of two independent parts.  Part 1: Radio Frequency (RF)
> Certification Tests,  tests the RF characteristics independent of the
> database, and includes conformance with channel 37 limits (iv. Measurements
> in the 602-620 MHz band ( TV channels 36-38)) - which means the behavior
> has to be encoded in the device.
>
> It is only after they have completed the Part 1 test that they run the
> Part 2 test: Database Interface Certification Tests, which is to validate
> the behavior of the radio with the database.
>
> So to permit constraints to be managed by a WSDB, as you suggest, would
> require changes to the current TCB process defined by the FCC.
>
> Peter S.
>
>
>
> *From: *Andy Lee <[email-masked]>
> *Date: *Tuesday, October 29, 2013 at 2:23 PM
> *To: *Ray Bellis <[email-masked]>
>
>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [paws] Question: Encode slopes?
>
>
>
> Hi,
>
>
>
> A couple of comments:
>
>    - The constraints on channels 36 and 38 are part of the current FCC
>    rules.  White space devices must comply with this requirement one way or
>    another, whether this information comes from the database or if it's
>    somehow encoded into the device firmware.  The FCC allows for either kind
>    of implementation, and PAWS should be supportive of this.
>    - PAWS is not limited to the FCC or the TV band.  We want to be
>    cognizant of emerging rules in other jurisdictions, in other bands, and
>    with the current state of radio technologies.  This is (hopefully) an
>    international standard that is not bound to any one country's rules or any
>    one company's implementation.
>    - All else being equal, why not choose an encoding that is a better
>    match for all currently known rules and radio technologies?
>
>
>
> Respectfully,
>
>
>
>
> Andy Lee |
>
>  Google Inc. |
>
>  [email-masked] |
>
>  408-230-0522
>
>
>
> On Tue, Oct 29, 2013 at 9:57 AM, Ray Bellis <[email-masked]>
> wrote:
>
>
> On 29 Oct 2013, at 15:57, Vincent Chen <[email-masked]> wrote:
>
> The only potentially valid use case I've seen for non-zero slopes are the
> FCC limits for channels 36 and 38, and we've heard from Spectrum Bridge
> that this isn't an issue.
>
>
> Ray
>
> [email-masked]

---

From: Peter Stanforth <[email-masked]>
Date: Fri, 1 Nov 2013 16:24:55 -0400

The FCC does not require the DB to provide any mask information. That can be validated by the 5 certified radios that are not getting anything but a channel list from a certified database.
I am still not convinced that, under current FCC rules, they will accept anything but a channel list.  I don’t think they will object to a DB providing such information but they certainly do not require it.

From: Andy Lee <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 1, 2013 at 4:17 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Peter Stanforth <[email-masked]<mailto:[email-masked]>>, Protocol to Access White Space database <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Question: Encode slopes?

What and how to encode is already defined in the FCC rules (the values have been referenced in previous messages).  The values are explicitly given to us, and we just need a way to include it in a PAWS message.

The current encoding does not support the encoding of those values (including slopes).  A new encoding has been proposed that does support the FCC parameters.

What is the justification for sticking with the less capable encoding?  The old encoding is incapable of supporting a use case that's been identified in the current rules.

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

On Fri, Nov 1, 2013 at 7:50 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Even if things are hard coded in firmware, an update to firmware could bring the product up-to-date with the changed rules. Of course, it might be more flexible to have that info delivered over paws, but the discussions on this list do not indicate any consensus on what and how to encode.
Most people resist to changing the current encoding in draft -06. Since we were not able to conclude this discussion in time and submit a revised version of the document before the deadline, we can keep continue discussing this encoding issue for a few more days, but I’d like to conclude it by the F2F. So far, no conclusion in changing the current encoding, and unless a miracle happens in the next few days, this will be the conclusion, as we need to move forward.
There will be a separate discussion sometime in the future on whether to create a paws version 2, and if yes, then what should be included in there. But before that discussion happens we need to get the current protocol out of the door.
-Gabor

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Andy Lee
Sent: Tuesday, October 29, 2013 1:51 PM
To: Peter Stanforth
Cc: [email-masked]<mailto:[email-masked]>

Hi Peter,

Best regards,

Andy Lee |

 Google Inc. |

On Tue, Oct 29, 2013 at 1:33 PM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
The note you reference in the test procedure is ambiguous, there is no reference to channels 36-38 in part two and no mention of tests to lock out unauthorized channels, or a definition of what that really means. So I can only base our interpretation on what we have been required to do to pass WSD certification. The FCC being the final judge of that. The way we have been required (By we I mean the DUT) to operate it that the DUT cannot have it’s compliance overridden by the database. A specific example. A DUT was having trouble complying with the channel 37 requirement and the manufacturer made the decision to block any use of channels around it in the firmware – to get a product out and allow them to rework the RF later. A test was required to prove that if the database provided those blocked channels as options that the DUT would in fact not operate on them, in order to get FCC certification.
Further the requirement you reference is about permission to use a channel not OOB emissions. (15.709(c)(4) which is what I was referring to.

I still don’t think defining the mask is a bad idea, though I think there are  better ways of doing it than we are talking about, but I do think this discussion belongs in a new version of PAWS where we can describe the requirements and define the behavior comprehensively. It is not required to support FCC or Ofcom management of WSDs. Which was the basis of the current PAWS requirements.

Hi Peter,

Best regards,

Andy Lee |

 Google Inc. |

On Tue, Oct 29, 2013 at 12:02 PM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
Andy
The statement “White space devices must comply one way or another” is inconsistent with the testing process we have been required to use to get FCC certification (5 WSDs so far), and I suggest that you cannot currently certify a device that does not have the conformance encoded in the firmware. Specifically: In order to certify a White Space Device the device must be certified against the FCC test process (https://apps.fcc.gov/kdb/GetAttachment.html?id=Rnszbl7%2BTh%2FUqEwk%2FztsOQ%3D%3D   ), which consists of two independent parts.  Part 1: Radio Frequency (RF) Certification Tests,  tests the RF characteristics independent of the database, and includes conformance with channel 37 limits (iv. Measurements in the 602-620 MHz band ( TV channels 36-38)) - which means the behavior has to be encoded in the device.
It is only after they have completed the Part 1 test that they run the Part 2 test: Database Interface Certification Tests, which is to validate the behavior of the radio with the database.
So to permit constraints to be managed by a WSDB, as you suggest, would require changes to the current TCB process defined by the FCC.
Peter S.

Hi,

A couple of comments:

Respectfully,

Andy Lee |

 Google Inc. |

Ray

---

From: Andy Lee <[email-masked]>
Date: Fri, 1 Nov 2013 13:46:22 -0700

Most (perhaps all) of the device and database certifications that have been
completed thus far have used proprietary interfaces.  They have not relied
on a *draft* PAWS specification.  And there are other certified devices
which do get more than just a channel list.

We're not aiming for the least common denominator here.  There are many use
cases that could take advantage of this information.  Just because there is
one implementation that doesn't use this feature, that doesn't mean the
protocol shouldn't support it.  The FCC's testing rules clearly indicate
that it is OK for a device to rely on information from the database to meet
compliance.  Just because one company decides not to make use of this
capability does not mean that others will come to the same conclusion.  And
the PAWS protocol should accommodate both.

The protocol is already not about "channels", which is a good thing, since
this is picking up steam internationally.  There is also substantial work
being done in other bands that are leaning towards spectrum databases and
PAWS.  Some of these other bands have no concept of channels at all.

What's the justification for the old, less capable encoding?  The old
encoding does not follow any of the common practices used in the radio
device industries.  I think we should strongly consider following the lead
of IEEE 802.11 and other technologies that will be the most likely users of
white space.

On Fri, Nov 1, 2013 at 1:24 PM, Peter Stanforth <[email-masked]>wrote:

> The FCC does not require the DB to provide any mask information. That can
> be validated by the 5 certified radios that are not getting anything but a
> channel list from a certified database.
> I am still not convinced that, under current FCC rules, they will accept
> anything but a channel list.  I don’t think they will object to a DB
> providing such information but they certainly do not require it.
>
> From: Andy Lee <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: Peter Stanforth <[email-masked]>, Protocol to Access White
> Space database <[email-masked]>
>
> What and how to encode is already defined in the FCC rules (the values
> have been referenced in previous messages).  The values are explicitly
> given to us, and we just need a way to include it in a PAWS message.
>
> What is the justification for sticking with the less capable encoding?
>  The old encoding is incapable of supporting a use case that's been
> identified in the current rules.
>
>
>> Most people resist to changing the current encoding in draft -06. Since
>> we were not able to conclude this discussion in time and submit a revised
>> *From:[email-masked] [mailto:[email-masked]] *On Behalf
>> Of *ext Andy Lee
>> This leaves open the possibility for the FCC to change, add, or remove
>> the constrains around channel 37 in the future.  If a device chooses to
>> have hard-coded constraints in their firmware, they may end up missing out
>> on some spectrum opportunities that might be permitted in future rule
>> modifications.
>>
>>
>>
>> Best regards,
>>
>>
>>
>>
>> Andy Lee |
>>
>>  Google Inc. |
>>
>>  [email-masked] |
>>
>>  408-230-0522
>>
>>
>>
>> On Tue, Oct 29, 2013 at 1:33 PM, Peter Stanforth <
>> Further the requirement you reference is about permission to use a
>> channel not OOB emissions. (15.709(c)(4) which is what I was referring to.
>>
>>
>>
>> Thanks for the link.  The rules actually DO allow for these constraints
>> to come from the database (and defer to Part 2 for testing).  The rules in
>> Part 1 are as follows:
>>
>>
>>
>>
>>
>>
>> Best regards,
>>
>>
>>
>>
>> Andy Lee |
>>
>>  Google Inc. |
>>
>>  [email-masked] |
>>
>>  408-230-0522
>>
>>
>>

---

From: Peter Stanforth <[email-masked]>
Date: Fri, 1 Nov 2013 17:45:29 -0400

With all due respect you are not listing to what I am saying.
1 I agree that providing more flexible API and more information is what we should aim for with PAWS.
2 You were implying, incorrectly, that the current V6 PAWS protocol could not support the FCC rules, It can and does. We have implemented this protocol. I am not sure why that is ‘proprietary'.
3 my only issue is that this is not fully thought out and we also need to get a PAWS protocol out the door. So I am trying to put this capability into a future iteration so we can do it justice.

From: Andy Lee <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 1, 2013 at 4:46 PM
To: Peter Stanforth <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Protocol to Access White Space database <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Question: Encode slopes?

Most (perhaps all) of the device and database certifications that have been completed thus far have used proprietary interfaces.  They have not relied on a *draft* PAWS specification.  And there are other certified devices which do get more than just a channel list.

We're not aiming for the least common denominator here.  There are many use cases that could take advantage of this information.  Just because there is one implementation that doesn't use this feature, that doesn't mean the protocol shouldn't support it.  The FCC's testing rules clearly indicate that it is OK for a device to rely on information from the database to meet compliance.  Just because one company decides not to make use of this capability does not mean that others will come to the same conclusion.  And the PAWS protocol should accommodate both.

The protocol is already not about "channels", which is a good thing, since this is picking up steam internationally.  There is also substantial work being done in other bands that are leaning towards spectrum databases and PAWS.  Some of these other bands have no concept of channels at all.

What's the justification for the old, less capable encoding?  The old encoding does not follow any of the common practices used in the radio device industries.  I think we should strongly consider following the lead of IEEE 802.11 and other technologies that will be the most likely users of white space.

On Fri, Nov 1, 2013 at 1:24 PM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
The FCC does not require the DB to provide any mask information. That can be validated by the 5 certified radios that are not getting anything but a channel list from a certified database.
I am still not convinced that, under current FCC rules, they will accept anything but a channel list.  I don’t think they will object to a DB providing such information but they certainly do not require it.

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

Hi Peter,

Best regards,

Andy Lee |

 Google Inc. |

Hi Peter,

Best regards,

Andy Lee |

 Google Inc. |

Hi,

A couple of comments:

Respectfully,

Andy Lee |

 Google Inc. |

Ray

---

From: Nancy Bravin <[email-masked]>
Date: Fri, 1 Nov 2013 15:02:36 -0700

I have a couple of concerns.
1. why have we not submitted option 2 months ago
2. In that we have the ability to revise every 6 months which is not something most other SDO’s can do, there is no reason to try and
have other things in there in one FINAL and ONLY PAWS protocol which I seem to be seeing some want to do and therefore add things now
when in fact, we can adapt easily and make changes, work with other groups, and keep up to date with the different requirements likely to change.

Sincerely, Nancy 
On Nov 1, 2013, at 2:45 PM, Peter Stanforth <[email-masked]> wrote:

> To: Peter Stanforth <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Protocol to Access White Space database <[email-masked]>
> On Fri, Nov 1, 2013 at 1:24 PM, Peter Stanforth <[email-masked]> wrote:
>> Cc: Peter Stanforth <[email-masked]>, Protocol to Access White Space database <[email-masked]>
>> 
>>> From:[email-masked] [mailto:[email-masked]] On Behalf Of ext Andy Lee
>>> On Tue, Oct 29, 2013 at 1:33 PM, Peter Stanforth <[email-masked]> wrote:
>>> To: Peter Stanforth <[email-masked]>
>>> Cc: Ray Bellis <[email-masked]>, "[email-masked]" <[email-masked]>
>>> 
>>> On Tue, Oct 29, 2013 at 12:02 PM, Peter Stanforth <[email-masked]> wrote:
>>> Andy 
>>> To: Ray Bellis <[email-masked]>
>>> 
>>> Cc: "[email-masked]" <[email-masked]>
>>> The constraints on channels 36 and 38 are part of the current FCC rules.  White space devices must comply with this requirement one way or another, whether this information comes from the database or if it's somehow encoded into the device firmware.  The FCC allows for either kind of implementation, and PAWS should be supportive of this.
>>> PAWS is not limited to the FCC or the TV band.  We want to be cognizant of emerging rules in other jurisdictions, in other bands, and with the current state of radio technologies.  This is (hopefully) an international standard that is not bound to any one country's rules or any one company's implementation.
>>> All else being equal, why not choose an encoding that is a better match for all currently known rules and radio technologies?
>>>  
>>> Respectfully,
>>> 
>>>  
>>> Andy Lee |
>>>  Google Inc. |
>>>  [email-masked] |
>>>  408-230-0522
>>>  
>>> 
>>> On Tue, Oct 29, 2013 at 9:57 AM, Ray Bellis <[email-masked]> wrote:
>>>

---

From: Nancy Bravin <[email-masked]>
Date: Fri, 1 Nov 2013 15:10:11 -0700

Sorry, meant to send to Andy, Gabor and the group as well.

---

From: Andy Lee <[email-masked]>
Date: Fri, 1 Nov 2013 15:12:21 -0700

Thanks, Peter.

You were implying, incorrectly, that the current V6 PAWS protocol could not
> support the FCC rules, It can and does. We have implemented this protocol.
> I am not sure why that is ‘proprietary'.

I am only saying that most, if not all, of the devices that are already
certified by the FCC were certified prior to the existence of PAWS draft
06.  At the time of their certification, they were not using PAWS.  Perhaps
"proprietary" was a poor choice of words, but the certified devices have
not been based on a protocol that is common across multiple database
providers.

my only issue is that this is not fully thought out and we also need to get
> a PAWS protocol out the door. So I am trying to put this capability into a
> future iteration so we can do it justice.

The spectrum profile ideas have been thought out quite a bit, perhaps even
more so than the version 06 encoding.  The 06 encoding is distinctly
different than what is commonly used elsewhere in the industry and device
emissions control.

On Fri, Nov 1, 2013 at 2:45 PM, Peter Stanforth <[email-masked]>wrote:

> 2 You were implying, incorrectly, that the current V6 PAWS protocol could
> not support the FCC rules, It can and does. We have implemented this
> protocol. I am not sure why that is ‘proprietary'.
> 3 my only issue is that this is not fully thought out and we also need to
> get a PAWS protocol out the door. So I am trying to put this capability
> into a future iteration so we can do it justice.
>
>
> Most (perhaps all) of the device and database certifications that have
> been completed thus far have used proprietary interfaces.  They have not
> relied on a *draft* PAWS specification.  And there are other certified
> devices which do get more than just a channel list.
>
> We're not aiming for the least common denominator here.  There are many
> use cases that could take advantage of this information.  Just because
> there is one implementation that doesn't use this feature, that doesn't
> mean the protocol shouldn't support it.  The FCC's testing rules clearly
> indicate that it is OK for a device to rely on information from the
> database to meet compliance.  Just because one company decides not to make
> use of this capability does not mean that others will come to the same
> conclusion.  And the PAWS protocol should accommodate both.
>
>>> I still don’t think defining the mask is a bad idea, though I think
>>> there are  better ways of doing it than we are talking about, but I do
>>> think this discussion belongs in a new version of PAWS where we can
>>> describe the requirements and define the behavior comprehensively. It is
>>> not required to support FCC or Ofcom management of WSDs. Which was the
>>> basis of the current PAWS requirements.
>>>
>>>
>>>
>>>
>>>
>>> The only potentially valid use case I've seen for non-zero slopes are
>>> the FCC limits for channels 36 and 38, and we've heard from Spectrum Bridge

---

From: Andy Lee <[email-masked]>
Date: Fri, 1 Nov 2013 15:21:11 -0700

Thanks, Nancy,

why have we not submitted option 2 months ago

Just for reference, this topic surfaced as early as August 25 in this
thread: http://www.ietf.org/mail-archive/web/paws/current/msg01607.html

In fact, is was agreed at the prior F2F meeting that option 2 was the more
general (and preferable) encoding.

Best regards,

On Fri, Nov 1, 2013 at 3:10 PM, Nancy Bravin <[email-masked]> wrote:

> 2. In that we have the ability to revise every 6 months which is not
> something most other SDO’s can do, there is no reason to try and
> have other things in there in one FINAL and ONLY PAWS protocol which I
> seem to be seeing some want to do and therefore add things now
> when in fact, we can adapt easily and make changes, work with other
> groups, and keep up to date with the different requirements likely to
> change.
>
> Sincerely, Nancy

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Fri, 1 Nov 2013 17:18:35 -0700

With all due respect to Andy, previous messages on this list have 
touched on only some of the requirements in the current FCC regs that 
affect the emissions profile a TVBD must comply with.  I gave a fairly 
long list, but I also stated that it was not exhaustive as I stated.

In my opinion, the additional information encoded via the "mask" does 
not provide the capability that Andy appears to be advocating (and which 
quite a few people seem to be suppoting, including me). This extended 
"mask" encoding does not, IMO, provide enough to be of any greater use 
than what is in the draft.

So I recommend moving forward with the simple encoding in the draft 
which will support TVBD deployment where it is currently possible.

I further recommend the group move forward in developing the additional 
protocol elements in PAWS to support the dynamic speification of 
transmission characteristics  I also suggest that, as we now know IEEE 
P1900.5 is in the process of developing a data model for supporting the 
kind of adaptive process we seem to be talking about, that PAWS could 
benefit from that work as a starting point.  I don't know the proper 
process for establishing a working relationship between this group and 
another SDO, but I do know the chair of  IEEE 1900.5 who has said he'd 
be happy to work with PAWS:   [email-masked]

Hope that helps
B

On 11/1/2013 1:17 PM, Andy Lee wrote:
> (including slopes).  A new encoding has been proposed that does 
> support the FCC parameters.
>
> Andy Lee | 	 Google Inc. | 	[email-masked] 
> <mailto:[email-masked]> | 	 408-230-0522
>
>
>
>     Even if things are hard coded in firmware, an update to firmware
>     could bring the product up-to-date with the changed rules. Of
>     course, it might be more flexible to have that info delivered over
>     paws, but the discussions on this list do not indicate any
>     consensus on what and how to encode.
>
>     Most people resist to changing the current encoding in draft -06.
>     Since we were not able to conclude this discussion in time and
>     submit a revised version of the document before the deadline, we
>     can keep continue discussing this encoding issue for a few more
>     days, but I'd like to conclude it by the F2F. So far, no
>     conclusion in changing the current encoding, and unless a miracle
>     happens in the next few days, this will be the conclusion, as we
>     need to move forward.
>
>     There will be a separate discussion sometime in the future on
>     whether to create a paws version 2, and if yes, then what should
>     be included in there. But before that discussion happens we need
>     to get the current protocol out of the door.
>
>     -Gabor
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On
>     Behalf Of *ext Andy Lee
>     *Cc:* [email-masked] <mailto:[email-masked]>
>
>
>     I think that channels 36 and 38 were merely being offered as
>     examples, hence the "e.g.".  Perhaps it's a matter of
>     interpretation, but it seems pretty clear to me that the purpose
>     of this note is to allow the device under test (DUT) to use
>     information from the database to meet compliance requirements, if
>     it so chooses.  It is not forced to have those constraints
>     This leaves open the possibility for the FCC to change, add, or
>     remove the constrains around channel 37 in the future.  If a
>     device chooses to have hard-coded constraints in their firmware,
>     they may end up missing out on some spectrum opportunities that
>     might be permitted in future rule modifications.
>
>     Best regards,
>
>
>     Andy Lee |
>
>     	
>
>      Google Inc. |
>
>     	
>
>     [email-masked] <mailto:[email-masked]> |
>
>     	
>
>     408-230-0522 <tel:408-230-0522>
>
>     On Tue, Oct 29, 2013 at 1:33 PM, Peter Stanforth
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     The note you reference in the test procedure is ambiguous, there
>     is no reference to channels 36-38 in part two and no mention of
>     tests to lock out unauthorized channels, or a definition of what
>     that really means. So I can only base our interpretation on what
>     we have been required to do to pass WSD certification. The FCC
>     being the final judge of that. The way we have been required (By
>     we I mean the DUT) to operate it that the DUT cannot have it's
>     compliance overridden by the database. A specific example. A DUT
>     was having trouble complying with the channel 37 requirement and
>     the manufacturer made the decision to block any use of channels
>     around it in the firmware -- to get a product out and allow them
>     to rework the RF later. A test was required to prove that if the
>     database provided those blocked channels as options that the DUT
>     would in fact not operate on them, in order to get FCC certification.
>
>     I still don't think defining the mask is a bad idea, though I
>     think there are  better ways of doing it than we are talking
>     about, but I do think this discussion belongs in a new version of
>     PAWS where we can describe the requirements and define the
>     behavior comprehensively. It is not required to support FCC or
>     Ofcom management of WSDs. Which was the basis of the current PAWS
>     requirements.
>
>     *From: *Andy Lee <[email-masked] <mailto:[email-masked]>>
>     *To: *Peter Stanforth <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc: *Ray Bellis <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>
>
>     Thanks for the link.  The rules actually DO allow for these
>     constraints to come from the database (and defer to Part 2 for
>     testing).  The rules in Part 1 are as follows:
>
>     Inline image 1
>
>     Best regards,
>
>
>     Andy Lee |
>
>     	
>
>      Google Inc. |
>
>     	
>
>     [email-masked] <mailto:[email-masked]> |
>
>     	
>
>     408-230-0522 <tel:408-230-0522>
>
>     On Tue, Oct 29, 2013 at 12:02 PM, Peter Stanforth
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Andy
>
>     The statement "White space devices must comply one way or another"
>     is inconsistent with the testing process we have been required to
>     use to get FCC certification (5 WSDs so far), and I suggest that
>     you cannot currently certify a device that does not have the
>     conformance encoded in the firmware. Specifically: In order to
>     certify a White Space Device the device must be certified against
>     the FCC test process
>     (https://apps.fcc.gov/kdb/GetAttachment.html?id=Rnszbl7%2BTh%2FUqEwk%2FztsOQ%3D%3D
>      ), which consists of two independent parts.  Part 1: Radio
>     Frequency (RF) Certification Tests,  tests the RF characteristics
>     independent of the database, and includes conformance with channel
>     37 limits (iv. Measurements in the 602-620 MHz band ( TV channels
>     36-38)) - which means the behavior has to be encoded in the device.
>
>     It is only after they have completed the Part 1 test that they run
>     the Part 2 test: Database Interface Certification Tests, which is
>     to validate the behavior of the radio with the database.
>
>     So to permit constraints to be managed by a WSDB, as you suggest,
>     would require changes to the current TCB process defined by the FCC.
>
>     Peter S.
>
>     *From: *Andy Lee <[email-masked] <mailto:[email-masked]>>
>     *To: *Ray Bellis <[email-masked]
>     <mailto:[email-masked]>>
>
>
>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>       * The constraints on channels 36 and 38 are part of the current
>         FCC rules.  White space devices must comply with this
>         requirement one way or another, whether this information comes
>         from the database or if it's somehow encoded into the device
>         firmware.  The FCC allows for either kind of implementation,
>         and PAWS should be supportive of this.
>       * PAWS is not limited to the FCC or the TV band.  We want to be
>         cognizant of emerging rules in other jurisdictions, in other
>         bands, and with the current state of radio technologies.  This
>         is (hopefully) an international standard that is not bound to
>         any one country's rules or any one company's implementation.
>       * All else being equal, why not choose an encoding that is a
>         better match for all currently known rules and radio technologies?
>
>     Respectfully,
>
>
>     Andy Lee |
>
>     	
>
>      Google Inc. |
>
>     	
>
>     [email-masked] <mailto:[email-masked]> |
>
>     	
>
>     408-230-0522 <tel:408-230-0522>
>
>     On Tue, Oct 29, 2013 at 9:57 AM, Ray Bellis
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     The only potentially valid use case I've seen for non-zero slopes
>     are the FCC limits for channels 36 and 38, and we've heard from
>     Spectrum Bridge that this isn't an issue.
>
>
>     Ray
>
>     [email-masked] <mailto:[email-masked]>

---

From: Andy Lee <[email-masked]>
Date: Fri, 1 Nov 2013 18:01:05 -0700

Hi Benjamin,

Sorry if I missed it, but could you point out an example of something that
the proposed encoding is not able to represent?  As far as I've seen, all
of the examples from the FCC rules, and from WiFi, and from ATSC, can be
represented by the proposed encoding.

I respectfully disagree that the addition information is of no greater
value than the current draft.  This kind of information has already been
used successfully in other contexts without problems.  Some of the
certified database providers provide information beyond just a plain
channel list.  There are certainly use cases for value added information
that are not satisfied by the -06 draft.

It looks like most people agree that the proposed encoding can represent a
greater variety of data than the -06 encoding.  The proposed encoding is a
strict superset of the capabilities of the -06 draft, so *there's nothing
to lose by the change*.

The proposed change is only the text in *bold* below, plus an update of the
examples.  We've been spending quite a lot of time discussing a rather
small change.

5.10 Spectrum
> ...
> Parameters:
> *psdBandwidthHz*:  This parameter is REQUIRED to define the operating
>       bandwidth (in Hertz) for which permissible power levels is to be
>       specified.  For example, FCC regulation would require only one
>       spectrum specification at 6MHz bandwidth, but Ofcom regulation
>       would require 2 specifications, at 0.1MHz and 8MHz.  This
>       parameter MAY be empty if there is no available spectrum.
> *profiles*: A *FrequencyProfile* list is REQUIRED to
> *specify permissible*
> *      power levels across frequencies. Each FrequencyProfile entry in **
>     the **list is itself a list of (frequency, power) points*. The
>       *profiles* list MAY be empty if there is no available spectrum.
>
> Additionally, the "FrequencyRange" section would be changed to
> "FrequencyProfile".
> Specific encoding examples for a "Spectrum" message:
> Draft 06:
> {
>   "bandwidth": 6e6,
>   "frequencyRanges": [
>     {"startHz":5.18e8, "stopHz":5.26e8, "maxPowerDBm":30.0},
>     {"startHz":5.36e8, "stopHz":5.42e8, "maxPowerDBm":36.0},
>     ...
>   ]
> }
> Proposed Change:
> {
>   "psdBandwidthHz": 6e6,
>   "profiles": [
>     [
>      {"freqHz":5.18e8, "maxPsdDbmPerBw": 30.0},
>      {"freqHz":5.26e8, "maxPsdDbmPerBw": 30.0}
>     ],
>     [
>      {"freqHz":5.36e8, "maxPsdDbmPerBw": 36.0},
>      {"freqHz":5.42e8, "maxPsdDbmPerBw": 36.0}
>     ],
>     ...
>   ]
> }

On Fri, Nov 1, 2013 at 5:18 PM, Benjamin A. Rolfe <[email-masked]>wrote:

> affect the emissions profile a TVBD must comply with.  I gave a fairly long
> list, but I also stated that it was not exhaustive as I stated.
>
> In my opinion, the additional information encoded via the "mask" does not
> provide the capability that Andy appears to be advocating (and which quite
> a few people seem to be suppoting, including me). This extended "mask"
> encoding does not, IMO, provide enough to be of any greater use than what
> is in the draft.
>
> So I recommend moving forward with the simple encoding in the draft which
> will support TVBD deployment where it is currently possible.
>
> another SDO, but I do know the chair of  IEEE 1900.5 who has said he'd be
> happy to work with PAWS:   [email-masked]
>
> Hope that helps
> B
>
>
>
> paws mailing [email-masked]://www.ietf.org/mailman/listinfo/paws
>
>
>

---

From: <[email-masked]>
Date: Sat, 2 Nov 2013 01:13:57 +0000

As per the ietf procedures, any agreement reached in the f2f has to be confirmed on the list.
We discussed this encoding issue for 2 months on the list without being able to reach consensus.
That is why a  new version of the draft was not submitted. If by Tuesday the list does not reach consensus on how to update the encoding, then by default the current encoding stays in the draft.

If people continue to be unhappy with the content of the draft, then instead of issuing a new wglc, we'll need to keep continue discussions until we reach consensus, which delays the finalization of the draft.

-          Gabor

From: ext Andy Lee [mailto:[email-masked]]
Sent: Friday, November 01, 2013 3:21 PM
To: Nancy Bravin
Cc: Peter Stanforth; Bajko Gabor (Nokia-CIC/SiliconValley); Protocol to Access White Space database
Subject: Re: [paws] Question: Encode slopes?

Thanks, Nancy,

Just for reference, this topic surfaced as early as August 25 in this thread: http://www.ietf.org/mail-archive/web/paws/current/msg01607.html

In fact, is was agreed at the prior F2F meeting that option 2 was the more general (and preferable) encoding.

Best regards,

Andy Lee |

 Google Inc. |

On Fri, Nov 1, 2013 at 3:10 PM, Nancy Bravin <[email-masked]<mailto:[email-masked]>> wrote:
Sorry, meant to send to Andy, Gabor and the group as well.

On Nov 1, 2013, at 3:02 PM, Nancy Bravin <[email-masked]<mailto:[email-masked]>> wrote:

2. In that we have the ability to revise every 6 months which is not something most other SDO's can do, there is no reason to try and

Sincerely, Nancy
On Nov 1, 2013, at 2:45 PM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:

With all due respect you are not listing to what I am saying.
1 I agree that providing more flexible API and more information is what we should aim for with PAWS.
2 You were implying, incorrectly, that the current V6 PAWS protocol could not support the FCC rules, It can and does. We have implemented this protocol. I am not sure why that is 'proprietary'.
3 my only issue is that this is not fully thought out and we also need to get a PAWS protocol out the door. So I am trying to put this capability into a future iteration so we can do it justice.

Andy Lee |

 Google Inc. |

The FCC does not require the DB to provide any mask information. That can be validated by the 5 certified radios that are not getting anything but a channel list from a certified database.
I am still not convinced that, under current FCC rules, they will accept anything but a channel list.  I don't think they will object to a DB providing such information but they certainly do not require it.

Andy Lee |

 Google Inc. |

Hi Peter,

Best regards,

Andy Lee |

 Google Inc. |

Hi Peter,

Best regards,

Andy Lee |

 Google Inc. |

Hi,

A couple of comments:

Respectfully,

Andy Lee |

 Google Inc. |

Ray

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Fri, 1 Nov 2013 18:33:07 -0700

Well, since you asked!
Basically, everything else beyond the maximum power averaged over the 
6MHz channel. Well, it doesn't actually even do that because you have to 
just know that the given dBm value is average power over the 6MHz 
channel (and that it is a conducted limit, and so on).  You also just 
know that you must use only as much TX power as necessary,  You have to 
know that, in addition to meeting the x dBm over the 6MHz chunk, you 
have to meet a PSD limit of from 12.2dBm, 2.2dbM, -1.8dBm or -0.8dBm per 
any 100 kHz. And you just know this is a conducted limit.
You just know that in the channels immediately adjacent to the channel 
you are operating in, any spillage must be 72.8 dB below the highest 
average power in the TV channel in which the device is operating.
You have to just know what is in FCC part 15.209 because that specifies 
emission limits  in other than adjacent TV channels.
Then there is the field strength limits that apply to 602–620 MHz given 
in 15.709(4)
There's the niifty stuff in 15.712(a) which references §73.684 which 
adds additional requirements for emissions.

Practically speaking, as we move time forward and deploy real TBDBs we 
will see changes in the regulator  protection criteria that have driven 
many of these limits, especially the ones for out of channel radiation 
(which are some of the more complicated), as experience will show that 
TV receivers and other protected users are not harmed by TBBDs.  The max 
power allowed may also increase, but this is only one of the parameters 
I expect to see change.

FWIW I'm not convinced the dBm value in the draft 6 representation is 
not all that useful, but I didn't complain about that in time.

hope that helps some more...
B

On 11/1/2013 6:01 PM, Andy Lee wrote:
> Hi Benjamin,
>
> Sorry if I missed it, but could you point out an example of something 
> that the proposed encoding is not able to represent?  As far as I've 
> seen, all of the examples from the FCC rules, and from WiFi, and from 
> ATSC, can be represented by the proposed encoding.
>
> value than the current draft.  This kind of information has already 
> been used successfully in other contexts without problems.  Some of 
> the certified database providers provide information beyond just a 
> plain channel list.  There are certainly use cases for value added 
> information that are not satisfied by the -06 draft.
>
> It looks like most people agree that the proposed encoding can 
> represent a greater variety of data than the -06 encoding.  The 
> proposed encoding is a strict superset of the capabilities of the -06 
> draft, so _there's nothing to lose by the change_.
>
> The proposed change is only the text in *bold* below, plus an update 
> of the examples.  We've been spending quite a lot of time discussing a 
> rather small change.
>
>     5.10 Spectrum
>     ...
>     Parameters:
>     *profiles*: A *FrequencyProfile* list is REQUIRED to *specify
>     permissible
>     **      power levels across frequencies. Each FrequencyProfile
>     entry in
>     **      the **list is itself a list of (frequency, power) points*.
>     The
> On Fri, Nov 1, 2013 at 5:18 PM, Benjamin A. Rolfe <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     touched on only some of the requirements in the current FCC regs
>     that affect the emissions profile a TVBD must comply with.  I gave
>     a fairly long list, but I also stated that it was not exhaustive
>     as I stated.
>
>     In my opinion, the additional information encoded via the "mask"
>     does not provide the capability that Andy appears to be advocating
>     (and which quite a few people seem to be suppoting, including me).
>     This extended "mask" encoding does not, IMO, provide enough to be
>     of any greater use than what is in the draft.
>
>     So I recommend moving forward with the simple encoding in the
>     draft which will support TVBD deployment where it is currently
>     possible.
>
>     I further recommend the group move forward in developing the
>     additional protocol elements in PAWS to support the dynamic
>     speification of transmission characteristics  I also suggest that,
>     as we now know IEEE P1900.5 is in the process of developing a data
>     model for supporting the kind of adaptive process we seem to be
>     talking about, that PAWS could benefit from that work as a
>     starting point.  I don't know the proper process for establishing
>     a working relationship between this group and another SDO, but I
>     do know the chair of  IEEE 1900.5 who has said he'd be happy to
>     work with PAWS: [email-masked]
>     <mailto:[email-masked]>
>
>     Hope that helps
>     B
>
>
>
>>     What and how to encode is already defined in the FCC rules (the
>>     values have been referenced in previous messages).  The values
>>     are explicitly given to us, and we just need a way to include it
>>     in a PAWS message.
>>
>>     The current encoding does not support the encoding of those
>>     values (including slopes).  A new encoding has been proposed that
>>     does support the FCC parameters.
>>
>>     What is the justification for sticking with the less capable
>>     encoding?  The old encoding is incapable of supporting a use case
>>     that's been identified in the current rules.
>>
>>
>>     <mailto:[email-masked]> | 	408-230-0522 <tel:408-230-0522>
>>
>>
>>
>>         Even if things are hard coded in firmware, an update to
>>         firmware could bring the product up-to-date with the changed
>>         rules. Of course, it might be more flexible to have that info
>>         delivered over paws, but the discussions on this list do not
>>         indicate any consensus on what and how to encode.
>>
>>         Most people resist to changing the current encoding in draft
>>         -06. Since we were not able to conclude this discussion in
>>         time and submit a revised version of the document before the
>>         deadline, we can keep continue discussing this encoding issue
>>         for a few more days, but I’d like to conclude it by the F2F.
>>         So far, no conclusion in changing the current encoding, and
>>         unless a miracle happens in the next few days, this will be
>>         whether to create a paws version 2, and if yes, then what
>>         should be included in there. But before that discussion
>>         happens we need to get the current protocol out of the door.
>>
>>         -Gabor
>>
>>         [mailto:[email-masked] <mailto:[email-masked]>]
>>         *On Behalf Of *ext Andy Lee
>>         interpretation, but it seems pretty clear to me that the
>>         purpose of this note is to allow the device under test (DUT)
>>         to use information from the database to meet compliance
>>         requirements, if it so chooses.  It is not forced to have
>>         those constraints hard-coded in the firmware.
>>
>>         This leaves open the possibility for the FCC to change, add,
>>         or remove the constrains around channel 37 in the future.  If
>>         a device chooses to have hard-coded constraints in their
>>         firmware, they may end up missing out on some spectrum
>>         opportunities that might be permitted in future rule
>>         modifications.
>>
>>         Best regards,
>>
>>
>>         Andy Lee |
>>
>>         	
>>
>>          Google Inc. |
>>
>>         	
>>
>>         The note you reference in the test procedure is ambiguous,
>>         there is no reference to channels 36-38 in part two and no
>>         mention of tests to lock out unauthorized channels, or a
>>         definition of what that really means. So I can only base our
>>         interpretation on what we have been required to do to pass
>>         WSD certification. The FCC being the final judge of that. The
>>         way we have been required (By we I mean the DUT) to operate
>>         it that the DUT cannot have it’s compliance overridden by the
>>         database. A specific example. A DUT was having trouble
>>         complying with the channel 37 requirement and the
>>         manufacturer made the decision to block any use of channels
>>         around it in the firmware – to get a product out and allow
>>         them to rework the RF later. A test was required to prove
>>         that if the database provided those blocked channels as
>>         options that the DUT would in fact not operate on them, in
>>         Further the requirement you reference is about permission to
>>         use a channel not OOB emissions. (15.709(c)(4) which is what
>>         I was referring to.
>>
>>         I still don’t think defining the mask is a bad idea, though I
>>         about, but I do think this discussion belongs in a new
>>         version of PAWS where we can describe the requirements and
>>         define the behavior comprehensively. It is not required to
>>         support FCC or Ofcom management of WSDs. Which was the basis
>>         of the current PAWS requirements.
>>
>>         constraints to come from the database (and defer to Part 2
>>         for testing).  The rules in Part 1 are as follows:
>>
>>         Inline image 1
>>
>>         Best regards,
>>
>>
>>         Andy Lee |
>>
>>         	
>>
>>          Google Inc. |
>>
>>         	
>>
>>         The statement “White space devices must comply one way or
>>         another” is inconsistent with the testing process we have
>>         been required to use to get FCC certification (5 WSDs so
>>         far), and I suggest that you cannot currently certify a
>>         device that does not have the conformance encoded in the
>>         firmware. Specifically: In order to certify a White Space
>>         Device the device must be certified against the FCC test
>>         process
>>         Frequency (RF) Certification Tests,  tests the RF
>>         characteristics independent of the database, and includes
>>         conformance with channel 37 limits (iv. Measurements in the
>>         602-620 MHz band ( TV channels 36-38)) - which means the
>>         behavior has to be encoded in the device.
>>
>>         It is only after they have completed the Part 1 test that
>>         they run the Part 2 test: Database Interface Certification
>>         Tests, which is to validate the behavior of the radio with
>>         the database.
>>
>>         So to permit constraints to be managed by a WSDB, as you
>>         suggest, would require changes to the current TCB process
>>         defined by the FCC.
>>
>>         Peter S.
>>
>>           * The constraints on channels 36 and 38 are part of the
>>             current FCC rules.  White space devices must comply with
>>             this requirement one way or another, whether this
>>             information comes from the database or if it's somehow
>>             encoded into the device firmware.  The FCC allows for
>>             either kind of implementation, and PAWS should be
>>             supportive of this.
>>           * PAWS is not limited to the FCC or the TV band.  We want
>>             to be cognizant of emerging rules in other jurisdictions,
>>             in other bands, and with the current state of radio
>>             technologies.  This is (hopefully) an international
>>             standard that is not bound to any one country's rules or
>>             any one company's implementation.
>>           * All else being equal, why not choose an encoding that is
>>             a better match for all currently known rules and radio
>>             technologies?
>>
>>         Respectfully,
>>
>>
>>         Andy Lee |
>>
>>         	
>>
>>          Google Inc. |
>>
>>         	
>>
>>         <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>
>>         I do NOT support this change.  All of the observations I made
>>         in my message of 9th October still apply.
>>
>>         The only potentially valid use case I've seen for non-zero
>>         slopes are the FCC limits for channels 36 and 38, and we've
>>         heard from Spectrum Bridge that this isn't an issue.
>>
>>
>>         Ray
>>

---

From: Paul Lambert <[email-masked]>
Date: Fri, 1 Nov 2013 18:37:29 -0700

The new encoding proposal is  good idea.  While not required by the FCC, it provides additional information that we can work to use in implementations and will have a positive impact on future regulatory approaches.  As an individual working for a chip vendor – this approach matches the analysis we are already having to perform.

Paul

Hi Peter,

Best regards,

Andy Lee |

 Google Inc. |

Hi Peter,

Best regards,

Andy Lee |

 Google Inc. |

Hi,

A couple of comments:

Respectfully,

Andy Lee |

 Google Inc. |

Ray

---

From: Andy Lee <[email-masked]>
Date: Fri, 1 Nov 2013 18:54:34 -0700

Thanks Benjamin,

Responses inline below...

On Fri, Nov 1, 2013 at 6:33 PM, Benjamin A. Rolfe <[email-masked]>wrote:

>  Well, since you asked!
> Basically, everything else beyond the maximum power averaged over the 6MHz
> channel. Well, it doesn't actually even do that because you have to just
> know that the given dBm value is average power over the 6MHz channel (and
> that it is a conducted limit, and so on).  You also just know that you must
> use only as much TX power as necessary,  You have to know that, in addition
> to meeting the x dBm over the 6MHz chunk, you have to meet a PSD limit of
> from 12.2dBm, 2.2dbM, -1.8dBm or -0.8dBm per any 100 kHz. And you just know
> this is a conducted limit.
>

Yes, and the protocol supports this.  In fact, it is required under Ofcom
rules that we pass both an 8MHz psd response and a 100 KHz psd response.
 The device is required to comply with both spectrum profiles.

Similarly in the US, as your examples point out, these are over a specific
bandwidth.  It essentially works the same way.

All of the parameters mentioned here can be encoded using the proposed
draft.

BTW, the various limits you quote are for different device types.
 Depending on your device type, you'll only get one of those limits applied
to you.

Also, these are not conducted limits.  Most device types, like
personal/portable, have non-removable antennas, so their limits are
specified as EIRP.

The actual text is as follows (from CFR 47, section 15.709(a):

(5) The power spectral density from the TVBD shall not be greater than the
following values when measured in any 100 kHz band during any time interval
of continuous transmission.

(i) Fixed devices: 12.6 dBm conducted power. If transmitting antennas of
directional gain greater than 6 dBi are used, this conducted power level
shall be reduced by the amount in dB that the directional gain of the
antenna exceeds 6 dBi.

(ii) Personal/portable device operating adjacent to occupied TV channels:
-1.4 dBm EIRP.

(iii) Sensing-only devices: -0.4 dBm EIRP.

(iv) All other personal/portable devices: 2.6 dBm EIRP.

> You just know that in the channels immediately adjacent to the channel you
> are operating in, any spillage must be 72.8 dB below the highest average
> power in the TV channel in which the device is operating.
>

That is not correct.  The adjacent channel limits are absolute values that
do not vary with WSD operating power.  The emission limits are given as
follows (from CFR 47, section 15.709(c):

(c) Emission limits for TVBDs.--(1) In the television channels immediately
adjacent to the channel in which the TVBD is operating, emissions from the
TVBD shall not exceed the following levels.

(i) Fixed devices: -42.8 dBm conducted power.

(ii) Personal/portable device operating adjacent to occupied TV channels:
-56.8 dBm EIRP.

(iii) Sensing-only devices: -55.8 dBm EIRP.

(iv) All other personal/portable devices: -52.8 dBm EIRP.

In any case, this is a separate issue that is unrelated to how we choose to
do spectrum profile encoding.

> Then there is the field strength limits that apply to 602-620 MHz given
> in 15.709(4)
>

Yes.  I put out those examples, and they are fully encodable using the
proposed draft.

>
> There's the niifty stuff in 15.712(a) which references §73.684 which adds
> additional requirements for emissions.
>
> (which are some of the more complicated), as experience will show that TV
> receivers and other protected users are not harmed by TBBDs.  The max power
> allowed may also increase, but this is only one of the parameters I expect
> to see change.
>
> FWIW I'm not convinced the dBm value in the draft 6 representation is not
> all that useful, but I didn't complain about that in time.
>

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 4 Nov 2013 11:18:21 -0500

A heads up to the group.
As it seems this concept is becoming part of the protocol I have updated our IETF IPR statement to reflect the impact this has on our view of our IP in relation to the PAWS standard.
Regards,
Peter S.

From: Andy Lee <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 1, 2013 at 9:54 PM
To: "Benjamin A. Rolfe" <[email-masked]<mailto:[email-masked]>>
Cc: Protocol to Access White Space database <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Question: Encode slopes?

Thanks Benjamin,

On Fri, Nov 1, 2013 at 6:33 PM, Benjamin A. Rolfe <[email-masked]<mailto:[email-masked]>> wrote:
Well, since you asked!
Basically, everything else beyond the maximum power averaged over the 6MHz channel. Well, it doesn't actually even do that because you have to just know that the given dBm value is average power over the 6MHz channel (and that it is a conducted limit, and so on).  You also just know that you must use only as much TX power as necessary,  You have to know that, in addition to meeting the x dBm over the 6MHz chunk, you have to meet a PSD limit of from 12.2dBm, 2.2dbM, -1.8dBm or -0.8dBm per any 100 kHz. And you just know this is a conducted limit.

Yes, and the protocol supports this.  In fact, it is required under Ofcom rules that we pass both an 8MHz psd response and a 100 KHz psd response.  The device is required to comply with both spectrum profiles.

Similarly in the US, as your examples point out, these are over a specific bandwidth.  It essentially works the same way.

All of the parameters mentioned here can be encoded using the proposed draft.

BTW, the various limits you quote are for different device types.  Depending on your device type, you'll only get one of those limits applied to you.

Also, these are not conducted limits.  Most device types, like personal/portable, have non-removable antennas, so their limits are specified as EIRP.

(5) The power spectral density from the TVBD shall not be greater than the following values when measured in any 100 kHz band during any time interval of continuous transmission.

(i) Fixed devices: 12.6 dBm conducted power. If transmitting antennas of directional gain greater than 6 dBi are used, this conducted power level shall be reduced by the amount in dB that the directional gain of the antenna exceeds 6 dBi.

(ii) Personal/portable device operating adjacent to occupied TV channels: -1.4 dBm EIRP.

You just know that in the channels immediately adjacent to the channel you are operating in, any spillage must be 72.8 dB below the highest average power in the TV channel in which the device is operating.

That is not correct.  The adjacent channel limits are absolute values that do not vary with WSD operating power.  The emission limits are given as follows (from CFR 47, section 15.709(c):

(c) Emission limits for TVBDs.—(1) In the television channels immediately adjacent to the channel in which the TVBD is operating, emissions from the TVBD shall not exceed the following levels.

(ii) Personal/portable device operating adjacent to occupied TV channels: -56.8 dBm EIRP.

In any case, this is a separate issue that is unrelated to how we choose to do spectrum profile encoding.

You have to just know what is in FCC part 15.209 because that specifies emission limits  in other than adjacent TV channels.
Then there is the field strength limits that apply to 602–620 MHz given in 15.709(4)

Yes.  I put out those examples, and they are fully encodable using the proposed draft.

There's the niifty stuff in 15.712(a) which references §73.684 which adds additional requirements for emissions.

Practically speaking, as we move time forward and deploy real TBDBs we will see changes in the regulator  protection criteria that have driven many of these limits, especially the ones for out of channel radiation (which are some of the more complicated), as experience will show that TV receivers and other protected users are not harmed by TBBDs.  The max power allowed may also increase, but this is only one of the parameters I expect to see change.

FWIW I'm not convinced the dBm value in the draft 6 representation is not all that useful, but I didn't complain about that in time.

---

From: <[email-masked]>
Date: Mon, 4 Nov 2013 17:21:27 +0000

Peter,
What IPR declaration have you updated? IPR declarations against the solution document are listed here:
http://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-ietf-paws-protocol
and currently there is only one IPR listed, which does not come from you.

-Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Peter Stanforth
Sent: Monday, November 04, 2013 8:18 AM
To: Andy Lee; Benjamin A. Rolfe
Cc: Protocol to Access White Space database
Subject: Re: [paws] Question: Encode slopes?

A heads up to the group.

Thanks Benjamin,

(c) Emission limits for TVBDs.-(1) In the television channels immediately adjacent to the channel in which the TVBD is operating, emissions from the TVBD shall not exceed the following levels.

You have to just know what is in FCC part 15.209 because that specifies emission limits  in other than adjacent TV channels.
Then there is the field strength limits that apply to 602-620 MHz given in 15.709(4)

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 4 Nov 2013 12:35:24 -0500

This one. I just looked and it does not reflect what I changed. Not sure how long it takes for the system to show a change.
https://datatracker.ietf.org/ipr/1838/

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 4, 2013 at 1:21 PM
To: Peter Stanforth <[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]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [paws] Question: Encode slopes?

Peter,

-Gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Peter Stanforth

A heads up to the group.

Thanks Benjamin,