Subject: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"?

From: Vincent Chen <[email-masked]>
Date: Wed, 10 Oct 2012 21:53:58 -0700

All,

The various versions of the proposed drafts of the PAWS protocol tended to
distinguish between "device location" and "antenna height".

I think we should combine them into a single 3-D location of the radiation
center of (the antenna of) the device.

Does that sound right?

The proposed draft-vchen-paws-protocol-00 defines the following parameters
for location and height:

  latitude
  longitude
  locationUncertainty
  locationConfidence

  height
  heightType
  heightUncertainty

This is very close to the fields  defined by RFC 6225, which has the
parameters:

 latitude
 latitudeUncertainty
 longitude
 longitudeUncertainty
 altitude
 altitudeUncertainty
 altitudeType

Should PAWS reference RFC 6225 and list the following differences?

 - The "altitudeType" should be "above means sea level" (WGS84) or "above
ground", instead of the ones defined in the RFC.

 - Add confidence values along each axis.

If this acceptable, then we can think about defining JSON encoding of RFC
6225 for use by PAWS.

Thanks.

-- 
-vince

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Oct 2012 06:07:57 -0400

We need both I think, because of the way the regulations are written.  I don't think there is a simple way to convert that would be acceptable.  In theory, if we knew the terrain height at the location accurately enough, we could calculate what we need, but that is an onerous requirement I think.

Brian
 
On Oct 11, 2012, at 12:53 AM, Vincent Chen <[email-masked]> wrote:

> All,
> 
> The various versions of the proposed drafts of the PAWS protocol tended to distinguish between "device location" and "antenna height".
> 
> I think we should combine them into a single 3-D location of the radiation center of (the antenna of) the device.
> 
> Does that sound right?
> 
> The proposed draft-vchen-paws-protocol-00 defines the following parameters for location and height:
> 
>   latitude
>   longitude
>   locationUncertainty
>   locationConfidence
> 
>   height
>   heightType
>   heightUncertainty
> 
> This is very close to the fields  defined by RFC 6225, which has the parameters:
> 
>  latitude
>  latitudeUncertainty
>  longitude
>  longitudeUncertainty
>  altitude
>  altitudeUncertainty
>  altitudeType
> 
>  - The "altitudeType" should be "above means sea level" (WGS84) or "above ground", instead of the ones defined in the RFC.
> 
> If this acceptable, then we can think about defining JSON encoding of RFC 6225 for use by PAWS.
> 
> Thanks.
> 
> -- 
> -vince
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: Peter Stanforth <[email-masked]>
Date: Thu, 11 Oct 2012 08:40:15 -0400

Agreed.
We need to be able to resolve AGL, HAAT, location and maybe other criteria
based on the regulators methods. I am not sure a single 3D location will
be acceptable.

On ThuOct/11/12 Thu Oct 11, 6:07 AM, "Rosen, Brian"
<[email-masked]> wrote:

>We need both I think, because of the way the regulations are written.  I
>don't think there is a simple way to convert that would be acceptable.
>In theory, if we knew the terrain height at the location accurately
>enough, we could calculate what we need, but that is an onerous
>requirement I think.
>
>Brian
> 
>> The various versions of the proposed drafts of the PAWS protocol tended
>>to distinguish between "device location" and "antenna height".
>> 
>> I think we should combine them into a single 3-D location of the
>>radiation center of (the antenna of) the device.
>> 
>> Does that sound right?
>> 
>>  - The "altitudeType" should be "above means sea level" (WGS84) or
>>"above ground", instead of the ones defined in the RFC.
>>

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 11 Oct 2012 10:19:51 -0700

I would not suggest specifying a method to resolve HAAT, as there are 
many methods which may be used and I would not bet on every regulatory 
region agreeing on a single method. For each Height (altitude) provide a 
way to indicate what it is as suggested bellow and a way to identify the 
reference model or regional method (like regulator ID?).

At the moment, FCC specifies the location is of the device, while OfCom 
specifies the location is of the antenna.   The later makes more sense  
to a radio guy worried about interference footprint.  The first seems to 
assume the device and antenna are close enough to each other (within the 
allowed uncertainty which is currently +-50m).  OfCom and FCC currently 
specify WGS84. This may change in the future if the as the WGS model has 
been and will be updated from time to time.  OfCom gives specific 
requirements for how accuracy is specified (and a 95% confidence 
level).  Where antenna height is required by OfCom it is specified as 
above ground level. FCC has specified HAAT and has already revised at 
least once how HAAT is to be determined (and I expect it to change again).

