Under FCC rules, there is no specific requirement for how signal power is distributed between multiple "on" channels. The rules are designed to protect the TV broadcasts, so as long as the WSD's out-of-band emissions stay below the "off" channel power limits, the TV broadcasts will have the protection they need.
Andy Lee | Google Inc. | [email protected] | 408-230-0522 On Mon, Sep 16, 2013 at 1:17 PM, Ray Bellis <[email protected]>wrote: > Per my previous message, I mean the case where the WSDB profile permits > two adjacent channels to be used but the device only uses one of those. > > Is the permitted adjacent channel leakage into the unused channel > supposed to be specified in the PAWS spectrum profile or (as I would > expect) by regulatory device requirements? > > Ray > > Sent from my iPhone > > On 16 Sep 2013, at 21:12, "Andy Lee" <[email protected]> wrote: > > 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
