Hi Ben, How are things? Long time no see...
I don't think I'm on the PAWS reflector but I copied a couple of names from this thread to the cc. Just to echo what John said, we are very much interested in opening a dialogue with the PAWS group. We believe that our work complements what is being done in PAWS and we are hopeful we can get some cross fertilization. A few of us have started thinking about how 1900.5 can be leveraged in some future version of PAWS. Perhaps someone from PAWS could come to 1900.5 to make a presentation so we would have a greater awareness of your activities and vice versa? Much of our work is by teleconference so if someone wanted to listen in or contribute it would be easy to do. Please feel free to contact me if there is interest. Mat Matthew Sherman, Ph.D. Chair, IEEE 1900.5 BAE Systems - Electronic Systems (ES) email: [email protected]<mailto:[email protected]> Website: http://grouper.ieee.org/groups/dyspan/5/index.htm From: Stine, John A. [mailto:[email protected]] Sent: Thursday, October 24, 2013 7:01 PM To: Benjamin A. Rolfe Cc: [email protected]; Sherman, Matthew J. (US SSA) Subject: RE: [paws] Question: Encode slopes? 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]> [mailto:[email protected]] On Behalf Of Benjamin A. Rolfe Sent: Thursday, October 24, 2013 2:58 PM Cc: [email protected]<mailto:[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