OfCom identifies other antenna characteristics that may be communicated 
between a device and the database as well including directionality and 
orientation, polarisation (I am quoting OfCom here), and if the antenna 
location is indoor or outdoor.

Hope this helps

Ben

On 10/11/2012 5:40 AM, Peter Stanforth wrote:
>> On Oct 11, 2012, at 12:53 AM, Vincent Chen<[email-masked]>  wrote:
>>
>>> All,
>>>

---

From: Nancy Bravin <[email-masked]>
Date: Thu, 11 Oct 2012 10:36:15 -0700

Also, there are different possible use cases that would need HAAT etc, and some where it could be above sea level if WS devices are used aboard a ship or boat or attached to
a flotation device of some sort for monitoring in the future. Or infrastructure monitoring on a bridge lets say, that would be above sea level I assume. 

OF course this would be applicable to local regulations allowed. 
So having the ability to comply with all, in the original protocol and may be something to be discussed by the WG. 
Just a thought, I am not married to it. 

Sincerely, Nancy

On Oct 11, 2012, at 10:19 AM, Benjamin A. Rolfe wrote:

> I would not suggest specifying a method to resolve HAAT, as there are many methods which may be used and I would not bet on every regulatory region agreeing on a single method. For each Height (altitude) provide a way to indicate what it is as suggested bellow and a way to identify the reference model or regional method (like regulator ID?).
> 
> At the moment, FCC specifies the location is of the device, while OfCom specifies the location is of the antenna.   The later makes more sense  to a radio guy worried about interference footprint.  The first seems to assume the device and antenna are close enough to each other (within the allowed uncertainty which is currently +-50m).  OfCom and FCC currently specify WGS84. This may change in the future if the as the WGS model has been and will be updated from time to time.  OfCom gives specific requirements for how accuracy is specified (and a 95% confidence level).  Where antenna height is required by OfCom it is specified as above ground level. FCC has specified HAAT and has already revised at least once how HAAT is to be determined (and I expect it to change again).
> 
> OfCom identifies other antenna characteristics that may be communicated between a device and the database as well including directionality and orientation, polarisation (I am quoting OfCom here), and if the antenna location is indoor or outdoor.
> 
> Hope this helps
> 
> Ben
>

---

From: Nancy Bravin <[email-masked]>
Date: Thu, 11 Oct 2012 13:37:37 -0700

A bridge above water? I think would be measured "above sea level as there is no terrain unless it is underwater. 

The point being that sea level for a variety of applications should be a separate category than over terrain, or above ground level. 
Being below sea level is another issue….but can be handled with sea level minus etc…
Also different countries will, according to its topology will have different regulations, so being prepared is wise, including the x mile of ocean that
is not international waters.

 Cruise ships coming into port for instance…will the staterooms using WS devices be above or below sea level, 
or will everything be WS and Slave devices if such is a use case that could apply? 
A DB provider could serve WS devises in such a manner. IMHO

Sincerely, N

On Oct 11, 2012, at 1:21 PM, Benjamin A. Rolfe wrote:

> I find few circumstances where a bridge being below sea level would be a desireable thing (perhaps in the Salton Sea of southern California?).  In general if the antenna is below sea level on the bridge we hope the monitoring system has already sent it's alerts!  Now the idea of whitespace device on submersibles, though, is really interesting :-).
> 
> The question really is about how we specify altitude (antenna guys call it "height", while navigators call it "altitude").  The terms Above Ground Level (AGL)  and Height Above Average Terrain are actually quite different things.  Each must be expressed in units like feet or meters relative to some reference.  Mean Sea Level is a commonly used reference that defines an ellipsoid approximating the level of the oceans, but of the actual level of oceans around the world varies over time and location.   MSL is just the well defined reference point.  It happens to be the reference used by GPS and most other navigation systems used on earth.  Two common ways to measure altitude (height) are with barometric pressure (baro-altitude) and GPS, both typically give a value relative to MSL.
> 
> HAAT is technically very different than AGL.  AGL is defined as the elevation above a specific point on the surface of the earth.  HAAT is an averaged elevation  over an area.  Computing altitude AGL is simple subtraction if you have a geo database that contains the elevation of a particular lat/lon. If you have for example your measured GPS altitude, and the elevation of the point on the surface at teh same lat/lon, you subtract one for the other and viola, height above the ground.  Or, for a fixed system, put in the height of the tower or mast you put the antenna on top of (assuming the bottom of the tower is attached to the ground firmly enough the tower remains orthogonal to the ground - a very useful feature of towers ;-).
> 
> HAAT requires you define a specific area and integrate the elevation values of a number of points within that area. This means (pun intended) you have to define an integration method, interval and pattern for selecting the points to integrate, and so on.  The FCC has done this, at least twice, as the latest MO changed the HAAT definition used.   So it'd be a bad idea to
> capture a particular method for computing HAAT in the standard and I don't see why we would, we just need the protocol to support carrying the information around.
> 
> Of course in your shipboard example when out to sea I'd expect AGL and HAAT to resolve to the same value, the average terrain being wet and flat. The same would be true in Florida too I suppose.
> 
> From a radio point of view, HAAT can be more useful in predicting radio propagation.  FCC picked it for that reason I suspect. We can deal with the complexity.  OfCom has picked to use AGL for device antenna height in their requirements.  A protocol that doesn't support HAAT can't support databases certified by the FCC, and if you can't support AGL you can't support databases certified by OfCom. I don't think it takes much, as I suggested, if we know the regulatory region we can know what form of altitude we need to give or get.
> 
> Hope that helps....yes I have spent a lot of my life thinking about my position on the earth :-).
> 
> B
> 
>

