Re: [Geopriv] 802.11 measurements

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Thu Aug 05 2010 - 00:34:29 EDT

I forgot to mention that we'd also discussed antenna ID.
        
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
Received on Thu, 5 Aug 2010 12:34:29 +0800

This archive was generated by hypermail 2.1.8 : Thu Aug 05 2010 - 00:38:04 EDT