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
