Ben,
I think I agree but not sure if there is something subtle in your comments that I am missing. I agree that the device should be able to communicate its lat/lon/height. As was mentioned for some device types (e.g. Fixed WSD) the height parameter is required by some Regulatory Authorities (e.g. US FCC requires HAGL). I shared previously that the height parameter should be a generalized value not sure "altitude" has a specific implied definition. The value of HAAT should be the responsibility of the Database based on the Regulatory Authority Policy. In the original draft submitted that was used for this merged document the method for registration was separate from the request for available channels to allow for a clean separation of required functionality (e.g in the US only Fixed WSD must register once or if they are moved, Mode IIs do not register). Also more FYI in the US the FCC requested that the database provide the Fixed WSD registration capability over the wire when Telcordia was certified (although it was not explicitly state). Best regards, John ________________________________ From: [email protected] [[email protected]] on behalf of Benjamin A. Rolfe [[email protected]] Sent: Friday, October 12, 2012 4:43 PM To: [email protected] Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? FCC Part 15.713 does say that the registration information must be in the database and doesn't say how it gets there. This is "registration" and must be completed before the device may operate. This is where I got the notion that it would be part of the device registration protocol. If that is outside the scope of PAWS then I'm sorry to have missed that. As for HAAT requirements, The FCC Second Memorandum and Order FCC 10-174 states conditions when both antenna height above ground and HAAT requirements must be used to determine if the device be provided channel availability data. Again may not need to be sent over the wire. But in the case of some 802 systems, we expect a local device will be a source of channel availability data (a fixed device serving a mode II device for example) and so this information will need to be acquired somehow. I definitely prefer Vincents approach, where the TVWS device provides to the DB server 3D location and let the DB server do the work of accessing geographic data and calculating the rest. This may work in the US. OfCom seems specifically to state that the antenna height above ground will need to be communicated between the DB and the WS device, in 3.9 through 3.13 it gives conditions where antenna height both "may" and "must" be communicated a between the database and the master device. Again leads me to the notion that the protocol provide for the exchange. Maybe we should separate device location from antenna parameters? -Ben Correction: FCC rules only state that the Database must "store" the fixed-device's "height above ground". It does not mandate that the Device must send "height above ground" over the wire. Thus, the protocol can still allow "Above Sea Level" from the device and let the database compute and store "height above ground". On Fri, Oct 12, 2012 at 9:59 AM, Vincent Chen <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws -- -vince -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
