All, Some views from the regulator's perspective including on the spectrum encoding issue. I recognise that some of this has been argued repeatedly and that the discussion has moved on.
* In the ETSI/Ofcom model, the databases only communicate maximum intentional power in each channel. Unwanted emissions are regulated via compliance with one of the classes defined in ETSI EN 301 598. So, if the DB says that a channel is not available, the a device must not have wanted emissions on it. The device is allowed have "skirt" on it, but only up to the levels allowed by its emission class. * The DB should have a clear way of telling the device that a channel is unavailable. I am not in favour of assuming that certain low dBm number means unavailability. * From a regulator's perspective, there is no requirement on HOW the DB specifies unavailable channels. 2 approaches have been mentioned here: 1) to exclude the channel from the list, and 2) a codification such "-inf dBm". Either would work for us. * Peter is right that the regulatory requirement is that a DB should simply tell a device that a channel is available, the allowed power and the start/end of availability. I am not comfortable with the notion of "no information given" , in case the device decides that a spectrum availability info remains valid in the absence of newer information. Having said that you may want to accommodate value added services in future versions of the protocol, to indicate things such as "this channel is normally the best even though from 3:00 to 6:00 is not available", but it looks too advanced to me at this stage. * Future proofing devices. The way we plan to accommodate better unwanted emissions or less interfering technologies in the ETSI framework is 1) through update of the ETSI standard (not very quick), and 2) by means of the "technology ID" field (hopefully quicker). If a new technology is assessed (how this is done is TBD) to be more benign to DTT/PMSE receivers, the DB will allow higher power levels to devices declaring that technology. Hope this helps, Cesar From: [email protected] [mailto:[email protected]] On Behalf Of Peter Stanforth Sent: 23 September 2013 15:00 To: Harasty, Daniel J; [email protected] Subject: Re: [paws] "unavailable" vs "no information" Speaking as a database provider who has been certified, and someone who has helped a number of radios get FCC certification I have to suggest your interpretation is wrong. There is no ambiguity as far as the FCC is concerned, and conversations with IDA, IC, and Ofcom lead to a similar conclusion. >From the Regulator perspective, the database provides a list of channels that >are available and anything that is not specifically identified as available is >unavailable - period. There is no notion, to use your example, that channel 17 is undefined after 6pm. The database told you you can only use it till 6pm. At 6pm you can query the database and you may be told that it is available. Does this mean it was always available? Absolutely not, but at the time of the original query it was unavailable. I also have to deal with the situation where I am required to tell a device "no channels available". At the time I give that answer it is unambiguous. If the device asks again later it may, or may not, get the same answer. I don't understand how I do this if we are returning a complete "channel list" with any kind of emission criteria, and satisfy the Regulator that we are doing what we are required to do. As I have said previously the database is not the enforcer or the decision maker. It simply provides information based on the Regulator rules and policy. I have found this is not open to debate. In most countries Regulators are not allowed to delegate or abdicate responsibility for spectrum management. We exist, as a database provider, by acting as an agent or subcontractor to the Regulator (depending on the domain). We are not permitted to make interpretations or make decisions. We simply implement their rules. Maybe this will change in the future but this is the environment we operate in today. As far as spectrum availability is concerned I think the current specification allows us to comply with all the known regulatory environments we are aware of. Including vague notions around implicit, or maybe, concepts not only give me concern about how I comply with the agreement I have in place with the regulator, it is likely to give the incumbents fits. We have enough fights with the incumbents today even with the simple definition that exist. Suggesting that the database is "interpreting" anything simply makes the likelihood of spectrum sharing in whitespace less likely. All that being said. I go back to my other concern, which is that this is taking way too long. Based on the original charter we should be done by now. So even though I think some of these ideas are academically interesting, and maybe in the longer term future of PAWS. I really want to get a PAWS protocol finished that supports the TVWS activities that are percolating around the world. To paraphrase Voltaire I strongly believe that an imperfect, but finished, PAWS protocol sends a stronger message of industry commitment to wanting access to TVWS and spectrum sharing than continuing to debate what PAWS maybe one day. Peter S From: <Harasty>, Daniel J <[email protected]<mailto:[email protected]>> Date: Monday, September 23, 2013 9:20 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [paws] "unavailable" vs "no information" Gabor Bajko mentioned: I think we first have to agree whether we need at all to encode an 'unavailable channel'. Current draft section 4.4.2 says: "The response message for the Available Spectrum Query contains a schedule of available spectrum for the Device." To me this means that channels which are not listed are implicitly unavailable and leakage into unavailable spectrum has to conform to the rules. I agree that "no mention of a segment of spectrum as available" is a possible way to express "it is unavailable". Let's call this "implicit unavailability". However, if I'm a Device, and I received a SPECTRUM_AVAIL_RESP that says "Channel 17 is available until 6pm" (and nothing else is mentioned about Channel 17 for the time period after 6pm)... does that mean "Channel 17 is unavailable after 6pm" or "I have no information about Channel 17 after 6pm (maybe it is available, maybe it's not)"? Thus I propose that we still need some sort of "explicit unavailable" notation, and "no mention" should be reserved to express "there is no information about this piece of spectrum in this time period - ask again later". Stated another way: I propose that PAWS is better off if the Database has some way to express the difference between "channel unavailable" and "no information given about this channel [in this time period]". Perhaps the "implicit unavailability" approach could be made to work by then ADDING more fields to the event structures, like "response valid through" or "response expiration" values... but I find that more convoluted than a "explicit unavailable" notation, which can express "this bit of spectrum is unavailable in this time period". Dan Harasty ________________________________ ****************************************************************************************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use of the addressee only. If you have received this email in error please notify the originator of the message and delete it from your system. This email has been scanned for viruses. However, you open any attachments at your own risk. Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise. ******************************************************************************************************************
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
