> > what is the origin of the “-56.8” value for PSD that keeps cropping up in > the examples to indicate “not available”?
The FCC rules under 15.709(c)(1) require devices to have these adjacent channel emission limits to protect TV broadcasts. The "on" channels can be 16, 20, or 36 dBm EIRP, and the "off" channels have specific limits of -52.8, -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied by TV. Andy Lee | Google Inc. | [email protected] | 408-230-0522 On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel J <[email protected]>wrote: > I very much agree with Ray’s observations and resulting proposal. In > fact: this exact email was in draft form in my head…**** > > ** ** > > I may have a few things to add – but first, I have one technical question > first: what is the origin of the “-56.8” value for PSD that keeps cropping > up in the examples to indicate “not available”?**** > > ** ** > > Thanks,**** > > ** ** > > Dan Harasty**** > > ** ** > > ** ** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Ray Bellis > *Sent:* Monday, September 16, 2013 5:06 AM > *To:* Vincent Chen > *Cc:* [email protected] > *Subject:* Re: [paws] Encoding of spectrum profile**** > > ** ** > > ** ** > > On 13 Sep 2013, at 17:00, Vincent Chen <[email protected]>**** > > wrote:**** > > > > **** > > I see. Television channels do not occupy a contiguous range of > frequencies. In the US, **** > > ** ** > > - [54MHz, 72MHz] Channel 2-4**** > > - [76MHz, 88MHz] Channels 5-6**** > > - [174MHz, 216MHz] Channels 7-13**** > > - [470MHz, 698MHz] Channels 14-51**** > > ** ** > > So the response given by the database should not include any frequencies > not in the plan.**** > > ** ** > > That means a "spectrum profile" should be encoded as a list of "array" of > (frequency, power) points.**** > > - Each array represents a "profile" for a contiguous range of frequencies > **** > > - The range of frequencies within a list of profiles MUST be disjoint and > SHOULD be sorted**** > > - The entire set of frequency bands defined by the regulatory domain MUST > be represented by a single list of "profiles"**** > > (rather than split them across multiple lists)**** > > ** ** > > That last point is to remove ambiguity and, thus, variations in database > implementation, to simplify logic on devices.**** > > ** ** > > Example:**** > > ** ** > > ...**** > > > > **** > > Does that address your concern?**** > > ** ** > > It does, although I still think the original #1 data model where each > available frequency range was simply defined by (f1, f2, psd1, psd2) is > much better. It's also more consistent with the ETSI draft spec.**** > > ** ** > > Using the #2 model of an array of (f, psd) points is only more efficient > as an encoding mechanism in those few cases where non-zero PSD slopes do > actually need to be encoded. Any time there's a "step" jump in Psd you > need just as much data to encode that jump using (f, psd) points as you > would if you used (f1, f2, psd1, psd2).**** > > ** ** > > Regarding splitting the lists in the way you propose, that's not just a > question of what frequencies are "in the plan". The current OFCOM > consultation proposes (§5.93) "not to allow WSD operation in channel 38" > (606 - 614 MHz) as that's used for nationwide PMSE. Channel 38 is > definitely "in the plan", but it's also a discontinuity. Your proposed > model would appear to require that we break our frequency table in two > either side of channel 38, and ends up with a two dimensional array of > arrays in the JSON encoding.**** > > ** ** > > Using (f1, f2, p1, p2) allows the use of a single level list of values, > with the only constraint being that frequency ranges not overlap.**** > > ** ** > > Your example for the US plan then just becomes (omitting the 100 kHz > bandwidth):**** > > ** ** > > "spectra": [**** > > {**** > > "bandwidth": 6e6,**** > > "frequencyRanges": [**** > > {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd": > -56.8},**** > > {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd": > -56.8},**** > > {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, > "stopPsd": -56.8},**** > > {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, > "stopPsd": -56.8},**** > > {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd": > 30.0},**** > > {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd": > 36.0},**** > > {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, > "stopPsd": -56.8}**** > > ]**** > > ]**** > > ]**** > > ** ** > > This requires 28 data values, exactly the same as in your example. It's > also the smallest change necessary from the current spec in > draft-ietf-paws-protocol-06 to support non-zero Psd slopes. For encoding > efficiency one could also specify that PSD just be either a single value or > a pair [psd1, psd2] for those non-zero slope cases.**** > > ** ** > > kind regards,**** > > ** ** > > 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
