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 protected] <mailto:[email protected]>>
Date: Wednesday, October 23, 2013 at 7:30 PM
Cc: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
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.
Inline image 1
Best regards,
Andy Lee | Google Inc. | [email protected]
<mailto:[email protected]> | 408-230-0522
On Wed, Oct 23, 2013 at 8:47 AM, Peter Stanforth
<[email protected] <mailto:[email protected]>> 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 protected]
<mailto:[email protected]>>
Date: Wednesday, October 23, 2013 at 11:40 AM
To: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
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 10/23/2013 1:44 AM, Ray Bellis wrote:
On 22 Oct 2013, at 17:07, Peter Stanforth<[email protected]>
<mailto:[email protected]> wrote:
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
_______________________________________________
paws mailing list
[email protected]
<mailto:[email protected]>https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
