Subject: [paws] Question: Encode slopes?

From: Vincent Chen <[email-masked]>
Date: Mon, 21 Oct 2013 23:47:06 -0700

All,

At the last F2F, we had general agreement that supporting the ability to
encode slopes in the spectrum profile was a good idea. (I've attached some
supporting information at the end of this email illustrating specs that
apply to TVWS, TV broadcast, and WiFi that are expressed in terms of
slopes.)

In subsequent discussions on the list for determining how to encode this
information, however, it became clear that we should revisit this question,
independent of the encoding. So....

Question: Should PAWS support the ability to encode slopes?

-- 
-vince

FCC white space rules uses slopes in their emission limits for channels 36
thru 38 (CFR 47, section 15.709).  This is part of the current white space
regulation and we cannot support it.  The FCC-defined spectrum profile
looks like this:

The TV broadcast industry uses spectrum profiles to define their emission
limits.  The ATSC transmitter compliance specs are available at
http://www.atsc.org/cms/standards/a_64b.pdf.  Their spectrum profile also
uses sloped lines in its definition, and looks like this:

The Wi-Fi industry has transmit spectrum masks for their devices that also
use slopes.  The details of the mask depend on which modulation type is
currently active.  In the 802.11-2012 spec, there are currently 76 distinct
modulation and coding schemes defined, so a Wi-Fi device can behave like
many different kinds of radios depending on which modulation type it is
using at the moment.  A sample of one of the spectrum masks looks like this:

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 22 Oct 2013 11:03:20 -0400

> Question: Should PAWS support the ability to encode slopes?

IMHO, it's a significant limitation of the current specification, but
can probably wait for "version 2".  Doing it properly will involve a
lot of changes to the protocol and the logic for checking constraints.

-- 
Wes Eddy
MTI Systems

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 22 Oct 2013 12:07:39 -0400

Took the words right out of my mouth! My preference is to make sure we have addressed all known regulator issues, for which I don't believe this is required, and then do this right next time.
Peter S.

From: Wesley Eddy <[email-masked]<mailto:[email-masked]>>
Organization: MTI Systems
Date: Tuesday, October 22, 2013 11:03 AM
To: Vincent Chen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Question: Encode slopes?

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

---

From: Ray Bellis <[email-masked]>
Date: Wed, 23 Oct 2013 08:44:28 +0000

> Took the words right out of my mouth! My preference is to make sure we have addressed all known regulator issues, for which I don't believe this is required, and then do this right next time.

+lots

Ray

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Wed, 23 Oct 2013 08:40:41 -0700

It would seem from the thread that this method of specifying a "mask" 
(emission limits) does not address the known regulatory requirements in 
the United States, where a simple rectangle does not describe the 
emissions profile limits.
This circles me back to the question I asked quite a while ago, which is 
how, as a device developer, do I use this information? What is the 
purpose of providing a "mask"?
Related question: Do the current FCC approved databases provide this 
"mask" information now?
Thanks
Ben

On 10/23/2013 1:44 AM, Ray Bellis wrote:
> [email-masked]

---

From: Peter Stanforth <[email-masked]>
Date: Wed, 23 Oct 2013 11:47:59 -0400

Speaking as an FCC certified TVWS database provider, we do not supply any information to the devices related to EIRP, PSD, mask or similar characteristics.
The device supplied FCCID tells us what the FCC compliance is (high power fixed, personal/portable mode 1 or 2) and we calculate protection, and respond with channel lists based on this.
All the device gets is a list of channels that it is legally allowed to operate on, based on the device classification provided.

From: "Benjamin A. Rolfe" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 23, 2013 at 11:40 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Question: Encode slopes?

It would seem from the thread that this method of specifying a "mask" (emission limits) does not address the known regulatory requirements in the United States, where a simple rectangle does not describe the emissions profile limits.
This circles me back to the question I asked quite a while ago, which is how, as a device developer, do I use this information?  What is the purpose of providing a "mask"?
Related question: Do the current FCC approved databases provide this "mask" information now?
Thanks
Ben

On 22 Oct 2013, at 17:07, Peter Stanforth <[email-masked]><mailto:[email-masked]> wrote:

+lots

Ray

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

---

From: Andy Lee <[email-masked]>
Date: Wed, 23 Oct 2013 12:23:30 -0700

Speaking as another FCC certified database provider, we do supply a
spectrum mask, and the response from the database is specified in terms of
frequencies rather than channels.

