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