On 10/11/2012 2:24 PM, Vincent Chen wrote:
Thanks All,

So what I hear is that trying to re-use a standard that describes location as (latitude, longitude, altitude) is probably not a good idea.
I disagree. I think it's a good idea to reuse what applies; RFC 6225 is a good starting point for what you need to do to represent location.

Note that in both FCC and OfCom the number captured in the database is relative to the surface (HAAT or AGL) and not relative to the reference datum (i.e. MSL or MLLW), so the height value they're looking for is going to be relative to whatever datum they use to define terrain/ground elevation.  I'd suggest we add a field called "height" rather than use "altitude", so as to not confuse this from altitude as provided by a GPS receiver or barometric pressure measurement (height above the reference datum, usually just called MSL).  Use "altitude" to mean what most people think it means and "height" to mean what FCC, OfCom and other regulators want it to mean, which of course is slightly different depending on which regulation you are reading.  Then we don't get tangled up in confusing (1) and (2) below. As a radio guy noodling RF propagation and interference potential, I care about the antenna height relative to the stuff around it and not much about absolute altitude.

As for what "height" means, that will be defined by the regulations.  It may be different for every set of WS rules and it might even vary by region in a single regulatory domain. And it will evolve over time.

Your correct that the difference between the various datums isn't as big as the uncertainty allowed by current regs, but I'm not sure that matters as I don't see why the protocol would USE the value. It may be relevant to an application process such as a provisioning system, so maybe we need to transport the value. Or not, as if you know the regulatory domain you know what reference datum they use, as well as what how they calculate height, so maybe just knowing the regulatory region ID may be enough.

I also pointed out you likely need to carry additional information about the antenna as well, such what I listed from the OfCom requirements.  Sorry that is really a diversion for this thread, but as we talk about antennas it came to mind.


Hope that helps.
Ben



To focus specifically on the discussion of height:

 - Whether protection should be computed using a device's HAAT is a regulatory rule. As such, the Database should be responsible to applying the right rules (including how to compute HAAT). We should not be burdening a device with those.

For the PAWS protocol, we should define height in a way that is easy for the device to determine by itself (or by an installer), independent of regulatory specifics. There appears to me two options we should support:
   1. Height above (relative to) mean sea level, as can be reported by a GPS, or
   2. Height above ground (or sea in case of a bridge) that can be determined by direct measurement or engineering drawings

For the first, we could specify WGS84. If WGS were to change in the future, how much difference would we expect? Probably won't actually make a difference in protection or available spectrum computations...

In the case of a bridge or ship, I claim one of the above will do. How to compute available channels is a regulatory rule whose enforcement belongs in the Database.
It should not impact the PAWS protocol.

I would hope that one of the goals of a standard is:
 - Establish reasonably flexible parameter set without going "overboard" (pun intended). I think we should present a model around which regulators could align, rather than encourage each to come up with completely new rules.

Thoughts?

-vince

_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws

Reply via email to