Subject: [paws] "unavailable" vs "no information"

From: "Harasty, Daniel J" <[email-masked]>
Date: Mon, 23 Sep 2013 13:20:37 +0000

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

---

From: James Harrison <[email-masked]>
Date: Mon, 23 Sep 2013 14:35:49 +0100

On 23/09/13 14:20, Harasty, Daniel J wrote:
>
> 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".
>
>

(First time poster, not-a-long-time lurker - hello! Do excuse me if I've 
missed anything...)

I'm not sure I can see the situation where, as a DB operator, I would 
want to say "I don't have anything to say about this piece of spectrum 
in this time period". Either I can allocate that spectrum - in which 
case I'd be providing freq/power data - or I can't, either for 
regulatory reasons or operational reasons (regulator-triggered shutdown, 
DB maintainence, etc).

Lack of definition in a response should always imply the spectrum is 
unavailable, in my opinion.

That said - I don't see a huge issue in adding a way to express the "no 
information available" case if there's a use-case to support that. But I 
think that should be a distinct note against some spectrum, with "not 
present in response" reserved for "explicitly unavailable".

Cheers,
James Harrison

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 23 Sep 2013 10:00:27 -0400

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-masked]<mailto:[email-masked]>>
Date: Monday, September 23, 2013 9:20 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

---

From: Cesar Gutierrez <[email-masked]>
Date: Mon, 23 Sep 2013 14:49:11 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Peter Stanforth
Sent: 23 September 2013 15:00
To: Harasty, Daniel J; [email-masked]
Subject: Re: [paws] "unavailable" vs "no information"

>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.

Peter S

Gabor Bajko mentioned:

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.
******************************************************************************************************************

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Mon, 23 Sep 2013 11:48:15 -0700

Based on the US rules, only when a channel is explicitly identified as 
available at the time and place may it be used.  If no information is 
obtained indicating it is OK to use at the time and location of the 
device it shall not transmit on a channel except as provided in the 
rules for making initial contact and queries for the purpose of 
obtaining channel availability information.   Last version of OFCOM and 
EU proposals I read were similar (except last version of EU rules I read 
did not have any provision for making an initial query, but that may 
have been fixed).

So absence of permission is (in this case) an implicit "No".

Hope that helps.

On 9/23/2013 6:20 AM, Harasty, Daniel J wrote:
>
> 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)"?
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: Andy Lee <[email-masked]>
Date: Mon, 23 Sep 2013 16:15:31 -0700

Hi Ben,

I think we're in total agreement.  The way the FCC rules are written, there
is always a baseline set of rules, with specific additional authorizations
granted by rule.  Section 15.709 grants radio emission permissions under
very specific conditions.  Anything not mentioned in section 15.709 is an
implicit fallback to the baseline set of rules.

Section 15.109 of the rules specifically covers non-transmitting devices,
and according to the FCC, non-transmitting devices are limited to a power
of 0.000000012 Watts in the UHF band (which is the same as 0.000012 mW, or
-49.2 dBm, or 200 uV/M @ 3 meters).  This IS the FCC's definition of "off";
they had to pick a value, and this is it.  Any channel not specifically
granted an "on" power level in section 15.709 would implicitly be "off".

The laws in most jurisdictions are defined this way, where all the rules
are "additive".  Anything not mentioned in a specific add-on rule would
implicitly fall back to the more general rules underneath.

I'm fine with there being an implicit "off" whenever there is not an
explicit "on" contained within a message.  Whether the DB communicates the
"off" parameters to the device is separate matter.

Best regards,
Andy