The purpose of the database is to protect incumbent operations. How secondary users then access the spectrum is beyond the regulatory scope (though the way the FCC defined the way PSD is measured narrow channel use is effectively banned). So far all Regulators have defined protection in terms of 6 or 8 MHz channels, not partial channels. So unless we believe we can convince regulators to change their definition and protect partial channels (when used by PMSE for instance) the way it is defined is adequate.
I apologize for sounding like I am pouring cold water on your ideas but, although the Charter says "protocol for access White Space", there was a conscious decision made at the beginning to solve the problem for TVWS, thus avoiding scope creep and getting a standard out there. While we have tried to remain flexible we really don't know how other bands, beyond a proposal by PCAST in the US, and a notion of LSA in the EU, will be managed so I would keep to the plan. We are already a year late from the original objective. Peter S. From: "Benjamin A. Rolfe" <[email protected]<mailto:[email protected]>> Date: Saturday, September 14, 2013 10:33 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] Encoding of spectrum profile The Whitespace spectrum allocations I have been following in various regions are made of of non-contiguous collections of contiguous spectrum, as illustrated by the US situation for TVWS below: each TV channel is a contiguous chunk of spectrum 6MHz wide; TV channels are spread dis-contiguously across the spectrum. . Multiple standards exist and others are under development to utilize whitespace allocations. In 802.11, mhe ultiple TV channels may be aggregated to one 802.11 channel; in 802.15 we do e opposite: we divide a single TV channel into many physical channels. In the current drafts, we assume the database provides the boundaries of the TV channel (somehow) and the standard maps that to the PHY channels defined. There is also a need to specify unavailability of a small part of a TV channel. The regional regulations for allowable use, in particular the methods for specifying transmit signal energy limitations, vary greatly. In the US the current TVWS is quite simple compared how power limits are specified in other bands. As we see the whitespace concept catching on (and it seems to be), I expect we will see the variety of methods used in other subparts of Part 15 applied. If the goal is to be able to get this information from the database so an implementation can be regulation agnostic, it may be wise to look at some of the methods likely to be applied when we move beyond "TVWS" into application of the whitespace management concept to other spectrum allocations. In Part 15 we see emission limits expressed as total power in a specified bandwidth, peak measured in any xHz accross the entire signal or band, field strength (energy level measured at a specified distance) and several other methods. In the more popular license exempt bands we have different methods applied, with different effective emissions limits, that are based on modulation type, modulation bandwidth (signalling rate), how the band is sub-divided into communcation channels (number of channels and occupied bandwidth of each), if the system employs frequency hopping, etc. We also see constraints such as minimum and maximum occupied bandwidth for a communications channel. I don't know if there is much concern over data volume for database exchanges. Specifying an approximation of a spectral mask point by point is possible, but may become quite a few points. There are a few standard models for approximating spectral shape which could be used to reduce the data volume, which may have value in the long run. A few thoughts I hope will help from a humble and hopeful future user of the protocol! -Ben On 9/13/2013 8:03 PM, [email protected]<mailto:[email protected]> wrote: Hi, Not just the spectrum is available in non-contiguous bands, but a whitespace radio with higher bandwidth requirement may use non-contiguous spectrum aggregation, and consume available spectrum across multiple bands too. Thanks and Regards, Sajeev From:[email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Vincent Chen Sent: Friday, September 13, 2013 10:03 PM To: Peter Stanforth Cc: [email protected]<mailto:[email protected]> Subject: Re: [paws] Encoding of spectrum profile Peter, Agreed. So it is important for the protocol to be able to represent discontiguous bands. Thanks. -vince On Fri, Sep 13, 2013 at 9:06 AM, Peter Stanforth <[email protected]<mailto:[email protected]>> wrote: The US is not unique in having discontinuous bands, we have come across a mix of VHF and UHF channels in a number of countries. From: Vincent Chen <[email protected]<mailto:[email protected]>> Date: Friday, September 13, 2013 12:00 PM To: Ray Bellis <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] Encoding of spectrum profile Ray, Sorry for the delay in response. My point about being able to represent discontinuities in the frequency range still appears to stand, however. 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: "spectra": [ { "bandwidth": 6e6, "profiles": [ [ { "freqHz": 5.4e7, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 7.6e7, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 8.8e7, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 1.74e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.8 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } ] ] }, { "bandwidth": 1e5, "profiles": [ [ { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 7.2e7, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 1.74e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 2.16e8, "maxPsdDbmPerBw": -74.58 }, ], [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }, { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 }, { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 } ] ] } ] Does that address your concern? -- -vince -- -vince _______________________________________________ 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
