I have a couple of concerns. 1. why have we not submitted option 2 months ago 2. In that we have the ability to revise every 6 months which is not something most other SDO’s can do, there is no reason to try and have other things in there in one FINAL and ONLY PAWS protocol which I seem to be seeing some want to do and therefore add things now when in fact, we can adapt easily and make changes, work with other groups, and keep up to date with the different requirements likely to change.
Sincerely, Nancy On Nov 1, 2013, at 2:45 PM, Peter Stanforth <[email protected]> wrote: > With all due respect you are not listing to what I am saying. > 1 I agree that providing more flexible API and more information is what we > should aim for with PAWS. > 2 You were implying, incorrectly, that the current V6 PAWS protocol could not > support the FCC rules, It can and does. We have implemented this protocol. I > am not sure why that is ‘proprietary'. > 3 my only issue is that this is not fully thought out and we also need to get > a PAWS protocol out the door. So I am trying to put this capability into a > future iteration so we can do it justice. > > > From: Andy Lee <[email protected]> > Date: Friday, November 1, 2013 at 4:46 PM > To: Peter Stanforth <[email protected]> > Cc: "[email protected]" <[email protected]>, Protocol to Access White > Space database <[email protected]> > Subject: Re: [paws] Question: Encode slopes? > > Most (perhaps all) of the device and database certifications that have been > completed thus far have used proprietary interfaces. They have not relied on > a *draft* PAWS specification. And there are other certified devices which do > get more than just a channel list. > > We're not aiming for the least common denominator here. There are many use > cases that could take advantage of this information. Just because there is > one implementation that doesn't use this feature, that doesn't mean the > protocol shouldn't support it. The FCC's testing rules clearly indicate that > it is OK for a device to rely on information from the database to meet > compliance. Just because one company decides not to make use of this > capability does not mean that others will come to the same conclusion. And > the PAWS protocol should accommodate both. > > The protocol is already not about "channels", which is a good thing, since > this is picking up steam internationally. There is also substantial work > being done in other bands that are leaning towards spectrum databases and > PAWS. Some of these other bands have no concept of channels at all. > > What's the justification for the old, less capable encoding? The old > encoding does not follow any of the common practices used in the radio device > industries. I think we should strongly consider following the lead of IEEE > 802.11 and other technologies that will be the most likely users of white > space. > > > Andy Lee | Google Inc. | [email protected] | 408-230-0522 > > > On Fri, Nov 1, 2013 at 1:24 PM, Peter Stanforth <[email protected]> > wrote: >> The FCC does not require the DB to provide any mask information. That can be >> validated by the 5 certified radios that are not getting anything but a >> channel list from a certified database. >> I am still not convinced that, under current FCC rules, they will accept >> anything but a channel list. I don’t think they will object to a DB >> providing such information but they certainly do not require it. >> >> From: Andy Lee <[email protected]> >> Date: Friday, November 1, 2013 at 4:17 PM >> To: "[email protected]" <[email protected]> >> Cc: Peter Stanforth <[email protected]>, Protocol to Access White >> Space database <[email protected]> >> >> Subject: Re: [paws] Question: Encode slopes? >> >> What and how to encode is already defined in the FCC rules (the values have >> been referenced in previous messages). The values are explicitly given to >> us, and we just need a way to include it in a PAWS message. >> >> The current encoding does not support the encoding of those values >> (including slopes). A new encoding has been proposed that does support the >> FCC parameters. >> >> What is the justification for sticking with the less capable encoding? The >> old encoding is incapable of supporting a use case that's been identified in >> the current rules. >> >> >> Andy Lee | Google Inc. | [email protected] | 408-230-0522 >> >> >> On Fri, Nov 1, 2013 at 7:50 AM, <[email protected]> wrote: >>> Even if things are hard coded in firmware, an update to firmware could >>> bring the product up-to-date with the changed rules. Of course, it might be >>> more flexible to have that info delivered over paws, but the discussions on >>> this list do not indicate any consensus on what and how to encode. >>> Most people resist to changing the current encoding in draft -06. Since we >>> were not able to conclude this discussion in time and submit a revised >>> version of the document before the deadline, we can keep continue >>> discussing this encoding issue for a few more days, but I’d like to >>> conclude it by the F2F. So far, no conclusion in changing the current >>> encoding, and unless a miracle happens in the next few days, this will be >>> the conclusion, as we need to move forward. >>> There will be a separate discussion sometime in the future on whether to >>> create a paws version 2, and if yes, then what should be included in there. >>> But before that discussion happens we need to get the current protocol out >>> of the door. >>> -Gabor >>> >>> >>> From:[email protected] [mailto:[email protected]] On Behalf Of ext >>> Andy Lee >>> Sent: Tuesday, October 29, 2013 1:51 PM >>> To: Peter Stanforth >>> Cc: [email protected] >>> >>> Subject: Re: [paws] Question: Encode slopes? >>> >>> >>> Hi Peter, >>> >>> I think that channels 36 and 38 were merely being offered as examples, >>> hence the "e.g.". Perhaps it's a matter of interpretation, but it seems >>> pretty clear to me that the purpose of this note is to allow the device >>> under test (DUT) to use information from the database to meet compliance >>> requirements, if it so chooses. It is not forced to have those constraints >>> hard-coded in the firmware. >>> >>> This leaves open the possibility for the FCC to change, add, or remove the >>> constrains around channel 37 in the future. If a device chooses to have >>> hard-coded constraints in their firmware, they may end up missing out on >>> some spectrum opportunities that might be permitted in future rule >>> modifications. >>> >>> Best regards, >>> >>> >>> Andy Lee | >>> Google Inc. | >>> [email protected] | >>> 408-230-0522 >>> >>> >>> On Tue, Oct 29, 2013 at 1:33 PM, Peter Stanforth <[email protected]> >>> wrote: >>> The note you reference in the test procedure is ambiguous, there is no >>> reference to channels 36-38 in part two and no mention of tests to lock out >>> unauthorized channels, or a definition of what that really means. So I can >>> only base our interpretation on what we have been required to do to pass >>> WSD certification. The FCC being the final judge of that. The way we have >>> been required (By we I mean the DUT) to operate it that the DUT cannot have >>> it’s compliance overridden by the database. A specific example. A DUT was >>> having trouble complying with the channel 37 requirement and the >>> manufacturer made the decision to block any use of channels around it in >>> the firmware – to get a product out and allow them to rework the RF later. >>> A test was required to prove that if the database provided those blocked >>> channels as options that the DUT would in fact not operate on them, in >>> order to get FCC certification. >>> Further the requirement you reference is about permission to use a channel >>> not OOB emissions. (15.709(c)(4) which is what I was referring to. >>> >>> I still don’t think defining the mask is a bad idea, though I think there >>> are better ways of doing it than we are talking about, but I do think this >>> discussion belongs in a new version of PAWS where we can describe the >>> requirements and define the behavior comprehensively. It is not required to >>> support FCC or Ofcom management of WSDs. Which was the basis of the current >>> PAWS requirements. >>> >>> >>> From: Andy Lee <[email protected]> >>> Date: Tuesday, October 29, 2013 at 4:07 PM >>> To: Peter Stanforth <[email protected]> >>> Cc: Ray Bellis <[email protected]>, "[email protected]" <[email protected]> >>> >>> Subject: Re: [paws] Question: Encode slopes? >>> >>> Hi Peter, >>> >>> Thanks for the link. The rules actually DO allow for these constraints to >>> come from the database (and defer to Part 2 for testing). The rules in >>> Part 1 are as follows: >>> >>> <image001.png> >>> >>> Best regards, >>> >>> >>> Andy Lee | >>> Google Inc. | >>> [email protected] | >>> 408-230-0522 >>> >>> >>> On Tue, Oct 29, 2013 at 12:02 PM, Peter Stanforth >>> <[email protected]> wrote: >>> Andy >>> The statement “White space devices must comply one way or another” is >>> inconsistent with the testing process we have been required to use to get >>> FCC certification (5 WSDs so far), and I suggest that you cannot currently >>> certify a device that does not have the conformance encoded in the >>> firmware. Specifically: In order to certify a White Space Device the device >>> must be certified against the FCC test process >>> (https://apps.fcc.gov/kdb/GetAttachment.html?id=Rnszbl7%2BTh%2FUqEwk%2FztsOQ%3D%3D >>> ), which consists of two independent parts. Part 1: Radio Frequency >>> (RF) Certification Tests, tests the RF characteristics independent of the >>> database, and includes conformance with channel 37 limits (iv. Measurements >>> in the 602-620 MHz band ( TV channels 36-38)) - which means the behavior >>> has to be encoded in the device. >>> It is only after they have completed the Part 1 test that they run the Part >>> 2 test: Database Interface Certification Tests, which is to validate the >>> behavior of the radio with the database. >>> So to permit constraints to be managed by a WSDB, as you suggest, would >>> require changes to the current TCB process defined by the FCC. >>> Peter S. >>> >>> From: Andy Lee <[email protected]> >>> Date: Tuesday, October 29, 2013 at 2:23 PM >>> To: Ray Bellis <[email protected]> >>> >>> Cc: "[email protected]" <[email protected]> >>> Subject: Re: [paws] Question: Encode slopes? >>> >>> Hi, >>> >>> A couple of comments: >>> The constraints on channels 36 and 38 are part of the current FCC rules. >>> White space devices must comply with this requirement one way or another, >>> whether this information comes from the database or if it's somehow encoded >>> into the device firmware. The FCC allows for either kind of >>> implementation, and PAWS should be supportive of this. >>> PAWS is not limited to the FCC or the TV band. We want to be cognizant of >>> emerging rules in other jurisdictions, in other bands, and with the current >>> state of radio technologies. This is (hopefully) an international standard >>> that is not bound to any one country's rules or any one company's >>> implementation. >>> All else being equal, why not choose an encoding that is a better match for >>> all currently known rules and radio technologies? >>> >>> Respectfully, >>> >>> >>> Andy Lee | >>> Google Inc. | >>> [email protected] | >>> 408-230-0522 >>> >>> >>> On Tue, Oct 29, 2013 at 9:57 AM, Ray Bellis <[email protected]> >>> wrote: >>> >>> On 29 Oct 2013, at 15:57, Vincent Chen <[email protected]> wrote: >>> >>> > Just to make it more concrete, I've included the proposed change to the >>> > text and examples: >>> >>> I do NOT support this change. All of the observations I made in my message >>> of 9th October still apply. >>> >>> The only potentially valid use case I've seen for non-zero slopes are the >>> FCC limits for channels 36 and 38, and we've heard from Spectrum Bridge >>> that this isn't an issue. >>> >>> Ray >>> >>> _______________________________________________ >>> paws mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >>> >> > > <image001.png>_______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
