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 protected]>
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 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
