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 protected] [mailto:[email protected]] On Behalf Of
Benjamin A. Rolfe
Sent: Thursday, October 24, 2013 2:58 PM
Cc: [email protected]
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.
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
