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]<mailto:[email protected]>> wrote: What do you mean by "otherwise permitted channels"? Andy Lee | Google Inc. | [email protected]<mailto:[email protected]> | 408-230-0522 On Mon, Sep 16, 2013 at 12:25 PM, Ray Bellis <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> | 408-230-0522<tel:408-230-0522> On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel J <[email protected]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ray Bellis Sent: Monday, September 16, 2013 5:06 AM To: Vincent Chen Cc: [email protected]<mailto:[email protected]> Subject: Re: [paws] Encoding of spectrum profile On 13 Sep 2013, at 17:00, Vincent Chen <[email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
