This was something that folks in my company have suggested to me would be useful. We're starting to see access points with distributed antennae. Some of these can report what antenna is used for a particular transmission, which can help greatly with positioning if the characteristics of the antenna are known.
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Thomson, Martin
> Sent: Tuesday, 3 August 2010 10:24 AM
> To: geopriv@ietf.org; Gabor.Bajko@nokia.com
> Subject: [Geopriv] 802.11 measurements
>
> Gabor has provided some excellent feedback on the measurement
> definition in the -measurements draft.
>
> I plan to make the following changes, with the possible exception of
> one final item, which I will explain below.
>
> 1. Change wap to ap in line with 802.11 terminology.
>
> 2. Add location, as reported by the AP.
>
> 3. Add a "verified" tag to the BSSID. It is possible for a device to
> gain an assurance that the BSSID is correct. This Boolean attribute
> simply labels the BSSID as good. This doesn't help with the spoofing
> problem, but it can be used to filter bad data. In particular, this
> helps with the attack that has an attacker deploy a number of access
> points in order to alter the measurements that a device gets. (Come to
> think of it, this sort of attack probably needs text too.)
>
> 4. Remove round trip delay, which is difficult (or nigh impossible) to
> measure when scheduling delays are considered. The approach that is
> being taken in 802.11 is to synchronize clocks and measure the one way
> flight time. Either node can measure this value, but since it's the
> same underlying value, there will only be a single flight time (as
> opposed to an rtd in both directions).
>
> 5. The potentially controversial suggestion is the removal of channel.
> It's possible that this value changes over time, rendering it
> effectively useless. However, in a lot of cases, the channel remains
> static. Therefore, I am inclined to retain channel, even though it
> might not provide any assistance in some deployments.
>
> --Martin
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
