Sorry, meant to send to Andy, Gabor and the group as well. On Nov 1, 2013, at 3:02 PM, Nancy Bravin <[email protected]> wrote:
> 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
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
