How does/will the database compute spectrum availability when a region is provided?

[Kate Harrison]

PAWS supports more general forms of geolocation (such as ellipses or polygons which represent possible locations of the device). Your API lists support for these features as well, but preliminary testing shows that the resulting spectrum schedule is not affected by these parameters. I've included my test point below (my comparison was with vs. without the last three parameters).

My questions are as follows:

1. Will Google's spectrum database support this more general geolocation in the near future? 
2. If yes, how do you expect it will be implemented? I don't believe the FCC has given guidance on this matter yet and Ofcom appears to give only vague guidance ("[The WSDB] will then calculate the generic operational parameters that apply within the coverage area based on a number of default (conservative) device parameters." -- paragraph 5.38.2 of the 2012 Ofcom consultation).

I'm very curious about this aspect of the policy as well as how it is implemented. I suspect the practical answers to my questions are "not soon" and "we're waiting for the relevant regulations" but I thought I'd ask anyway.

Selected available spectrum request details:

    "location": {
      "point": {
        "center": {
          "latitude": 42.0986,
          "longitude": -75.9183
        },
        "semiMajorAxis": 100000,
        "semiMinorAxis": 100000,
        "orientation": 0
      }
    }

[Michael Head]

As PAWS is evolving (we're hoping to that draft 07 will be published soon), our implementation isn't complete and is subject to change. We don't yet support all features.

Also note that we currently only support US rules. Ofcom is not yet in scope.

So to answer your question, at the moment, we only support getting available spectrum at a single point. Other geometries specified in PAWS aren't yet handled, and I believe the axes given in your request snippet are ignored. It probably makes sense to return an error if those extra fields are given in the request until we do actively support them.

It's indeed an open question exactly _how_ those would be handled and would depend on regulation.

Thanks,

-- mike

[Dan Moldovan]

FYI, FCC does provide some guidance on area availability, see 15.711(3)(ii) of the CFR. Specifically:

"

A Mode II personal/portable device may load channel availability information for multiple locations around, i.e., in the vicinity of, its current location and use that information in its operation. A Mode II TVBD may use such available channel information to define a geographic area within which it can operate on the same available channels at all locations, for example a Mode II TVBD could calculate a bounded area in which a channel or channels are available at all locations within the area and operate on a mobile basis within that area.

"

This still doesn't fully clarify how the bounded area is calculated, but the spirit of the law is to ensure protection of licensed transmitters, so at a minimum, the available channel list will likely contain only those channels that are available at every point within the specified area.

[Kate Harrison]

As I understand it, the PAWS protocol is referring to uncertainty in the device's location as opposed to providing a list of channels which is available at all locations within a region. The answer to both queries should be the same, but I think it shows how differently the two teams are thinking (FCC vs. PAWS authors). The PAWS group appears (in my opinion) to be taking a more realistic approach to location uncertainty ("Valid values range from 0 to 99, since, in practice, 100-percent confidence is not achievable." -- section 5.1, "confidence") while the FCC is probably concentrating more on practical systems deployment and just assuming 50-meter geolocation accuracy.

I'm particularly interested in this topic due to some recent work we've been doing on location uncertainty. One of the observations that we made was that it's quite easy to imagine how to answer requests which contain multiple polygons. For example, responding to a device which says "I'm in either New York City or San Francisco" should fundamentally be no more difficult (or different, logic-wise) than responding to a device which says "I'm somewhere in San Francisco". The key is that although we talk extensively about geolocation, the real problem is determining a set of safe operating parameters and computing that set does not require precise geolocation. </plug for own research>

[Kate Harrison]

I'll be excited to read the next draft when it comes out. Are you able to give a preview of any upcoming changes?

Are you able to comment on Google's plans (or lack thereof) regarding support for Ofcom regulations? It would be interesting to hear if there are any practical concerns which make supporting their more complex rules significantly more difficult.

[Michael Head]

I definitely recommend joining the PAWS working group list (sign up links are here: https://datatracker.ietf.org/wg/paws/charter/) and providing feedback before the draft moves on to the area directors.

The list archives are public, and you can see some potential text updates that have been proposed there: http://www.ietf.org/mail-archive/web/paws/current/threads.html

-- mike

[Kate Harrison]

Thanks -- this is great!

[Michael Head]

FYI for anyone following along, but not on the PAWS list, a new PAWSdraft (07) has been posted: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

-- mike