---

From: Nancy Bravin <[email-masked]>
Date: Thu, 11 Oct 2012 13:44:14 -0700

Thanks Ben, in any case, as I said I am not married to this idea, just a thought of possibilities. 
N

On Oct 11, 2012, at 1:23 PM, Benjamin A. Rolfe wrote:

> P.S. here's a cool tool from the FCC
> http://transition.fcc.gov/mb/audio/bickel/haat_calculator.html
>

---

From: Vincent Chen <[email-masked]>
Date: Thu, 11 Oct 2012 14:24:31 -0700

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.

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

---

From: Nancy Bravin <[email-masked]>
Date: Thu, 11 Oct 2012 16:17:36 -0700

Well said, I agree…thanks Nancy

Nancy Bravin

[email-masked]
[email-masked]

On Oct 11, 2012, at 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.
> 
>  - 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.
>  - 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

---

From: "Malyar, John P" <[email-masked]>
Date: Thu, 11 Oct 2012 23:47:21 +0000

Vince

I agree that the Device should not specify HAAT but we do need a parameter from the Device to pass information above and beyond Lat and Lon for example HAGL. The specific value in this triple will be defined by the Regulatory Authority. We can simple call it Height and identify that the required/expected value will be determined by the RA. Not sure I would say it is independent of the RA. It should be noted that the value should be present in the Registration but not necessary in the Get Channels.

John

From: Vincent Chen [mailto:[email-masked]]
Sent: Thursday, October 11, 2012 05:24 PM
To: Nancy Bravin <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"?

Thanks All,

Thoughts?

-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Fri, 12 Oct 2012 08:08:19 -0700

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

- 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.

- 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

---

From: Vincent Chen <[email-masked]>
Date: Fri, 12 Oct 2012 09:59:25 -0700

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-masked]>wrote:

> **
>  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.

>  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
>  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.

-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Fri, 12 Oct 2012 10:38:45 -0700

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-masked]> wrote:

> (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
> 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.
>
> 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
>>
>>
>>
>>
>>  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

-- 
-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Fri, 12 Oct 2012 13:43:01 -0700

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-masked]>
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-masked]>
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).

- 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.

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-masked]

--

-vince

--

-vince

---

From: Peter Stanforth <[email-masked]>
Date: Sun, 14 Oct 2012 17:18:06 -0400

Assuming the DB has access to terrain data, likely if it is doing any kind of propagation calculation (required by FCC). Then the DB will be able to determine the HAAT and other topographic data from the Lat/Long provided by the device. The only thing the DB does not know is the height (above ground at that location) of the antenna, which both FCC and Ofcom require. This is the "Height" the DB needs.
Remember that Regulators are restricting the device to about 1W ERP so it does not make much sense to have the device very far away from the antenna.  So the location of the device is a reasonable approximation for the location of the antenna. In the FCC world personal/portable devices will be required to have a permanently attached antenna. Fixed devices are being certified with "remote" antenna but the certification includes specific antenna that are permitted so even here there is not much room for error.
Peter S.

From: "Benjamin A. Rolfe" <[email-masked]<mailto:[email-masked]>>
Date: Friday, October ,12, 2012 Fri Oct 12, 4:43 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.

