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 > > On 10/11/2012 5:40 AM, Peter Stanforth wrote: >> 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 protected]> 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 >>> >>> On Oct 11, 2012, at 12:53 AM, Vincent Chen<[email protected]> 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 >>>> >>>> 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 >>>> _______________________________________________ >>>> paws mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/paws >> > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
