What do you mean by "otherwise permitted channels"?
Andy Lee | Google Inc. | [email protected] | 408-230-0522 On Mon, Sep 16, 2013 at 12:25 PM, Ray Bellis <[email protected]>wrote: > And adjacent channel leakage into otherwise permitted channels is a > matter of regulatory device approval? > > Ray > > Sent from my iPhone > > On 16 Sep 2013, at 19:18, "Andy Lee" <[email protected]> wrote: > > 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