-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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> 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.

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).

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

Thoughts?

-vince

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

--
-vince

---

From: "Malyar, John P" <[email-masked]>
Date: Sun, 14 Oct 2012 22:08:03 +0000

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-masked] [[email-masked]] on behalf of Benjamin A. Rolfe [[email-masked]]
Sent: Friday, October 12, 2012 4:43 PM
To: [email-masked]
Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"?

-Ben

(my 2 cents)

Hope that helps.
Ben

Thoughts?

-vince

--
-vince

--
-vince

---

From: <[email-masked]>
Date: Tue, 23 Oct 2012 21:23:19 +0000

Yes, I also think that separating the device location and antenna parameters is a good approach. This is what the requirements document requires too.
So, send the device's (lon, lat, alt) location with related uncertainties and datum; and separately, the antenna parameters. The DB can then combine them, if it needs to, to provide the list of available channels.

-          Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Benjamin A. Rolfe
Sent: Friday, October 12, 2012 1:43 PM
To: [email-masked]
Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"?

-Ben

(my 2 cents)

Hope that helps.
Ben

Thoughts?

-vince

--
-vince

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Sun, 28 Oct 2012 12:25:39 -0700

All,

I'd like to address this at the F2F as an open issue, though I think we are
mostly in agreement.
The only point of discussion seems to be how to represent the (lat, lon,
height) in the protocol messages.

1. In the interest of avoiding ambiguity in the "generic"
Device-to-Database protocol, it still seems
    more precise for the device to report (only) the location of its
antenna's radiation center:

    (lat, lon, height)

   with associated uncertainties, etc, and where height is optional for
some types of devices.

  That's the only relevant location when determining available spectrum. It
seems that that's
  the intent of the FCC rules, even though the text does say "device
location".

2. We probably should allow automated GPS-reporting of the location of the
antenna's radiation
   center. Since GPS cannot report height above ground, the protocol should
allow the height to be
   entered as:

   - Height relative to ground/surface (manually entered by installer)
   - Height relative to mean sea level (reported by GPS)

   A regulatory domain could restrict to be only one of these.

-vince

On Tue, Oct 23, 2012 at 2:23 PM, <[email-masked]> wrote:

>  Yes, I also think that separating the device location and antenna
> parameters is a good approach. This is what the requirements document
> requires too.****
>
> So, send the device’s (lon, lat, alt) location with related uncertainties
> and datum; and separately, the antenna parameters. The DB can then combine
> them, if it needs to, to provide the list of available channels.****
>
> ** **
>
> **-          **Gabor ****
>
> ** **
>
>
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 29 Oct 2012 10:30:31 -0400

I think several participants have asked that the "device location" to be expressed as lat/lon, with optional height, and the antenna to be specified as height above ground.  I think that is the most practical way to obtain the data, and is what the current regulations require.  I think it is a mistake to try to specify radiation center as the input variable because it conflates what you know.  The device itself or an installer can measure the location of the device.  GPS is not accurate with respect to height in most cases, but it would be forward looking to allow device location to include height.  What we do now is use a terrain database to determine height of the device.  The antenna height is a measured quantity.  It's often fixed, or the installer knows it.  It's the height, not the radiation center, that is measured.

Brian

On Oct 28, 2012, at 3:25 PM, Vincent Chen <[email-masked]<mailto:[email-masked]>> wrote:

All,

I'd like to address this at the F2F as an open issue, though I think we are mostly in agreement.
The only point of discussion seems to be how to represent the (lat, lon, height) in the protocol messages.

1. In the interest of avoiding ambiguity in the "generic" Device-to-Database protocol, it still seems
    more precise for the device to report (only) the location of its antenna's radiation center:

    (lat, lon, height)

   with associated uncertainties, etc, and where height is optional for some types of devices.

  That's the only relevant location when determining available spectrum. It seems that that's
  the intent of the FCC rules, even though the text does say "device location".

2. We probably should allow automated GPS-reporting of the location of the antenna's radiation
   center. Since GPS cannot report height above ground, the protocol should allow the height to be
   entered as:

-vince

On Tue, Oct 23, 2012 at 2:23 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Yes, I also think that separating the device location and antenna parameters is a good approach. This is what the requirements document requires too.
So, send the device’s (lon, lat, alt) location with related uncertainties and datum; and separately, the antenna parameters. The DB can then combine them, if it needs to, to provide the list of available channels.

-          Gabor