That's correct, the example values come from the FCC rules under section 15.709(c)(1)
Andy Lee | Google Inc. | [email protected] | 408-230-0522 On Mon, Sep 16, 2013 at 10:33 AM, <[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”?**** > > I thought this was clarified in > http://www.ietf.org/mail-archive/web/paws/current/msg01615.html**** > > **- **gabor**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *ext Harasty, Daniel J > *Sent:* Monday, September 16, 2013 9:16 AM > *To:* Ray Bellis; Vincent Chen > > *Cc:* [email protected] > *Subject:* Re: [paws] Encoding of spectrum profile**** > > ** ** > > 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]<[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
