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