On Fri, Aug 30, 2013 at 1:35 AM, Ray Bellis <[email protected]> wrote:
> If what you've described above is the real rationale (and other messages > I've seen suggest it is) then it seems to me that mixing together in-block > power levels and out-of-block power limits in the same frequency table is a > big mistake. There appears to be no way to encode the frequency parameters > to say "you may use 30 dBm in this channel if you're using it, but only > leak -30 dBm into it if you use the adjacent channel instead". My interpretation is that the PAWS spectrum profile is expressing what is permissible under the local white space rules and is completely separate from the hardware OOB emission limits. In the case of the FCC, the permissible white space power is specified as absolute in-band power limits (36 dBm/6MHz EIRP fixed, 20 dBm/6MHz mode 2, and 16 dBm/6MHz mode 1), and specific absolute out-of-band power limits (-36.8 dBm/6MHz EIRP fixed, -56.8 dBm/6MHz any portable device on an adjacent channel, and -52.8 dBm/6MHz any other portable device), as specified in CFR Title 47, section 15.709. The FCC has additional special requirements around channel 37 as specified by the field strength table in section 15.709(c)(4). In the case of Ofcom, the permissible white space power is calculated individually per-channel for DTT and PMSE, resulting in a different power level for every 8 MHz and 100 kHz channel. There isn't really a distinction between "in-band" and "out-of-band" emissions when a continuum of power levels are possible. The spectrum database simply provides this list of permitted frequencies and power levels over the PAWS protocol. The profile of permitted spectrum could include adjacent channels in some places. It is then the device's responsibility to select which subset of frequencies it will actually use, in accordance with local regulation. At the time the device is built (and presumably as part of the device certification process), it must comply with several in-band and out-of-band emissions requirements (whether they are specified as relative values or absolute), but this has nothing to do with the spectrum availability offerings being communicated over PAWS. For example, Ofcom has specific adjacent channel leakage ratio (ACLR) requirements for devices to qualify as a Class 1, 2, 3, or 4 white space device. Once hardware is built, the ACLR performance of a device is essentially fixed, and there's nothing in the PAWS spectrum message that would change that. Andy Lee | Google Inc. | [email protected] | 408-230-0522 On Fri, Aug 30, 2013 at 1:35 AM, Ray Bellis <[email protected]>wrote: > > On 29 Aug 2013, at 17:04, Benjamin A. Rolfe <[email protected]> wrote: > > I too was confused by this, and *think* I have figured it out (perhaps > incorrectly): > "Unavailable" means the channel is not indicated as available at the > specific location and time of the query. Thus intentional radiation by a > whitespace device is not allowed. In real RF systems, a device transmitting > in an available channel near the unavailable channel will have some energy > "spill" outside the boundaries of the channel. The white space issued and > proposed regulations I have reviewed have different definitions of what is > allowed to "spill". I assume (dangerous word alert) that the intention is > to allow communication of these different regulatory requirements. > > > Hmm, ok... > > FCC regulations do not define "unavailable" but do specify limits on > emissions by TVWS devices outside of the TV channel being used, whether it > is indicated as "available" or not. This is specified as a level relative > to transmit signal level, not absolute dBm (" 72.8 dB below the highest > average power in the TV channel in which the device is operating."). For > frequencies beyond the TV channel adjacent to channel being used, maximum > emissions are defined as field strength (15.209). Representing the later > is in dBm requires defining the parameters for conversion; Note FCC > received multiple comments suggesting changing the adjacent channel > requirement to an absolute level and not relative to an actual level. I > don't see how the FCC requirements as issued can be expressed in this > format. > > > The draft ETSI spec has a table (ยง4.2.4.2.2, Table 3) giving permitted > adjacent frequency leakage ratios. They also appear to be relative to the > in-block power rather than absolute values. > > In any event, how would this data model support the perfectly feasible > scenario where a device is offered two adjacent channels, and therefore has > "full power" available in either, but only choses to use one, and therefore > must limit its OOB transmissions in the other? > > If what you've described above is the real rationale (and other messages > I've seen suggest it is) then it seems to me that mixing together in-block > power levels and out-of-block power limits in the same frequency table is a > big mistake. There appears to be no way to encode the frequency parameters > to say "you may use 30 dBm in this channel if you're using it, but only > leak -30 dBm into it if you use the adjacent channel instead". > > 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