As an industry reference, Wi-Fi has been using spectrum profiles with
slopes for many years now (link to
spec<http://standards.ieee.org/getieee802/download/802.11-2012.pdf>).
 See section D.2.3 Transmit Spectrum Mask requirements.  The relationship
between this transmit spectrum mask and the TVWS emission limit mask is
very relevant to picking operating frequencies, especially around channel
37 and the band edges.

Best regards,

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

On Wed, Oct 23, 2013 at 8:47 AM, Peter Stanforth
<[email-masked]>wrote:

> Speaking as an FCC certified TVWS database provider, we do not supply any
> information to the devices related to EIRP, PSD, mask or similar
> characteristics.
> The device supplied FCCID tells us what the FCC compliance is (high power
> fixed, personal/portable mode 1 or 2) and we calculate protection, and
> respond with channel lists based on this.
> All the device gets is a list of channels that it is legally allowed to
> operate on, based on the device classification provided.
>
> From: "Benjamin A. Rolfe" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
>
> (emission limits) does not address the known regulatory requirements in the
> United States, where a simple rectangle does not describe the emissions
> profile limits.
> how, as a device developer, do I use this information?  What is the purpose
> of providing a "mask"?
> On 22 Oct 2013, at 17:07, Peter Stanforth <[email-masked]> <[email-masked]> wrote:
>
>
> paws mailing [email-masked]://www.ietf.org/mailman/listinfo/paws
>
>
>

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Wed, 23 Oct 2013 16:30:54 -0700

One should take careful note that the spectrum profiles used in the 
802.11 DO NOT specify regulatory requirements, as such is out of scope 
of 802.11 as clearly sated in the boilerplate to the standard:

"Compliance with the provisions of any IEEE standards document does not 
imply compliance to any applicable regulatory requirements."

The mask specified in annex D of 802.11-2012 specifies requirements on 
an 802.11 device both as a transmitting device (it should fall within 
the boundaries of the envelope given) and as a receiving device (it must 
capture a signal that meets these requirements and tolerate emissions 
within this envelope spilling into the channel.  This does NOT assure 
regulatory compliance anywhere on earth (or elsewhere).

With that out of the way,  Andy's suggestion below ceertainly makes this 
"mask" representation more useful.  I did go back and review the emails 
on this topic and at least once it was stated that the goal of this 
"mask" is to capture regulatory requirements that may change from region 
to region, or over time, so that an implementation may be adaptable 
instead of having emission requirements hard coded. The current 
representation does not seem to meet that goal.  The enhancements that 
Andy shows below would come closer.

If the current desire of the majority is to "get on with it" addressing 
known regulations now and deal with enhancements such as this in version 
2, then I'd suggest removing the "mask" representation from the draft 
for now, and add it when the group feels it is appropriate to take the 
time to define it completly.   To meet the current rules that are 
approved for TVWS devices (FCC) we don't need the "mask" represented (as 
at least one database has been approved without it).  It would be a very 
useful enhancement to be able to derive the in-channel and near-channel 
emission masks from the database, but it is only if it is complete.

On 10/23/2013 12:23 PM, Andy Lee wrote:
> spectrum mask, and the response from the database is specified in 
> terms of frequencies rather than channels.
>
> slopes for many years now (link to spec 
> <http://standards.ieee.org/getieee802/download/802.11-2012.pdf>).  See 
> section D.2.3 Transmit Spectrum Mask requirements.  The relationship 
> between this transmit spectrum mask and the TVWS emission limit mask 
> is very relevant to picking operating frequencies, especially around 
> channel 37 and the band edges.
>
> Inline image 1
>
> Best regards,
>
>
> Andy Lee | 	 Google Inc. | 	[email-masked] 
> <mailto:[email-masked]> | 	 408-230-0522
>
>
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Speaking as an FCC certified TVWS database provider, we do not
>     supply any information to the devices related to EIRP, PSD, mask
>     or similar characteristics.
>     The device supplied FCCID tells us what the FCC compliance is
>     (high power fixed, personal/portable mode 1 or 2) and we calculate
>     protection, and respond with channel lists based on this.
>     All the device gets is a list of channels that it is legally
>     allowed to operate on, based on the device classification provided.
>
>     To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>
>     It would seem from the thread that this method of specifying a
>     "mask" (emission limits) does not address the known regulatory
>     requirements in the United States, where a simple rectangle does
>     not describe the emissions profile limits.
>     This circles me back to the question I asked quite a while ago,
>     which is how, as a device developer, do I use this information? 
>     What is the purpose of providing a "mask"?
>>     On 22 Oct 2013, at 17:07, Peter Stanforth<[email-masked]>  <mailto:[email-masked]>  wrote:
>>
>>     [email-masked]  <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/paws
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Peter Stanforth <[email-masked]>
Date: Thu, 24 Oct 2013 14:09:47 -0400

The concept of the database acting as a policy  manager is very appealing - but not simple. Which is why my preference is still to put this in version 2 and think through all the issues.
Putting my device developer hat on I can’t reconcile the policy manager concept under current FCC rules. It is a Catch 22. Assuming I certify today it will be against a specific set of operating characteristics. I would expect Andy to provide those same characteristics in his implementation. However if, in the future Andy provides different characteristics my device may no longer compliant with the rules and should not be operating. However if I adjust the operating characteristics the device is no longer in compliance with its certification, and would be operating illegally. So either the “new” rule permits grandfathered operation or my device needs to be re-certified.  It seems like we have to convince Regulators to certify databases as policy managers and simply certify radios to ensure they comply with the policy they are given for this concept to work.

From: "Benjamin A. Rolfe" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 23, 2013 at 7:30 PM
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Question: Encode slopes?

One should take careful note that the spectrum profiles used in the 802.11 DO NOT specify regulatory requirements, as such is out of scope of 802.11 as clearly sated in the boilerplate to the standard:

"Compliance with the provisions of any IEEE standards document does not imply compliance to any applicable regulatory requirements."

The mask specified in annex D of 802.11-2012 specifies requirements on an 802.11 device both as a transmitting device (it should fall within the boundaries of the envelope given) and as a receiving device (it must capture a signal that meets these requirements and tolerate emissions within this envelope spilling into the channel.  This does NOT assure regulatory compliance anywhere on earth (or elsewhere).

With that out of the way,  Andy's suggestion below ceertainly makes this "mask" representation more useful.  I did go back and review the emails on this topic and at least once it was stated that the goal of this "mask" is to capture regulatory requirements that may change from region to region, or over time, so that an implementation may be adaptable instead of having emission requirements hard coded. The current representation does not seem to meet that goal.  The enhancements that Andy shows below would come closer.

If the current desire of the majority is to "get on with it" addressing known regulations now and deal with enhancements such as this in version 2, then I'd suggest removing the "mask" representation from the draft for now, and add it when the group feels it is appropriate to take the time to define it  completly.   To meet the current rules that are approved for TVWS devices (FCC) we don't need the "mask" represented (as at least one database has been approved without it).  It would be a very useful enhancement to be able to derive the in-channel and near-channel emission masks from the database, but it is only if it is complete.

On 10/23/2013 12:23 PM, Andy Lee wrote:
Speaking as another FCC certified database provider, we do supply a spectrum mask, and the response from the database is specified in terms of frequencies rather than channels.

As an industry reference, Wi-Fi has been using spectrum profiles with slopes for many years now (link to spec<http://standards.ieee.org/getieee802/download/802.11-2012.pdf>).  See section D.2.3 Transmit Spectrum Mask requirements.  The relationship between this transmit spectrum mask and the TVWS emission limit mask is very relevant to picking operating frequencies, especially around channel 37 and the band edges.

Best regards,

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

On Wed, Oct 23, 2013 at 8:47 AM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
Speaking as an FCC certified TVWS database provider, we do not supply any information to the devices related to EIRP, PSD, mask or similar characteristics.
The device supplied FCCID tells us what the FCC compliance is (high power fixed, personal/portable mode 1 or 2) and we calculate protection, and respond with channel lists based on this.
All the device gets is a list of channels that it is legally allowed to operate on, based on the device classification provided.

+lots

Ray

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 24 Oct 2013 11:57:58 -0700

Very good points, Peter.  This is not a simple topic, it is ambitious 
and requires making guesses about what is going to happen in the 
future.  Not something completed quickly. There is a lot of good to be 
had finishing the standard  around the current regulations so that 
device implementers and database implementers can converge on a common 
protocol for the basic access we need right now, and I agree with Peter, 
best not bog that down now.  It seems worthy to have a standard that 
covers the basics real soon, and build upon it as experience teaches us 
(and regulators) what else we need.

I would encourage thought on the subject (please!), as history shows 
that here in the US at least, presenting the regulators with a viable 
technical approach has been a succesfull way to start regulatory 
change.  And I really do think the dynamic policy manager concept is 
really, really useful, not just for whitespace.

On 10/24/2013 11:09 AM, Peter Stanforth wrote:
> The concept of the database acting as a policy  manager is very 
> appealing - but not simple. Which is why my preference is still to put 
> this in version 2 and think through all the issues.
> Putting my device developer hat on I can’t reconcile the policy 
> manager concept under current FCC rules. It is a Catch 22. Assuming I 
> certify today it will be against a specific set of operating 
> characteristics. I would expect Andy to provide those same 
> characteristics in his implementation. However if, in the future Andy 
> provides different characteristics my device may no longer compliant 
> with the rules and should not be operating. However if I adjust the 
> operating characteristics the device is no longer in compliance with 
> its certification, and would be operating illegally. So either the 
> “new” rule permits grandfathered operation or my device needs to be 
> re-certified.  It seems like we have to convince Regulators to certify 
> databases as policy managers and simply certify radios to ensure they 
> comply with the policy they are given for this concept to work.
>
> From: "Benjamin A. Rolfe" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> "Compliance with the provisions of any IEEE standards document does 
> not imply compliance to any applicable regulatory requirements."
>
> the boundaries of the envelope given) and as a receiving device (it 
> must capture a signal that meets these requirements and tolerate 
> emissions within this envelope spilling into the channel. This does 
> NOT assure regulatory compliance anywhere on earth (or elsewhere).
>
> With that out of the way,  Andy's suggestion below ceertainly makes 
> this "mask" representation more useful. I did go back and review the 
> emails on this topic and at least once it was stated that the goal of 
> this "mask" is to capture regulatory requirements that may change from 
> region to region, or over time, so that an implementation may be 
> adaptable instead of having emission requirements hard coded. The 
> current representation does not seem to meet that goal.  The 
> enhancements that Andy shows below would come closer.
>
> If the current desire of the majority is to "get on with it" 
> addressing known regulations now and deal with enhancements such as 
> this in version 2, then I'd suggest removing the "mask" representation 
> from the draft for now, and add it when the group feels it is 
> appropriate to take the time to define it  completly.   To meet the 
> current rules that are approved for TVWS devices (FCC) we don't need 
> the "mask" represented (as at least one database has been approved 
> without it).  It would be a very useful enhancement to be able to 
> derive the in-channel and near-channel emission masks from the 
> database, but it is only if it is complete.
>
>
>
>> <http://standards.ieee.org/getieee802/download/802.11-2012.pdf>). 
>>  See section D.2.3 Transmit Spectrum Mask requirements.  The 
>> relationship between this transmit spectrum mask and the TVWS 
>> emission limit mask is very relevant to picking operating 
>> frequencies, especially around channel 37 and the band edges.
>>
>> Inline image 1
>>
>> Best regards,
>>
>>
>>     (high power fixed, personal/portable mode 1 or 2) and we
>>     calculate protection, and respond with channel lists based on this.

---

From: "Stine, John A." <[email-masked]>
Date: Thu, 24 Oct 2013 23:00:56 +0000

Ben,

                There are other standards bodies working on parts of this, specifically the IEEE Dynamic Spectrum Access Networks Standards Committee.  Work Group 1900.5 is addressing the use of policy and policy architectures.  It currently has two active projects, 1900.5.1 which is developing a dynamic spectrum access policy language and 1900.5.2 which is creating spectrum consumption modeling methods.  These projects are not addressing the database architecture and messaging that is required for database managed spectrum management which we are expecting PAWS to do.  These projects are focused on policy language and data models only.

                I am personally working on the 1900.5.2 standard.  The spectrum consumption modeling methods are creating two things: a set of constructs with which to model the boundaries of spectrum use and a set of computations that can be used with the models to arbitrate whether any two models are compatible.  This combination allows databases to manage coexistence, incumbents to add spectrum to the database system (the models provide the equivalent of contours), for pairs of users to negotiate sharing, and for the whole process to create geospatial policy by default.  They commoditize spectrum.

                The 1900.5.2 standards project has just started.  The project authorization request was approved in March.  The WG is currently producing a requirements and use case document but in the end will likely use methods developed in MITRE's internal research program on Model-Based Spectrum Management.  The spectrum consumption models we propose provide the means to model full spectrum masks with slopes, the susceptibility to interference of receivers with underlay masks that also have slopes and a whole lot more.

                I have already started communicating with the US regulatory agencies.  The NTIA and parts of the FCC are aware of this work.  We specifically address a couple of the more visible spectrum sharing topics, the receiver standards/efficiency work and sharing in the 3550-3650 MHz bands.

                I encourage you to look into participating.  I am sure if you ask, Mat Sherman, our chair, will gladly add you or anyone else interested to the group's email list and if you are willing to participate, to the group.

John Stine

From: [email-masked] [mailto:[email-masked]] On Behalf Of Benjamin A. Rolfe
Sent: Thursday, October 24, 2013 2:58 PM
Cc: [email-masked]
Subject: Re: [paws] Question: Encode slopes?

Very good points, Peter.  This is not a simple topic, it is ambitious and requires making guesses about what is going to happen in the future.  Not something completed quickly. There is a lot of good to be had finishing the standard  around the current regulations so that device implementers and database implementers can converge on a common protocol for the basic access we need right now, and I agree with Peter, best not bog that down now.  It seems worthy to have a standard that covers the basics real soon, and build upon it as experience teaches us (and regulators) what else we need.

I would encourage thought on the subject (please!), as history shows that here in the US at least, presenting the regulators with a viable technical approach has been a succesfull way to start regulatory change.  And I really do think the dynamic policy manager concept is really, really useful, not just for whitespace.

On 10/24/2013 11:09 AM, Peter Stanforth wrote:
The concept of the database acting as a policy  manager is very appealing - but not simple. Which is why my preference is still to put this in version 2 and think through all the issues.
Putting my device developer hat on I can't reconcile the policy manager concept under current FCC rules. It is a Catch 22. Assuming I certify today it will be against a specific set of operating characteristics. I would expect Andy to provide those same characteristics in his implementation. However if, in the future Andy provides different characteristics my device may no longer compliant with the rules and should not be operating. However if I adjust the operating characteristics the device is no longer in compliance with its certification, and would be operating illegally. So either the "new" rule permits grandfathered operation or my device needs to be re-certified.  It seems like we have to convince Regulators to certify databases as policy managers and simply certify radios to ensure they comply with the policy they are given for this concept to work.

Best regards,

Andy Lee |

 Google Inc. |

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

 408-230-0522

+lots

Ray

paws mailing list

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 24 Oct 2013 16:34:43 -0700

Thanks John,
This is good information for this group to know.  Data models are often 
a good place to start when developing protocols :-).
-Ben

On 10/24/2013 4:00 PM, Stine, John A. wrote:
>
> Ben,
>
> There are other standards bodies working on parts of this, 
> specifically the IEEE Dynamic Spectrum Access Networks Standards 
> Committee.  Work Group 1900.5 is addressing the use of policy and 
> policy architectures.  It currently has two active projects, 1900.5.1 
> which is developing a dynamic spectrum access policy language and 
> 1900.5.2 which is creating spectrum consumption modeling methods.  
> These projects are not addressing the database architecture and 
> messaging that is required for database managed spectrum management 
> which we are expecting PAWS to do.  These projects are focused on 
> policy language and data models only.
>
> I am personally working on the 1900.5.2 standard.  The spectrum 
> consumption modeling methods are creating two things: a set of 
> constructs with which to model the boundaries of spectrum use and a 
> set of computations that can be used with the models to arbitrate 
> whether any two models are compatible.  This combination allows 
> databases to manage coexistence, incumbents to add spectrum to the 
> database system (the models provide the equivalent of contours), for 
> pairs of users to negotiate sharing, and for the whole process to 
> create geospatial policy by default. They commoditize spectrum.
>
> The 1900.5.2 standards project has just started.  The project 
> authorization request was approved in March.  The WG is currently 
> producing a requirements and use case document but in the end will 
> likely use methods developed in MITRE's internal research program on 
> Model-Based Spectrum Management.  The spectrum consumption models we 
> propose provide the means to model full spectrum masks with slopes, 
> the susceptibility to interference of receivers with underlay masks 
> that also have slopes and a whole lot more.
>
> I have already started communicating with the US regulatory agencies.  
> The NTIA and parts of the FCC are aware of this work.  We specifically 
> address a couple of the more visible spectrum sharing topics, the 
> receiver standards/efficiency work and sharing in the 3550-3650 MHz bands.
>
> I encourage you to look into participating.  I am sure if you ask, Mat 
> Sherman, our chair, will gladly add you or anyone else interested to 
> the group's email list and if you are willing to participate, to the 
> group.
>
> John Stine
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Benjamin A. Rolfe
> *Sent:* Thursday, October 24, 2013 2:58 PM
> *Cc:* [email-masked]
> *Subject:* Re: [paws] Question: Encode slopes?
>
> protocol for the basic access we need right now, and I agree with 
> Peter, best not bog that down now.  It seems worthy to have a standard 
> that covers the basics real soon, and build upon it as experience 
> teaches us (and regulators) what else we need.
>
>     appealing - but not simple. Which is why my preference is still to
>     put this in version 2 and think through all the issues.
>
>     Putting my device developer hat on I can't reconcile the policy
>     manager concept under current FCC rules. It is a Catch 22.
>     Assuming I certify today it will be against a specific set of
>     operating characteristics. I would expect Andy to provide those
>     same characteristics in his implementation. However if, in the
>     future Andy provides different characteristics my device may no
>     longer compliant with the rules and should not be operating.
>     However if I adjust the operating characteristics the device is no
>     longer in compliance with its certification, and would be
>     operating illegally. So either the "new" rule permits
>     grandfathered operation or my device needs to be re-certified.  It
>     seems like we have to convince Regulators to certify databases as
>     policy managers and simply certify radios to ensure they comply
>     with the policy they are given for this concept to work.
>
>     *From: *"Benjamin A. Rolfe" <[email-masked]
>     <mailto:[email-masked]>>
>     *Date: *Wednesday, October 23, 2013 at 7:30 PM
>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject: *Re: [paws] Question: Encode slopes?
>
>     One should take careful note that the spectrum profiles used in
>     the 802.11 DO NOT specify regulatory requirements, as such is out
>     of scope of 802.11 as clearly sated in the boilerplate to the
>     standard:
>
>     "Compliance with the provisions of any IEEE standards document
>     does not imply compliance to any applicable regulatory requirements."
>
>     The mask specified in annex D of 802.11-2012 specifies
>     requirements on an 802.11 device both as a transmitting device (it
>     should fall within the boundaries of the envelope given) and as a
>     receiving device (it must capture a signal that meets these
>     requirements and tolerate emissions within this envelope spilling
>     into the channel.  This does NOT assure regulatory compliance
>     anywhere on earth (or elsewhere).
>
>     With that out of the way,  Andy's suggestion below ceertainly
>     makes this "mask" representation more useful.  I did go back and
>     review the emails on this topic and at least once it was stated
>     that the goal of this "mask" is to capture regulatory requirements
>     that may change from region to region, or over time, so that an
>     implementation may be adaptable instead of having emission
>     requirements hard coded. The current representation does not seem
>     to meet that goal.  The enhancements that Andy shows below would
>     come closer.
>
>     addressing known regulations now and deal with enhancements such
>     as this in version 2, then I'd suggest removing the "mask"
>     representation from the draft for now, and add it when the group
>     feels it is appropriate to take the time to define it completly.  
>     To meet the current rules that are approved for TVWS devices (FCC)
>     we don't need the "mask" represented (as at least one database has
>     been approved without it).  It would be a very useful enhancement
>     to be able to derive the in-channel and near-channel emission
>     masks from the database, but it is only if it is complete.
>
>
>         Speaking as another FCC certified database provider, we do
>         supply a spectrum mask, and the response from the database is
>         specified in terms of frequencies rather than channels.
>
>         As an industry reference, Wi-Fi has been using spectrum
>         profiles with slopes for many years now (link to spec
>         [email-masked] <mailto:[email-masked]> |
>
>         	
>
>          408-230-0522
>
>         supply any information to the devices related to EIRP, PSD,
>         mask or similar characteristics.
>
>         *From: *"Benjamin A. Rolfe" <[email-masked]
>         <mailto:[email-masked]>>
>         *Date: *Wednesday, October 23, 2013 at 11:40 AM
>         *To: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>
>
>
>         *Subject: *Re: [paws] Question: Encode slopes?
>
>         requirements in the United States, where a simple rectangle
>         does not describe the emissions profile limits.
>         This circles me back to the question I asked quite a while
>         ago, which is how, as a device developer, do I use this
>         information?  What is the purpose of providing a "mask"?

---

From: Andy Lee <[email-masked]>
Date: Thu, 24 Oct 2013 16:35:32 -0700

Hi,

if, in the future Andy provides different characteristics my device may no
> longer compliant with the rules and should not be operating.

I'm not sure I understand this point or why anything would become
non-compliant.  Whether PAWS sends the spectrum data with "flat" encoding
or "sloped" encoding is independent of device compliance.  Supposing the
FCC modifies the rules in the future and allows 50 mW and 120 mW instead of
40 mW and 100 mW limits, then the PAWS will update accordingly (no matter
which encoding is used).

We've always held that one of the key benefits of database managed spectrum
is the ability to have device automatically adapt when spectrum resources
change (e.g., the "incentive auction" 600 MHz NPRM) or when protection
rules need to be changed (e.g., interference is being reported and the
calculations need to be modified).  It gives regulators the power to make
tweaks to spectrum policy without having to displace a large installed base
of devices.

>From a "black box" perspective, the emissions limits are what define
whether a WSD will cause interference or not.  In very basic terms, if the
emissions are low enough, there is no way for the device to cause
interference.  The database is simply providing the WSD information so that
it can configure operating parameters to stay below those emissions limits.

Best regards,

On Thu, Oct 24, 2013 at 11:09 AM, Peter Stanforth
<[email-masked]>wrote:

> The concept of the database acting as a policy  manager is very appealing
> - but not simple. Which is why my preference is still to put this in
> version 2 and think through all the issues.
> Putting my device developer hat on I can’t reconcile the policy manager
> concept under current FCC rules. It is a Catch 22. Assuming I certify today
> it will be against a specific set of operating characteristics. I would
> expect Andy to provide those same characteristics in his implementation.
> However if, in the future Andy provides different characteristics my device
> may no longer compliant with the rules and should not be operating. However
> if I adjust the operating characteristics the device is no longer in
> compliance with its certification, and would be operating illegally. So
> either the “new” rule permits grandfathered operation or my device needs to
> be re-certified.  It seems like we have to convince Regulators to certify
> Cc: "[email-masked]" <[email-masked]>
>
> One should take careful note that the spectrum profiles used in the 802.11
> DO NOT specify regulatory requirements, as such is out of scope of 802.11
> as clearly sated in the boilerplate to the standard:
>
> The mask specified in annex D of 802.11-2012 specifies requirements on an
> 802.11 device both as a transmitting device (it should fall within the
> boundaries of the envelope given) and as a receiving device (it must
> "mask" representation more useful.  I did go back and review the emails on
> this topic and at least once it was stated that the goal of this "mask" is
> to capture regulatory requirements that may change from region to region,
> or over time, so that an implementation may be adaptable instead of having
> emission requirements hard coded. The current representation does not seem
> to meet that goal.  The enhancements that Andy shows below would come
> closer.
>
> known regulations now and deal with enhancements such as this in version 2,
> then I'd suggest removing the "mask" representation from the draft for now,
> and add it when the group feels it is appropriate to take the time to
> define it  completly.   To meet the current rules that are approved for
> TVWS devices (FCC) we don't need the "mask" represented (as at least one
> database has been approved without it).  It would be a very useful
> enhancement to be able to derive the in-channel and near-channel emission
> slopes for many years now (link to spec<http://standards.ieee.org/getieee802/download/802.11-2012.pdf>).
> On Wed, Oct 23, 2013 at 8:47 AM, Peter Stanforth <[email-masked]
> > wrote:
>

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 24 Oct 2013 17:29:55 -0700

On 10/24/2013 4:35 PM, Andy Lee wrote:
> Hi,
>
>     if, in the future Andy provides different characteristics my
>     device may no longer compliant with the rules and should not be
>     operating.
>
>
> non-compliant.  Whether PAWS sends the spectrum data with "flat" 
> encoding or "sloped" encoding is independent of device compliance. 
>  Supposing the FCC modifies the rules in the future and allows 50 mW 
> and 120 mW instead of 40 mW and 100 mW limits, then the PAWS will 
> update accordingly (no matter which encoding is used).
>
> We've always held that one of the key benefits of database managed 
> spectrum is the ability to have device automatically adapt when 
> spectrum resources change (e.g., the "incentive auction" 600 MHz NPRM) 
> or when protection rules need to be changed (e.g., interference is 
> being reported and the calculations need to be modified).  It gives 
> regulators the power to make tweaks to spectrum policy without having 
> to displace a large installed base of devices.

Many of us think this is a great idea, and as indicated in other posts 
to this list, a lot of work is going on in the standards development 
world around this idea.  All good. The currently defined rules for 
certifying a device do not support such a  model.  Not so good, but 
things will change eventually.

The currently defined "mask" representation does not contain sufficient 
information to encode the transmit power (intentional emissions) limits 
as defined by the current FCC rules. It is only part of the information, 
and part is not enough to be useful.

> whether a WSD will cause interference or not.  In very basic terms, if 
> the emissions are low enough, there is no way for the device to cause 
> interference.
In very basic terms, the definition of "low enough" is hard fought, with 
licensed incumbents usually starting with "none at all" as their 
definition and we negotiate from there, and it has never been trivial, 
easy or quick.  If your point is that things are assured to change, I 
have to agree enthusiastically.   As things change, I don't expect the 
specification of emission limits to get simpler.

>  The database is simply providing the WSD information so that it can 
> configure operating parameters to stay below those emissions limits.
That would  be great, but not trivial.

Are you suggesting that PAWS should tackle the (complex) task of 
defining the protocol needed to support dynamic spectrum management now?

B

>     operating illegally. So either the “new” rule permits
>     feels it is appropriate to take the time to define it 
>     completly.   To meet the current rules that are approved for TVWS
>     devices (FCC) we don't need the "mask" represented (as at least
>     one database has been approved without it). It would be a very
>     useful enhancement to be able to derive the in-channel and
>     near-channel emission masks from the database, but it is only if
>     it is complete.
>
>
>
>>     Speaking as another FCC certified database provider, we do supply
>>     a spectrum mask, and the response from the database is specified
>>     in terms of frequencies rather than channels.
>>
>>     As an industry reference, Wi-Fi has been using spectrum profiles
>>     with slopes for many years now (link to spec
>>     <mailto:[email-masked]> | 	408-230-0522 <tel:408-230-0522>
>>
>>
>>
>>         Speaking as an FCC certified TVWS database provider, we do
>>         not supply any information to the devices related to EIRP,
>>         PSD, mask or similar characteristics.
>>         It would seem from the thread that this method of specifying
>>         a "mask" (emission limits) does not address the known
>>         regulatory requirements in the United States, where a simple
>>         rectangle does not describe the emissions profile limits.

---

From: Andy Lee <[email-masked]>
Date: Thu, 24 Oct 2013 21:58:46 -0700

Thanks for the feedback, Benjamin,

> licensed incumbents usually starting with "none at all" as their definition
> and we negotiate from there, and it has never been trivial, easy or quick

Yes, you're absolutely right.  The definition of "no emission" has always
been a difficult one because the laws of physics make it impossible to
literally have 0 emissions.

That is why the FCC has their Part 15 rules.  They've made a decision (and
it's very similar in every jurisdiction around the world) that there is
some threshold, below which, a device is considered to be non-interfering
(see CFR 47, section
15.109<http://www.ecfr.gov/cgi-bin/retrieveECFR?n=47y1.0.1.1.16&r=PART#47:1.0.1.1.16.2.236.6>).
 The limit the FCC has chosen for the UHF band is 200 microvolts / meter @
3 meters distance, which is equivalent to -49.21 dBm, which is equivalent
to 0.000012 milliwatts.

These are the limits that have been applied to all electronic devices for
decades.  E.g., your laptop is allowed to operate in the same room as your
TV because it complies with FCC Part 15 rules (and your TV continues to
work properly).  The same is true of your cell phone, a toaster, the TV
itself, or any "black box", so long as their emissions stay below the
limits listed in the rules.

I think the emissions limits are very well defined, but what's not clear is
how much of this information should be included in the PAWS response.

I think it is perfectly reasonable for this additional data to be optional
in the PAWS response.  The regulations do not prohibit nor do they require
sending this information, so it is completely at the discretion of the
database to send or not send this information.

Are you suggesting that PAWS should tackle the (complex) task of defining
> the protocol needed to support dynamic spectrum management now?

As per the subject line of this thread, the question is whether the
spectrum encoding should be limited to "flat" segments, or if the encoding
should allows for "slopes".  From a pure encoding point of view, both
options have roughly equal data size and complexity requirements, but the
"slopes" encoding makes it possible to express things like the channel 37
constraints.

I think both encodings are pretty straightforward and could be brought to
market quickly.  I just think that the "flat" encoding is not expressive
enough for some of the things we see in the rules today and for some of the
use cases we see in industry.  The "slopes" encoding might not solve every
problem either, but I think it's a lot closer to meeting the needs that we
are able to identify today.

"Dynamic" and "management" are loaded words, but at some level, I do
believe that PAWS is already a protocol for dynamic spectrum management.
 If the FCC compacts the TV spectrum (e.g., 600 MHz NPRM), or if they
decide to make changes to the white space availability calculations in the
future, we expect all current-generation white space devices to
automatically comply with the new rules because they are being "managed" by
a database.  The FCC has the ability to re-shape the frequencies and power
levels used by devices, and they won't be stuck with legacy devices
polluting the spectrum.

We can discuss how to be "more dynamic" or how to achieve tighter levels of
"management" (micro-management?) of spectrum some other time.

Best regards,

On Thu, Oct 24, 2013 at 5:29 PM, Benjamin A. Rolfe <[email-masked]>wrote:

>  if, in the future Andy provides different characteristics my device may
>> no longer compliant with the rules and should not be operating.
>
>
> spectrum is the ability to have device automatically adapt when spectrum
> resources change (e.g., the "incentive auction" 600 MHz NPRM) or when
> protection rules need to be changed (e.g., interference is being reported
> and the calculations need to be modified).  It gives regulators the power
> to make tweaks to spectrum policy without having to displace a large
> installed base of devices.
>
>
> Many of us think this is a great idea, and as indicated in other posts to
> this list, a lot of work is going on in the standards development world
> around this idea.  All good. The currently defined rules for certifying a
> device do not support such a  model.  Not so good, but things will change
> eventually.
>
> information to encode the transmit power (intentional emissions) limits as
> defined by the current FCC rules. It is only part of the information, and
> part is not enough to be useful.
>
>
> licensed incumbents usually starting with "none at all" as their definition
> and we negotiate from there, and it has never been trivial, easy or quick.
> If your point is that things are assured to change, I have to agree
> enthusiastically.   As things change, I don't expect the specification of
> emission limits to get simpler.
>
>
> Are you suggesting that PAWS should tackle the (complex) task of defining
> the protocol needed to support dynamic spectrum management now?
>
> B
>
>
>  Best regards,
>
> On Thu, Oct 24, 2013 at 11:09 AM, Peter Stanforth <
> [email-masked]> wrote:
>
>> appealing - but not simple. Which is why my preference is still to put this
>> in version 2 and think through all the issues.
>> 802.11 DO NOT specify regulatory requirements, as such is out of scope of
>> 802.11 as clearly sated in the boilerplate to the standard:
>>
>> On Wed, Oct 23, 2013 at 8:47 AM, Peter Stanforth <
>> [email-masked]> wrote:
>>
>>>  Speaking as an FCC certified TVWS database provider, we do not supply
>>> any information to the devices related to EIRP, PSD, mask or similar
>>> characteristics.
>>> The device supplied FCCID tells us what the FCC compliance is (high
>>> power fixed, personal/portable mode 1 or 2) and we calculate protection,
>>> and respond with channel lists based on this.

---

From: Peter Stanforth <[email-masked]>
Date: Fri, 25 Oct 2013 07:33:04 -0400

Andy, First of all I didn’t mean to sound like I was picking on you. I still have a hard time speaking IETF, me, and not as our organization.  I agree with your thought on the key benefit of a DB. My question relates to how we resolve radio certification issues against policy updates implemented by the database.  In the example you cite about power limits we currently resolve that by FCCID (as an example we currently support a waiver for a low power fixed device (Specific FCCID) that gets treated differently than a high power fixed device) but all of this is taken care of inside the database.  We don’t have a situation where a device has to decide between it’s certified performance envelope and one provided by a database. Should be an easily solvable problem, but I suspect this is more of a regulatory issue than a technical/PAWS issue.

Peter S.

From: Andy Lee <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 24, 2013 at 7:35 PM
To: Peter Stanforth <[email-masked]<mailto:[email-masked]>>
Cc: "Benjamin A. Rolfe" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Question: Encode slopes?

Hi,

if, in the future Andy provides different characteristics my device may no longer compliant with the rules and should not be operating.

I'm not sure I understand this point or why anything would become non-compliant.  Whether PAWS sends the spectrum data with "flat" encoding or "sloped" encoding is independent of device compliance.  Supposing the FCC modifies the rules in the future and allows 50 mW and 120 mW instead of 40 mW and 100 mW limits, then the PAWS will update accordingly (no matter which encoding is used).

We've always held that one of the key benefits of database managed spectrum is the ability to have device automatically adapt when spectrum resources change (e.g., the "incentive auction" 600 MHz NPRM) or when protection rules need to be changed (e.g., interference is being reported and the calculations need to be modified).  It gives regulators the power to make tweaks to spectrum policy without having to displace a large installed base of devices.

>From a "black box" perspective, the emissions limits are what define whether a WSD will cause interference or not.  In very basic terms, if the emissions are low enough, there is no way for the device to cause interference.  The database is simply providing the WSD information so that it can configure operating parameters to stay below those emissions limits.

Best regards,

On Thu, Oct 24, 2013 at 11:09 AM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
The concept of the database acting as a policy  manager is very appealing - but not simple. Which is why my preference is still to put this in version 2 and think through all the issues.
Putting my device developer hat on I can’t reconcile the policy manager concept under current FCC rules. It is a Catch 22. Assuming I certify today it will be against a specific set of operating characteristics. I would expect Andy to provide those same characteristics in his implementation. However if, in the future Andy provides different characteristics my device may no longer compliant with the rules and should not be operating. However if I adjust the operating characteristics the device is no longer in compliance with its certification, and would be operating illegally. So either the “new” rule permits grandfathered operation or my device needs to be re-certified.  It seems like we have to convince Regulators to certify databases as policy managers and simply certify radios to ensure they comply with the policy they are given for this concept to work.

Best regards,

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

+lots

Ray

---

From: Andy Lee <[email-masked]>
Date: Fri, 25 Oct 2013 09:55:44 -0700

Hi Peter,

Thanks for the note.  No worries.  I think this is all new territory, not
only for us, but also the FCC and regulators around the world, so I think
it's great that we can discuss so many of these issues here.

As most people are probably aware, the FCC is currently working through the
600 MHz "incentive auction" process.  The probable outcome of this is that
the TV broadcasters will be compacted into a smaller set of channels, and
the white space rules will be updated accordingly.  I'm guessing that the
FCC does not plan on re-certifying all white space devices when those new
rules go into effect.  I suspect they will rely on the white space
databases to migrate existing devices to the new spectrum envelope.

Keep in mind that even today, device certification only tests that the
device is following the instructions of the database.  The device
certification does not care why a particular channel is available or not
(e.g., limited by TV, wireless mic, PLMRS/CMRS, MVPD, radio astronomy,
etc.), nor does it care why each channel has been assigned a particular
power level (e.g., 40 mW vs. 100 mW).  The information at the database can
(and does) change pretty frequently (e.g., updating TV transmitter data,
wireless mic registrations, etc.) without impacting the device's ability to
get certified.

We don’t have a situation where a device has to decide between it’s
> certified performance envelope and one provided by a database.

I'm not sure if I'm understanding this sentence correctly.  I think the
envelope provided by the database IS the envelope the device is expected to
conform to (the device doesn't have a choice in this matter).  If a device
fails to follow the database's instructions, it would be out of compliance,
and should not get certified.

If all certified devices are following database instructions properly, then
the FCC can instruct the databases to update their white space
calculations, and all devices will automatically comply with the new rules.

All the best,

On Fri, Oct 25, 2013 at 4:33 AM, Peter Stanforth
<[email-masked]>wrote:

> Andy, First of all I didn’t mean to sound like I was picking on you. I
> still have a hard time speaking IETF, me, and not as our organization.  I
> agree with your thought on the key benefit of a DB. My question relates to
> how we resolve radio certification issues against policy updates
> implemented by the database.  In the example you cite about power limits we
> currently resolve that by FCCID (as an example we currently support a
> waiver for a low power fixed device (Specific FCCID) that gets treated
> differently than a high power fixed device) but all of this is taken care
> of inside the database.  We don’t have a situation where a device has to
> decide between it’s certified performance envelope and one provided by a
> database. Should be an easily solvable problem, but I suspect this is more
> of a regulatory issue than a technical/PAWS issue.
>
> Peter S.
>
> From: Andy Lee <[email-masked]>
> To: Peter Stanforth <[email-masked]>
> Cc: "Benjamin A. Rolfe" <[email-masked]>, "[email-masked]" <
> [email-masked]>
>

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Fri, 25 Oct 2013 12:00:49 -0700

>     We don't have a situation where a device has to decide between
>     it's certified performance envelope and one provided by a database.
>
>
> I'm not sure if I'm understanding this sentence correctly.  I think 
> the envelope provided by the database IS the envelope the device is 
> expected to conform to (the device doesn't have a choice in this matter).

Well I don't know any other way to say this - with method proposed now 
for PAWS, the "envelope provided by the database" does not fully define 
he envelope that the device is expected to conform to per FCC 
regulations.  It addresses only one of many variables.

The FCC expects that the device will only transmit in the TV channels 
which the database says are available. When the FCC sells off some of 
these TV channels, the database will forever after exclude those 
channels from what is available. \
Existing devices will "adapt" because when they ask what they can use, 
the answer will never include those it can no longer use. That is simple 
enough.  The "envelope" has not changed in this case, and we don't need 
to know it to adapt to changes in what chunks of spectrum are available.

How a device transmits in those channels (i.e. the  "envelope" the 
signal must meet) is defined by a number of variables,  of which the TX 
power averaged over a frequency range (the TV channel) is only one. 
Notall are enumerated obviously in Subpart H of part 15 (the TVBD 
rules), as many are included by reference or implication (requirements 
inherited because it's part 15).  Right now the designer and the test 
house need work with what is hard coded  in the regulations.  To address 
dynamically adjusting to changes in the emissions requirements when 
using an available chunk of spectrum, we'd have to have a way to signal 
any and all of the parameters that currently are testing in conformance 
and quite possibly more.

There's a group in IEEE 1900 that is working on standards for dynamic 
spectrum.  I think it would be useful if PAWS and 1900.5 collaborated.

-B

>     Andy, First of all I didn't mean to sound like I was picking on
>     you. I still have a hard time speaking IETF, me, and not as our
>     organization.  I agree with your thought on the key benefit of a
>     DB. My question relates to how we resolve radio certification
>     issues against policy updates implemented by the database.  In the
>     example you cite about power limits we currently resolve that by
>     FCCID (as an example we currently support a waiver for a low power
>     fixed device (Specific FCCID) that gets treated differently than a
>     high power fixed device) but all of this is taken care of inside
>     the database.  We don't have a situation where a device has to
>     decide between it's certified performance envelope and one
>     provided by a database. Should be an easily solvable problem, but
>     I suspect this is more of a regulatory issue than a technical/PAWS
>     issue.
>
>     Peter S.
>
>     From: Andy Lee <[email-masked] <mailto:[email-masked]>>
>     Cc: "Benjamin A. Rolfe" <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>
>         device may no longer compliant with the rules and should not
>         be operating.
>
>
>      Supposing the FCC modifies the rules in the future and allows 50
>     mW and 120 mW instead of 40 mW and 100 mW limits, then the PAWS
>     will update accordingly (no matter which encoding is used).
>
>     spectrum resources change (e.g., the "incentive auction" 600 MHz
>     NPRM) or when protection rules need to be changed (e.g.,
>     interference is being reported and the calculations need to be
>     modified).  It gives regulators the power to make tweaks to
>     spectrum policy without having to displace a large installed base
>     of devices.
>
>     From a "black box" perspective, the emissions limits are what
>     define whether a WSD will cause interference or not.  In very
>     basic terms, if the emissions are low enough, there is no way for
>     the device to cause interference.  The database is simply
>     providing the WSD information so that it can configure operating
>     parameters to stay below those emissions limits.
>
>     Best regards,
>
>         The concept of the database acting as a policy  manager is
>         very appealing - but not simple. Which is why my preference is
>         still to put this in version 2 and think through all the issues.
>         Putting my device developer hat on I can't reconcile the
>         policy manager concept under current FCC rules. It is a Catch
>         22. Assuming I certify today it will be against a specific set
>         of operating characteristics. I would expect Andy to provide
>         those same characteristics in his implementation. However if,
>         in the future Andy provides different characteristics my
>         device may no longer compliant with the rules and should not
>         be operating. However if I adjust the operating
>         characteristics the device is no longer in compliance with its
>         certification, and would be operating illegally. So either the
>         "new" rule permits grandfathered operation or my device needs
>         to be re-certified.  It seems like we have to convince
>         Regulators to certify databases as policy managers and simply
>         certify radios to ensure they comply with the policy they are
>         given for this concept to work.
>
>         One should take careful note that the spectrum profiles used
>         in the 802.11 DO NOT specify regulatory requirements, as such
>         is out of scope of 802.11 as clearly sated in the boilerplate
>         to the standard:
>
>         requirements on an 802.11 device both as a transmitting device
>         (it should fall within the boundaries of the envelope given)
>         and as a receiving device (it must capture a signal that meets
>         these requirements and tolerate emissions within this envelope
>         spilling into the channel.  This does NOT assure regulatory
>         compliance anywhere on earth (or elsewhere).
>
>         makes this "mask" representation more useful.  I did go back
>         and review the emails on this topic and at least once it was
>         stated that the goal of this "mask" is to capture regulatory
>         requirements that may change from region to region, or over
>         time, so that an implementation may be adaptable instead of
>         having emission requirements hard coded. The current
>         representation does not seem to meet that goal.  The
>         addressing known regulations now and deal with enhancements
>         such as this in version 2, then I'd suggest removing the
>         "mask" representation from the draft for now, and add it when
>         the group feels it is appropriate to take the time to define
>         it completly.   To meet the current rules that are approved
>         for TVWS devices (FCC) we don't need the "mask" represented
>         (as at least one database has been approved without it).  It
>         would be a very useful enhancement to be able to derive the
>         in-channel and near-channel emission masks from the database,
>         but it is only if it is complete.
>
>
>
>>             Speaking as an FCC certified TVWS database provider, we
>>             do not supply any information to the devices related to
>>             EIRP, PSD, mask or similar characteristics.
>>             The device supplied FCCID tells us what the FCC
>>             compliance is (high power fixed, personal/portable mode 1
>>             or 2) and we calculate protection, and respond with
>>             channel lists based on this.
>>             All the device gets is a list of channels that it is
>>             legally allowed to operate on, based on the device
>>             classification provided.
>>
>>             It would seem from the thread that this method of
>>             specifying a "mask" (emission limits) does not address
>>             the known regulatory requirements in the United States,
>>             where a simple rectangle does not describe the emissions
>>             profile limits.
>>             This circles me back to the question I asked quite a
>>             while ago, which is how, as a device developer, do I use
>>             this information? What is the purpose of providing a "mask"?

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Fri, 25 Oct 2013 12:04:27 -0700

I am not sure if this email made it to the list. Matthew Sherman asked 
me to forward just in case.
Collaboration with 1900.5.2 seems like a good idea if  we are going to 
try and address dynamic spectrum management in a general sense (beyond  
just identifying the available frequency).

Sorry if ts is redundant.

Ben

-------- Original Message --------
Subject: 	RE: [paws] Question: Encode slopes?
Date: 	Thu, 24 Oct 2013 23:00:56 +0000
From: 	Stine, John A. <[email-masked]>
To: 	
CC: 	

Ben,

There are other standards bodies working on parts of this, specifically 
the IEEE Dynamic Spectrum Access Networks Standards Committee.  Work 
Group 1900.5 is addressing the use of policy and policy architectures.  
It currently has two active projects, 1900.5.1 which is developing a 
dynamic spectrum access policy language and 1900.5.2 which is creating 
spectrum consumption modeling methods.  These projects are not 
addressing the database architecture and messaging that is required for 
database managed spectrum management which we are expecting PAWS to do.  
These projects are focused on policy language and data models only.

I am personally working on the 1900.5.2 standard.  The spectrum 
consumption modeling methods are creating two things: a set of 
constructs with which to model the boundaries of spectrum use and a set 
of computations that can be used with the models to arbitrate whether 
any two models are compatible.  This combination allows databases to 
manage coexistence, incumbents to add spectrum to the database system 
(the models provide the equivalent of contours), for pairs of users to 
negotiate sharing, and for the whole process to create geospatial policy 
by default. They commoditize spectrum.

The 1900.5.2 standards project has just started.  The project 
authorization request was approved in March.  The WG is currently 
producing a requirements and use case document but in the end will 
likely use methods developed in MITRE's internal research program on 
Model-Based Spectrum Management.  The spectrum consumption models we 
propose provide the means to model full spectrum masks with slopes, the 
susceptibility to interference of receivers with underlay masks that 
also have slopes and a whole lot more.

I encourage you to look into participating.  I am sure if you ask, Mat 
Sherman, our chair, will gladly add you or anyone else interested to the 
group's email list and if you are willing to participate, to the group.

John Stine

    Putting my device developer hat on I can't reconcile the policy
    manager concept under current FCC rules. It is a Catch 22. Assuming
    I certify today it will be against a specific set of operating
    characteristics. I would expect Andy to provide those same
    characteristics in his implementation. However if, in the future
    Andy provides different characteristics my device may no longer
    compliant with the rules and should not be operating. However if I
    adjust the operating characteristics the device is no longer in
    compliance with its certification, and would be operating illegally.
    So either the "new" rule permits grandfathered operation or my
    device needs to be re-certified.  It seems like we have to convince
    Regulators to certify databases as policy managers and simply
    certify radios to ensure they comply with the policy they are given
    for this concept to work.

    One should take careful note that the spectrum profiles used in the
    802.11 DO NOT specify regulatory requirements, as such is out of
    scope of 802.11 as clearly sated in the boilerplate to the standard:

    The mask specified in annex D of 802.11-2012 specifies requirements
    on an 802.11 device both as a transmitting device (it should fall
    within the boundaries of the envelope given) and as a receiving
    device (it must capture a signal that meets these requirements and
    tolerate emissions within this envelope spilling into the channel. 
    This does NOT assure regulatory compliance anywhere on earth (or
    elsewhere).

    With that out of the way,  Andy's suggestion below ceertainly makes
    this "mask" representation more useful.  I did go back and review
    the emails on this topic and at least once it was stated that the
    goal of this "mask" is to capture regulatory requirements that may
    change from region to region, or over time, so that an
    implementation may be adaptable instead of having emission
    requirements hard coded. The current representation does not seem to
    meet that goal.  The enhancements that Andy shows below would come
    closer.

    If the current desire of the majority is to "get on with it"
    addressing known regulations now and deal with enhancements such as
    this in version 2, then I'd suggest removing the "mask"
    representation from the draft for now, and add it when the group
    feels it is appropriate to take the time to define it completly.  
    To meet the current rules that are approved for TVWS devices (FCC)
    we don't need the "mask" represented (as at least one database has
    been approved without it).  It would be a very useful enhancement to
    be able to derive the in-channel and near-channel emission masks
    from the database, but it is only if it is complete.

        section D.2.3 Transmit Spectrum Mask requirements.  The

        Inline image 1

        Best regards,

        Andy Lee |

          Google Inc. |

          408-230-0522

        It would seem from the thread that this method of specifying a
        "mask" (emission limits) does not address the known regulatory
        requirements in the United States, where a simple rectangle does
        not describe the emissions profile limits.
        This circles me back to the question I asked quite a while ago,
        which is how, as a device developer, do I use this information? 
        What is the purpose of providing a "mask"?
        Related question: Do the current FCC approved databases provide
        this "mask" information now?
        Thanks
        Ben

            +lots

            Ray

            paws mailing list

---

From: Andy Lee <[email-masked]>
Date: Fri, 25 Oct 2013 14:47:46 -0700

>
> The "envelope" has not changed in this case, and we don't need to know it
> to adapt to changes in what chunks of spectrum are available.

Today, the "envelope" does change.  It's more than just a channel on/off
response.  Power limits are also part of the current response.  A
personal/portable device is normally allowed to operate at 100 mW on open
white space channels.  However, if the device is inside the protection
contour on an adjacent channel, the power limit is reduced to 40 mW (it's
possible for a mix of 100 and 40 mW channels to be part of the response).
 In other words, both the frequency and power limits are specified for each
valid white space channel.

At any time (e.g., after the incentive auctions), the FCC can modify the
rules.  The calculated frequencies and power limits for white space could
change, and the new "envelope" of frequencies and power levels would go out
to all devices.  The future rules might even specify different power levels
not necessarily restricted to just 100 and 40 mW values.

On Fri, Oct 25, 2013 at 12:00 PM, Benjamin A. Rolfe <[email-masked]>wrote:

> conform to (the device doesn't have a choice in this matter).
>
>
> Well I don't know any other way to say this - with method proposed now for
> PAWS, the "envelope provided by the database" does not fully define he
> envelope that the device is expected to conform to per FCC regulations.  It
> addresses only one of many variables.
>
> which the database says are available. When the FCC sells off some of these
> TV channels, the database will forever after exclude those channels from
> what is available. \
> Existing devices will "adapt" because when they ask what they can use, the
> answer will never include those it can no longer use. That is simple
> enough.  The "envelope" has not changed in this case, and we don't need to
> know it to adapt to changes in what chunks of spectrum are available.
>
> How a device transmits in those channels (i.e. the  "envelope" the signal
> must meet) is defined by a number of variables,  of which the TX power
> averaged over a frequency range (the TV channel) is only one. Notall are
> enumerated obviously in Subpart H of part 15 (the TVBD rules), as many are
> included by reference or implication (requirements inherited because it's
> part 15).  Right now the designer and the test house need work with what is
> hard coded  in the regulations.  To address dynamically adjusting to
> changes in the emissions requirements when using an available chunk of
> spectrum, we'd have to have a way to signal any and all of the parameters
> that currently are testing in conformance and quite possibly more.
>
> On Fri, Oct 25, 2013 at 4:33 AM, Peter Stanforth <[email-masked]
> > wrote:
>
>>> an 802.11 device both as a transmitting device (it should fall within the
>>>> This circles me back to the question I asked quite a while ago, which
>>>> is how, as a device developer, do I use this information?  What is the

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Mon, 28 Oct 2013 12:33:46 -0700

To be technically clear: the spectral characteristics required to meet 
the regulations will not change from what is currently hard-coded  in 
the regulations until the FCC takes a regulatory action.   Which maximum 
TX power limit for a portable/personal TVBD is applies (100mW or 40mW) 
is determined by device designer and verified at device certification.

What we have today is (part of the story per 15.709(a)):  A fixed device 
is currently allowed one watt per 6 megahertz of bandwidth; A 
portable/personal device is allowed 100mW per 8 megahertz of bandwidth 
if it  meets all adjacent channel separation requirements in §15.712(a) 
and further limited to 40mW if it does not.  15.712(a) defines field 
strength contours for each TV channel referencing the method defined in 
part 73.684 (73.684 provides a propagation model and methodology for 
estimating the emissions footprint over a physical area). All devices 
must operate with adjacent channel emissions at least 72.8 dB below the 
fundamental (highest average power in the 6MH channel being used).  For 
use of 602-620 MHz there are additional limits expressed as 
dBuV/meter/120kHz.  There are additional limits which must be met for 
power spectral density, measured in any 100kHz of he occupied bandwidth, 
that depend on device type:

(5) The power spectral density conducted from the TVBD to the antenna 
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.2 dBm.
(ii) Personal/portable devices operating adjacent to occupied TV 
channels: -1.8 dBm.
(iii) Sensing-only devices: -0.8 dBm.
(iii) All other personal/portable devices: 2.2 dBm.

(for this one you need to know if the channel you are using is adjacent 
to a channel being used by a TV station).

The maximum TX power averaged over the 6MHz channel are conducted limits 
(measured with a wire connected to the transmitter output).  The PSD is 
field strength.  The adjacent channel requirements in 15.712 are 
specified as field strength at various distances and transmit duty cycle 
using a complicated methodology and specific propagation model.   Of 
course all TVBDs also must meet all the other requirements of Part 15 
applicable to intentional radiators and of course any practical TVBD 
will have to meet the part 5 requirements for unintentional radiators.

None of the above changes with time at the moment, it is  hard coded in 
the regulations and you can determine what is allowed by the TV channel. 
There has been some discussion about altering the rules to allow for 
dynamically specifying a different TX power maximum based on the 
services actually present at a given time, but I have not seen anything 
published by FCC yet.

If the goal of the group is to have the ability to convey all 
information required fora device to adjust it's transmit signal 
characeristics to adapt to changes in regulatory requirements which 
effect the transmit signal profile, then a lot more information is 
required and in fact the only way I see it being plausible is if the 
regulators adopt a common information model for modeling emission 
limits, which is a cool thing to do but might be out of scope of his group?.

I agree with Andy that we will, eventually, have regulations in the US 
that provide for power levels dynamically adjusted based on what other 
uses and users are in the channel or nearby channels. This is necessary 
for FCC to meet it's direction to manage more efficient use of he 
spectrum.  Honestly, I do not yet know what that will look like.

Hope this helps. Sorry if this is redundant (especially for all the 
other radioheads, to whom I appologize for over-simplifying things).

B

On 10/25/2013 2:47 PM, Andy Lee wrote:
>
>     The "envelope" has not changed in this case, and we don't need to
> Today, the "envelope" does change.  It's more than just a channel 
> on/off response.  Power limits are also part of the current response. 
>  A personal/portable device is normally allowed to operate at 100 mW 
> on open white space channels.  However, if the device is inside the 
> protection contour on an adjacent channel, the power limit is reduced 
> to 40 mW (it's possible for a mix of 100 and 40 mW channels to be part 
> of the response).  In other words, both the frequency and power limits 
> are specified for each valid white space channel.
>
> At any time (e.g., after the incentive auctions), the FCC can modify 
> the rules.  The calculated frequencies and power limits for white 
> space could change, and the new "envelope" of frequencies and power 
> levels would go out to all devices.  The future rules might even 
> specify different power levels not necessarily restricted to just 100 
> and 40 mW values.
>
>
> On Fri, Oct 25, 2013 at 12:00 PM, Benjamin A. Rolfe 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>>         We don’t have a situation where a device has to decide
>>         between it’s certified performance envelope and one provided
>>         by a database.
>>
>>
>>     I'm not sure if I'm understanding this sentence correctly.  I
>>     think the envelope provided by the database IS the envelope the
>>     device is expected to conform to (the device doesn't have a
>>     choice in this matter).
>
>     Well I don't know any other way to say this - with method proposed
>     now for PAWS, the "envelope provided by the database" does not
>     fully define he envelope that the device is expected to conform to
>     per FCC regulations.  It addresses only one of many variables.
>
>     The FCC expects that the device will only transmit in the TV
>     channels which the database says are available. When the FCC sells
>     off some of these TV channels, the database will forever after
>     exclude those channels from what is available. \
>     Existing devices will "adapt" because when they ask what they can
>     use, the answer will never include those it can no longer use.
>     That is simple enough.  The "envelope" has not changed in this
>     case, and we don't need to know it to adapt to changes in what
>     chunks of spectrum are available.
>
>     signal must meet) is defined by a number of variables,  of which
>     the TX power averaged over a frequency range (the TV channel) is
>     only one. Notall are enumerated obviously in Subpart H of part 15
>     (the TVBD rules), as many are included by reference or implication
>     (requirements inherited because it's part 15).  Right now the
>     designer and the test house need work with what is hard coded  in
>     the regulations.  To address dynamically adjusting to changes in
>     the emissions requirements when using an available chunk of
>     spectrum, we'd have to have a way to signal any and all of the
>     parameters that currently are testing in conformance and quite
>     possibly more.
>
>     There's a group in IEEE 1900 that is working on standards for
>     dynamic spectrum.  I think it would be useful if PAWS and 1900.5
>     collaborated.
>
>     -B
>
>
>
>>
>>         Andy, First of all I didn’t mean to sound like I was picking
>>         on you. I still have a hard time speaking IETF, me, and not
>>         as our organization.  I agree with your thought on the key
>>         benefit of a DB. My question relates to how we resolve radio
>>         certification issues against policy updates implemented by
>>         the database.  In the example you cite about power limits we
>>         currently resolve that by FCCID (as an example we currently
>>         support a waiver for a low power fixed device (Specific
>>         FCCID) that gets treated differently than a high power fixed
>>         device) but all of this is taken care of inside the database.
>>          We don’t have a situation where a device has to decide
>>         between it’s certified performance envelope and one provided
>>         by a database. Should be an easily solvable problem, but I
>>         suspect this is more of a regulatory issue than a
>>         technical/PAWS issue.
>>
>>         Peter S.
>>
>>             if, in the future Andy provides different characteristics
>>             my device may no longer compliant with the rules and
>>             should not be operating.
>>
>>
>>         I'm not sure I understand this point or why anything would
>>         become non-compliant.  Whether PAWS sends the spectrum data
>>         with "flat" encoding or "sloped" encoding is independent of
>>         device compliance.  Supposing the FCC modifies the rules in
>>         the future and allows 50 mW and 120 mW instead of 40 mW and
>>         100 mW limits, then the PAWS will update accordingly (no
>>         matter which encoding is used).
>>
>>         We've always held that one of the key benefits of database
>>         managed spectrum is the ability to have device automatically
>>         adapt when spectrum resources change (e.g., the "incentive
>>         auction" 600 MHz NPRM) or when protection rules need to be
>>         changed (e.g., interference is being reported and the
>>         calculations need to be modified).  It gives regulators the
>>         power to make tweaks to spectrum policy without having to
>>         displace a large installed base of devices.
>>
>>         basic terms, if the emissions are low enough, there is no way
>>         for the device to cause interference.  The database is simply
>>         providing the WSD information so that it can configure
>>         operating parameters to stay below those emissions limits.
>>
>>         Best regards,
>>
>>             The concept of the database acting as a policy  manager
>>             is very appealing - but not simple. Which is why my
>>             preference is still to put this in version 2 and think
>>             through all the issues.
>>             Putting my device developer hat on I can’t reconcile the
>>             policy manager concept under current FCC rules. It is a
>>             Catch 22. Assuming I certify today it will be against a
>>             specific set of operating characteristics. I would expect
>>             Andy to provide those same characteristics in his
>>             implementation. However if, in the future Andy provides
>>             different characteristics my device may no longer
>>             compliant with the rules and should not be operating.
>>             However if I adjust the operating characteristics the
>>             device is no longer in compliance with its certification,
>>             and would be operating illegally. So either the “new”
>>             rule permits grandfathered operation or my device needs
>>             Regulators to certify databases as policy managers and
>>             simply certify radios to ensure they comply with the
>>             policy they are given for this concept to work.
>>
>>             One should take careful note that the spectrum profiles
>>             used in the 802.11 DO NOT specify regulatory
>>             requirements, as such is out of scope of 802.11 as
>>             clearly sated in the boilerplate to the standard:
>>
>>             "Compliance with the provisions of any IEEE standards
>>             document does not imply compliance to any applicable
>>             regulatory requirements."
>>
>>             requirements on an 802.11 device both as a transmitting
>>             device (it should fall within the boundaries of the
>>             envelope given) and as a receiving device (it must
>>             capture a signal that meets these requirements and
>>             tolerate emissions within this envelope spilling into the
>>             channel. This does NOT assure regulatory compliance
>>             With that out of the way, Andy's suggestion below
>>             ceertainly makes this "mask" representation more useful.
>>             I did go back and review the emails on this topic and at
>>             least once it was stated that the goal of this "mask" is
>>             to capture regulatory requirements that may change from
>>             region to region, or over time, so that an implementation
>>             may be adaptable instead of having emission requirements
>>             hard coded. The current representation does not seem to
>>             meet that goal.  The enhancements that Andy shows below
>>             would come closer.
>>
>>             If the current desire of the majority is to "get on with
>>             it" addressing known regulations now and deal with
>>             enhancements such as this in version 2, then I'd suggest
>>             removing the "mask" representation from the draft for
>>             now, and add it when the group feels it is appropriate to
>>             take the time to define it completly. To meet the current
>>             rules that are approved for TVWS devices (FCC) we don't
>>             need the "mask" represented (as at least one database has
>>             been approved without it). It would be a very useful
>>             enhancement to be able to derive the in-channel and
>>             near-channel emission masks from the database, but it is
>>             only if it is complete.
>>
>>
>>
>>>             Speaking as another FCC certified database provider, we
>>>             do supply a spectrum mask, and the response from the
>>>             database is specified in terms of frequencies rather
>>>             than channels.
>>>
>>>              See section D.2.3 Transmit Spectrum Mask requirements.
>>>              The relationship between this transmit spectrum mask
>>>             and the TVWS emission limit mask is very relevant to
>>>             picking operating frequencies, especially around channel
>>>             37 and the band edges.
>>>
>>>             Inline image 1
>>>
>>>             Best regards,
>>>
>>>
>>>             <tel:408-230-0522>
>>>             <[email-masked]
>>>             <mailto:[email-masked]>> wrote:
>>>
>>>                 Speaking as an FCC certified TVWS database provider,
>>>                 we do not supply any information to the devices
>>>                 related to EIRP, PSD, mask or similar characteristics.
>>>                 compliance is (high power fixed, personal/portable
>>>                 mode 1 or 2) and we calculate protection, and
>>>                 To: "[email-masked] <mailto:[email-masked]>"
>>>                 <[email-masked] <mailto:[email-masked]>>
>>>
>>>                 specifying a "mask" (emission limits) does not
>>>                 address the known regulatory requirements in the
>>>                 United States, where a simple rectangle does not
>>>                 describe the emissions profile limits.
>>>                 while ago, which is how, as a device developer, do I
>>>                 use this information? What is the purpose of
>>>                 providing a "mask"?
>>>                 Related question: Do the current FCC approved
>>>                 databases provide this "mask" information now?
>>>                 Thanks
>>>                 Ben
>>>
>>>

---

From: Vincent Chen <[email-masked]>
Date: Tue, 29 Oct 2013 08:57:48 -0700

Ben,

Thanks for the details. Frankly, at this point, I can't tell whether you're
in support of a change from Draft 06.
Just to make it more concrete, I've included the proposed change to the
text and examples:

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}
    ],
    ...
  ]
}

The second version would allow adding points to form "sloped" profiles, if
desired, but is not required.

-vince

On Mon, Oct 28, 2013 at 12:33 PM, Benjamin A. Rolfe <[email-masked]>wrote:

> the regulations will not change from what is currently hard-coded  in the
> regulations until the FCC takes a regulatory action.   Which maximum TX
> power limit for a portable/personal TVBD is applies (100mW or 40mW) is
> determined by device designer and verified at device certification.
>
> portable/personal device is allowed 100mW per 8 megahertz of bandwidth if
> it  meets all adjacent channel separation requirements in §15.712(a) and
> further limited to 40mW if it does not.  15.712(a) defines field strength
> contours for each TV channel referencing the method defined in part 73.684 (73.684
> provides a propagation model and methodology for estimating the emissions
> footprint over a physical area). All devices must operate with adjacent
> channel emissions at least 72.8 dB below the fundamental (highest average
> power in the 6MH channel being used).  For use of 602-620 MHz there are
> additional limits expressed as dBuV/meter/120kHz.  There are additional
> limits which must be met for power spectral density, measured in any 100kHz
> of he occupied bandwidth, that depend on device type:****
>
> shall not be greater than the following values when measured in any 100 kHz
> band during any time interval of continuous transmission:
> (ii) Personal/portable devices operating adjacent to occupied TV channels:
> -1.8 dBm.
> (for this one you need to know if the channel you are using is adjacent to
> a channel being used by a TV station).
>
> field strength.  The adjacent channel requirements in 15.712 are specified
> as field strength at various distances and transmit duty cycle using a
> complicated methodology and specific propagation model.   Of course all
> TVBDs also must meet all the other requirements of Part 15 applicable to
> intentional radiators and of course any practical TVBD will have to meet
> the part 5 requirements for unintentional radiators.
>
> dynamically specifying a different TX power maximum based on the services
> actually present at a given time, but I have not seen anything published by
> FCC yet.
>
> If the goal of the group is to have the ability to convey all information
> required fora device to adjust it's transmit signal characeristics to adapt
> to changes in regulatory requirements which effect the transmit signal
> profile, then a lot more information is required and in fact the only way I
> see it being plausible is if the regulators adopt a common information
> model for modeling emission limits, which is a cool thing to do but might
> be out of scope of his group?.
>
> that provide for power levels dynamically adjusted based on what other uses
> and users are in the channel or nearby channels. This is necessary for FCC
> to meet it's direction to manage more efficient use of he spectrum.
> Honestly, I do not yet know what that will look like.
>
> Hope this helps. Sorry if this is redundant (especially for all the other
> radioheads, to whom I appologize for over-simplifying things).
>
> B
>
>
>
>
>
>  The "envelope" has not changed in this case, and we don't need to know
>> it to adapt to changes in what chunks of spectrum are available.
>
>
>> for PAWS, the "envelope provided by the database" does not fully define he
>> On Fri, Oct 25, 2013 at 4:33 AM, Peter Stanforth <
>>>  if, in the future Andy provides different characteristics my device
>>>> may no longer compliant with the rules and should not be operating.
>>>
>>>
>>>> emails on this topic and at least once it was stated that the goal of this
>>>> "mask" is to capture regulatory requirements that may change from region to
>>>> region, or over time, so that an implementation may be adaptable instead of
>>>> having emission requirements hard coded. The current representation does
>>>> not seem to meet that goal.  The enhancements that Andy shows below would
>>>> come closer.
>>>>
>>>>> supply any information to the devices related to EIRP, PSD, mask or similar
>>>>> characteristics.
>>>>> All the device gets is a list of channels that it is legally allowed
>>>>> to operate on, based on the device classification provided.
>>>>>
>>>>> "mask" (emission limits) does not address the known regulatory requirements
>>>>> in the United States, where a simple rectangle does not describe the

-- 
-vince

---

From: Ray Bellis <[email-masked]>
Date: Tue, 29 Oct 2013 16:57:18 +0000

On 29 Oct 2013, at 15:57, Vincent Chen <[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

---

From: Andy Lee <[email-masked]>
Date: Tue, 29 Oct 2013 11:23:23 -0700

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,

On Tue, Oct 29, 2013 at 9:57 AM, Ray Bellis <[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
>

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 29 Oct 2013 15:02:39 -0400

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,

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

Ray

---

From: Andy Lee <[email-masked]>
Date: Tue, 29 Oct 2013 13:07:46 -0700

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,

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.
>
> To: Ray Bellis <[email-masked]>
>

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 29 Oct 2013 16:33:21 -0400

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,

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,

Ray

---

From: Andy Lee <[email-masked]>
Date: Tue, 29 Oct 2013 13:50:51 -0700

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,

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.
>
>
> Cc: Ray Bellis <[email-masked]>, "[email-masked]" <[email-masked]
> >
>
> On Tue, Oct 29, 2013 at 12:02 PM, Peter Stanforth <
>>> 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