I was actually hoping to simplify things for devices. 1) Having a fully specified spectrum profile without discontinuities and without "special" values like -inf make it much easier to write the client side code. This minimizes the number of special edge cases that need to be handled by the parsing logic and "emission fitting" code on the client.
2) We still seem to be thinking in terms of TV channels only. PAWS is designed for other frequency bands too, and there won't always be such a distinct concept of on-channel vs. adjacent-channel emissions. 3) We don't know what future WSD technologies will be capable of. Wi-Fi already supports a long list of modulation types (e.g., BPSK, QPSK, DSSS, FHSS, OFDM) and channel widths. Software defined radios and other technologies can dynamically choose modulation types, channel widths, and power distribution. These agile radio technologies need the full spectrum profile to help them choose the right combination of emission parameters. WSDs are just a "black box" from the database's point of view. Andy Lee | Google Inc. | [email protected] | 408-230-0522 On Fri, Sep 20, 2013 at 2:35 PM, Peter Stanforth <[email protected]>wrote: > We have, until know, always worked on the assumption that the device would > be certified, or not, to comply with any out of band emissions. The FCC for > instance specifically tests the more stringent rule around channel 37, as > well as the more general case. The Database is not, and cannot be, the > enforcement agency. So simply providing a list of channels that it can use > is sufficient. > It should be of no consequence to a device why it cannot use a channel > other than to behave with its compliant emissions. > I agree with Gabor, why are we overly complicating this? > > From: "[email protected]" <[email protected]> > Date: Friday, September 20, 2013 4:54 PM > To: "[email protected]" <[email protected]>, "[email protected]" < > [email protected]> > Cc: "[email protected]" <[email protected]> > > Subject: Re: [paws] Spectrum encoding discussion > > Aren’t we talking past each other in this thread?**** > > If the rules are supposed to specify what is the max intended power level > a device can put into a channel (available or not), then I also think this > is what the DB should communicate to the device.**** > > If Ofcom specifies that the max leakage into an unavailable channel is > -33dbm, I assume the device will not be certified if it leaks more. If the > device supports multiple modulation types and one of them leaks more than > what is permitted in that regulatory domain, then the device will need to > know it, and in that regulatory domain avoid using that particular > modulation type. How does the device come to know it? Andy proposes the DB > to indicate that level for the unavailable channels. Others folks seem to > suggest a device built to operate under a certain ruleset has to implicitly > know it.**** > > Another way of looking at it might be to say that the max level of > permitted unintentional leakage into an adjacent channel is part of the > rulesetInfo, and the spectrum response only lists the available channels. > Could this be a way forward?**** > > - gabor**** > > ** ** > > *From:* [email protected] > [mailto:[email protected]<[email protected]>] > *On Behalf Of *ext Andy Lee > *Sent:* Friday, September 20, 2013 1:00 PM > *To:* Benjamin A. Rolfe > *Cc:* Protocol to Access White Space database > *Subject:* Re: [paws] Spectrum encoding discussion**** > > ** ** > > Hi Ben,**** > > ** ** > > And that means NO intentional radiation in the channel. **** > > ** ** > > If you are reading this as "transmitted emissions in band should be lower > than -33dBm" then, no, this is not the same as "no emissions" per FCC > rules. If one were to intentionally transmit at -33dBm where no intentional > emissions are allowed, that would not be the same as "no" under the rules. > **** > > ** ** > > There is certainly no intention to encourage any malicious behavior. In > general, we expect devices to be trying to do the right thing and just need > some information to understand where the boundaries are. These boundaries > include both intentional and unintentional emissions.**** > > ** ** > > Various modulation types have known spectral profiles, including both > in-band and out-of-band emissions. Knowing where the "shelf" is on the > adjacent channel makes it possible to match that with the "skirt" of the > intended modulation pattern. The "skirt" is not part of the intended > emission, but is important in trying to avoid causing interference on > adjacent channels.**** > > ** ** > > A crude example of this is shown in the following image:**** > > ** ** > > [image: Inline image 1]**** > > ** ** > > Best regards,**** > > > **** > > ** ** > > Andy Lee |**** > > Google Inc. |**** > > [email protected] |**** > > 408-230-0522**** > > ** ** > > On Fri, Sep 20, 2013 at 3:07 AM, Benjamin A. Rolfe <[email protected]> > wrote:**** > > ** ** > > On 9/19/2013 9:09 AM, Andy Lee wrote:**** > > The math bears that out, but nonetheless OFCOM are still effectively > proposing that *no* in-block transmissions are allowed in that channel.*** > * > > ** ** > > Same is true for the FCC. The FCC also assumes that "off" channels are > not used by WSDs.**** > > And that means NO intentional radiation in the channel. **** > > ** ** > > Specifying a low power level like -33 dBm is effectively the same thing as > specifying no in-band emissions there.**** > > ** ** > > If you are reading this as "transmitted emissions in band should be lower > than -33dBm" then, no, this is not the same as "no emissions" per FCC > rules. If one were to intentionally transmit at -33dBm where no intentional > emissions are allowed, that would not be the same as "no" under the rules. > **** > > > > > **** > > ** ** > > Even if someone did try to put an in-band emission there (regardless of > how impractical that actually is), it would be too low to cause > interference to anyone and no harm has been done to the "RF environment".* > *** > > Should be a little careful here for a couple reasons. I've designed and > shipped communication systems that operate quite well with transmit power > levels intentionally below -33dBm and do very useful things. It's pretty > easy to design a receive with sensitivity better than -96dBm, so an > intentional radiator at -33dBm near by will be noticed - at 900 MHz your > 10dB above sensitivity at 10m and at 54MHz you'd be 10 dB above sensitivity > at 100m, possibly. And when it comes to protecting their spectrum, people > always use the best propagation model to calculate interfence impact on > them :-). I've probably misunderstood something badly, but -33dBm is > certainly enough power to be noticed. > > I have tried the "too low to be noticed" argument a few times in the past > in regulatory discussions, and incumbent and/or protected users usually set > the threshold closer to -120dBm and usually argue that even at really low > TX power, the "aggregate impact" of multiple devices in the "RF > Environment" is an unacceptable impact. We had trouble with this argument > when the intentional radiator TX limit was below the maximum unintentional > emission limits for most non-transmitting devices (-41.3dBm). > > So it would be fairly important to ensure a device does not interpret > -33dBm as it's ok to use that channel so long as it's TX power is below > -33dBm. > > I may be off base here because of how y'all see the DB providing and what > I am expecting to support future needs. "protected users" includes more > than TV stations in the US. > > Not sure that helps, but hope so. **** > > > > > **** > > ** ** > > The advantage of having an "well behaved" spectrum profile (contiguous and > without special values like -inf) is that the channel selection algorithm > on the WSDs becomes much simpler and logical. There's no need to have lots > of special boundary condition checks and code paths that only get triggered > under special circumstances. I'd like to avoid ambiguous interpretations > on the device side as much as possible.**** > > Certainly ambiguous interpretations on the device side are a bad thing. > > Some apps are aggregating multiple TV channels to get a logical channel > that that can carry a 'wide' data pipe. Other uses can fit many useful > channels in one TV channel. In 802.15.4m we divide the TV channel up into > multiple physical channels carrying low data rate signals. Right now we > assume a peak power level for the TV channel, and we get that value with > the start frequency and width (or end frequency) from the database. > However, I've heard it proposed to the FCC that we may get different power > limits different parts of the TV channel, changing over time, as a > protection mechanism for deal with narrow band protected users while > allowing effective use of the rest of the TV channel. For what we do, this > is a good thing - our physical channel may be less than 200kHz wide. There > are a LOT of applications in IoT that need < 200kHz channels, and > blocking an entire TV channel to protect a wireless microphone using < > 200kHz of it means there are 28 other usable channels not being used - not > efficient use of the spectrum. > > Hope this helps. > > -Ben > > > **** > > > **** > > ** ** > > Andy Lee |**** > > Google Inc. |**** > > [email protected] |**** > > 408-230-0522**** > > ** ** > > On Thu, Sep 19, 2013 at 8:30 AM, Ray Bellis <[email protected]> > wrote:**** > > > On 19 Sep 2013, at 16:21, Andy Lee <[email protected]>**** > > wrote: > > > This actually shows that Ofcom has picked a power threshold on channel > 38 of -33 dBm. If you look at the ACLR numbers for class 3, 4, and 5 > devices, you'll see they are 10 dB apart from each other and that they all > work out to be -33 dBm on channel 38. > > > > The reason there are no limits for class 1 and 2 devices is because the > in-band power on channels 37 and 39 cannot exceed +36 dBm/8MHz, and > therefore the power on channel 38 will naturally be less than -33 dBm.**** > > The math bears that out, but nonetheless OFCOM are still effectively > proposing that *no* in-block transmissions are allowed in that channel. > > Per OFCOM / ETSI device interface requirements it would be incorrect for > us to actually send that value of -33 dBm to a device. > > Ray > > **** > > ** ** > > ** ** > > _______________________________________________**** > > paws mailing list**** > > [email protected]**** > > https://www.ietf.org/mailman/listinfo/paws**** > > ** ** > > > _______________________________________________ > 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
