IMHO we should define a protocol that makes it easy to build devices that operation in as many regulatory domains as possible. In order to do that, we should minimize regulatory-domain logic in the devices.
On Fri, Oct 12, 2012 at 8:08 AM, Benjamin A. Rolfe <[email protected]>wrote: > ** > 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. > That's a good suggestion on using RFC 6225 plus a height specification. Setting aside FCC and Ofcom specifics for the moment.... While I agree that, from RF perspective, antenna height above surface is the relevant number. For PAWS protocol, though, I'd like to have a device be able to report location as automatically as possible (think portable) and as regulatory-independent as possible. That means the protocol should allow a height value that can be reported from a technology such as GPS, which is typically above sea level. (We're still allowing height above surface to be configured by fixed-device installers) It should be the Database's responsibility to convert those measurements to values that are relevant for RF in order to compute protection and available spectrum. That is, the Database should have terrain info, not the device. > > 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. > As I mentioned, we should minimize regulatory-specific logic in the device. That is, I don't think we should build knowledge of per-domain reference datum into a device. I'm hoping we can let the protocol drive the rules a bit. Simplify the logic in the device: - The Device reports height as "Above Surface" OR altitude "Above Sea Level". - Let each Database do any conversions it wants (including which one it trusts when both are specified). Any region-to-region differences should be in the DB, not in the device. If we can agree that this is a good idea (big if?), do we need to be precise about which datum is used for "Above Sea Level"? or can we leave it at that (Note that Ofcom does not specify datum for height). Complication from actual rules: - FCC asks for height above ground (surface) - Ofcom asks for height above sea level (but height is optional) Will we be able to have a Device report only one and still satisfy the intent of the rules? While we might be forced to build FCC- and Ofcom-specific logic into a device, hopefully we can influence future rules and harmonization efforts to be more flexible. (my 2 cents) > 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. > This is already accounted for in draft-vchen-paws-protocol-00. I wanted to focus only on the location-related fields in this thread. > > 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 > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
