You are absolutely right. Khalid did say that he didn't know a great deal about 802.11, and we did discuss the timing problems in particular.
--Martin
On 2011-11-01 at 07:01:03, Gabor.Bajko@nokia.com wrote:
> I don't necessarily agree with all the comments. Specifically:
>
> band: The frequency band for the radio, in gigahertz (GHz). 802.11
> [IEEE.80211] specifies PHY layers that use 2.4, 3.7 and 5
> gigahertz frequency bands.
> I think it is not so useful, again, for other than RF finger printing
> matching.
>
> <Gabor> wifi coverage depends on the band. There is a significant
> difference when the STA sees a beacon from an AP in 5GHz band vs a
> 2.4GHz band. In 5G the STA must be much closer to the AP to see the
> beacon than it could in 2.4G. Same goes for network type, as 11a works
> in 5G, while 11b in 2.4G
>
>
> channel: The channel number (frequency) that the access point
> operates on.
> Correct, but probably with limited usefulness. Maybe useful for RF
> signature matching location techniques, but channel number is
> changeable by the user, though it very seldom occurs.
>
> <Gabor> In managed networks, APs change dynamically their operating
> channel to avoid overlapping BSS operations.
>
>
> flightTime: Flight time is the difference between the time of
> departure (TOD) of signal from a transmitting station and time of
> arrival (TOA) of signal at a receiving station, as defined in
> [IEEE.80211V]. Measurement of this value requires that stations
> synchronize their clocks. This value can be measured by access
> point or Device; because the flight time is assumed to be the
> same
> in either direction - aside from measurement errors - only a
> single element is provided. This element includes optional
> "rmsError" and "samples" attributes. RMS error might be derived
> from the reported RMS error in TOD and TOA.
> I think this field could be very useful if it was possible to measure
> it accurately, which I think it is not possible. In order use the
> Flight Time for range determination, both the transmitting and
> receiving ends should be synchronized to within 50nsec. This is not
> possible if the device and AP don't have access to a common reference
> time, such as GPS time. NTP sync won't achieve such accuracy, as far
> as I know. However, a more robust measurement would be Total Flight
> Time, or Round Trip Time. With such measurement, the device would
> loop back a signal, like a ping message for example, to the AP and the
> AP measures the round trip time. Time synchronization is not
> necessary in this case. Furthermore, there are ways to make this more
> accurate, similar to LTE, where the Device can send to the AP the
> Tx-to-Rx time difference in the device in order to compensate for the
> Rx-to-Tx path delay within the device. Lastly, it is implied that
> both the device and the AP have time t agging capability that has
> 50nsec resolution, which may be impractical, but I don't know that for
> sure and can research it if needed.
>
> <Gabor> STA and AP do not need a common reference time, as the STA
> syncs its clock to the AP's clock, before measuring the flight time.
> The accuracy of 50ns is desirable and it depends on how accurately can
> the wifi chips timestamp the messages. According to some chipset
> vendors, they are getting close to that number.
>
> -Gabor
>
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of ext Thomson, Martin
> Sent: Thursday, October 27, 2011 3:44 PM
> To: GEOPRIV
> Subject: [Geopriv] Expert review of location measurements
>
> The following is a review of draft-ietf-geopriv-held-measurements-03
> by Khalid Al Mufti, one of the location experts working for Commscope.
> I asked Khalid to provide a critique of Section 5.3, particularly with
> respect to the usefulness of the parameters for location.
>
> I'll correct the mistakes Khalid noticed in the next revision.
>
> --Martin
> ----
>
> 5.3. 802.11 WLAN Measurements
>
>
> In WiFi, or 802.11 [IEEE.80211], networks a Device might be able to
> provide information about the access point (AP) that it is attached
> to, or other WiFi points it is able to see. This is provided using
> the "wifi" element, as shown in Figure 6, which shows a single
> complete measurement for a single access point.
>
> [MT: snipped example]
>
> Figure 6: 802.11 WLAN Measurement Example
>
> A wifi element is made up of one or more access points, and an
> optional "nicType" element. Each access point is described using
> the
> "ap" element, which is comprised of the following fields:
>
> bssid: The basic service set identifier. In an Infrastructure BSS
> network, the bssid is the 48 bit MAC address of the access point.
>
> The "verified" attribute of this element describes whether the
> device has verified the MAC address or it authenticated the
> access
> point or the network operating the access point (for example, a
> captive portal accessed through the access point has been
> authenticated). This attributes defaults to a value of "false"
> when omitted.
>
> ssid: The service set identifier (SSID) for the wireless network
> served by the access point.
>
> The SSID is a 32-octet identifier that is commonly represented as
> a ASCII [RFC0020] or UTF-8 [RFC3629] encoded string. To
> represent
> octets that cannot be directly included in an XML element,
> escaping is used. Sequences of octets that do not represent a
> valid UTF-8 encoding can be escaped using a backslash ('\')
> followed by two case-insensitive hexadecimal digits representing
> the value of a single octet.
>
> The canonical or value-space form of an SSID is a sequence of up
> to 32 octets that is produced from the concatenation of UTF-8
> encoded sequences of unescaped characters and octets derived from
> escaped components.
> From what I can tell this is correct. It is useful, especially for
> location determination based on searching databases of SSID-Location.
>
> channel: The channel number (frequency) that the access point
> operates on.
> Correct, but probably with limited usefulness. Maybe useful for RF
> signature matching location techniques, but channel number is
> changeable by the user, though it very seldom occurs.
>
> location: The location of the access point, as reported by the
> access point. This element contains any valid location, using
> the
> rules for a "location-info" element, as described in [RFC5491].
> Really useful, but sounds like operator entered info (like street
> address), therefore it is useful, especially if it is augmented by the
> SSID-location database matching techniques.
>
> type: The network type for the network access. This element
> includes the alphabetic suffix of the 802.11 specification that
> introducted the radio interface, or PHY; e.g. "a", "b", "g", or
> "n".
> Other than for pattern matching techniques, I think it is not so
> useful.
>
> band: The frequency band for the radio, in gigahertz (GHz). 802.11
> [IEEE.80211] specifies PHY layers that use 2.4, 3.7 and 5
> gigahertz frequency bands.
> I think it is not so useful, again, for other than RF finger printing
> matching.
>
>
> regclass: The regulatory domain and class. The "country" attribute
> optionally includes the applicable two character country
> identifier (dot11CountryString), which can be followed by an 'O',
> 'I' or 'X'. The element text content includes the value of the
> regulatory class: an 8-bit integer in decimal form.
> If I understood this field correctly, I think it may depend on the
> ISP, which may be located far from the AP, thus have a country string
> it is a continent away. That's probably rare, but not impossible. If
> so, then it's not useful, in my opinion.
>
>
> antenna: The antenna identifier for the antenna that the access
> point is using to transmit the measured signals.
> From what I know, most APs have a single antenna, or two antenna's for
> MIMO type communication. But the antennas are very closely spaced, so
> identifying which antenna is used for Tx/Rx is not helpful for
> location. Unless there's an antenna in each floor in a building for
> the same AP (a configuration which I am not familiar with) then maybe
> identifying which Antenna the device is connecting to the AP through
> helps identify in what floor the device is located. So in such
> scenarios this field is useful, otherwise it is useless from what I
> can tell.
>
> flightTime: Flight time is the difference between the time of
> departure (TOD) of signal from a transmitting station and time of
> arrival (TOA) of signal at a receiving station, as defined in
> [IEEE.80211V]. Measurement of this value requires that stations
> synchronize their clocks. This value can be measured by access
> point or Device; because the flight time is assumed to be the
> same
> in either direction - aside from measurement errors - only a
> single element is provided. This element includes optional
> "rmsError" and "samples" attributes. RMS error might be derived
> from the reported RMS error in TOD and TOA.
> I think this field could be very useful if it was possible to measure
> it accurately, which I think it is not possible. In order use the
> Flight Time for range determination, both the transmitting and
> receiving ends should be synchronized to within 50nsec. This is not
> possible if the device and AP don't have access to a common reference
> time, such as GPS time. NTP sync won't achieve such accuracy, as far
> as I know. However, a more robust measurement would be Total Flight
> Time, or Round Trip Time. With such measurement, the device would
> loop back a signal, like a ping message for example, to the AP and the
> AP measures the round trip time. Time synchronization is not
> necessary in this case. Furthermore, there are ways to make this more
> accurate, similar to LTE, where the Device can send to the AP the
> Tx-to-Rx time difference in the device in order to compensate for the
> Rx-to-Tx path delay within the device. Lastly, it is implied that
> both the device and the AP have time t agging capability that has
> 50nsec resolution, which may be impractical, but I don't know that for
> sure and can research it if needed.
>
> apSignal: Measurement information for the signal transmitted by the
> access point, as observed by the Device. Some of these values
> are
> derived from 802.11v [IEEE.80211V] messages exchanged between
> Device and access point. The contents of this element include:
>
> transmit: The transmit power reported by the access point, in
> dB.
> I think it is useful as part of determining the path loss from AP to
> device, thus deducing range using log-normal propagation model. Its
> measurement unit is incorrectly written; it should be in dBm not
> measured in dB.
>
>
> gain: The gain of the access point antenna reported by the
> access
> point, in dB.
> I think it is useful as part of determining the path loss from AP to
> device, thus deducing range using log-normal propagation model. It is
> correctly specified in dB. I assume this is user entered info,
> though, so possibly subject to operator error. Nonetheless, it is
> needed for proper path loss determination, and should be included.
>
> rcpi: The received channel power indicator for the access point
> signal, as measured by the Device. This value SHOULD be in
> units of dBm (with RMS error in dB). If power is measured in
> a
> different fashion, the "dBm" attribute MUST be set to "false".
> Signal strength reporting on current hardware uses a range of
> different mechanisms; therefore, the value of the "nicType"
> element SHOULD be included if the units are not known to be in
> dBm and the value reported by the hardware should be included
> without modification. This element includes optional
> "rmsError" and "samples" attributes.
> I think it is useful as part of determining the path loss from AP to
> device, thus deducing range using log-normal propagation model.
>
> rsni: The received signal to noise indicator in dBm. This
> element includes optional "rmsError" and "samples" attributes.
> I think it can be considered as useful information. It can be used to
> verify that a high rcpi measurement is not due to something like
> interference.
>
> deviceSignal: Measurement information for the signal transmitted by
> the device, as reported by the access point. This element
> contains the same child elements as the "ap" element, with the
> access point and Device roles reversed.
>
> If we assume the RF path is symmetric between UL and DL then
> technically this is a redundant field (since we're after range
> determination through RF path loss modeling, I assume). However, it
> probably helps to have the opposite direction measurements for
> verification purposes. For instance, if both sides agree, then it
> increases confidence in the path loss estimate. So I think it is a
> good to have in addition to the APSignal measurements.
>
> All elements are optional except for "bssid".
>
> The "nicType" element is used to specify the make and model of the
> wireless network interface in the Device. Different 802.11 chipsets
> report measurements in different ways, so knowing the network
> interface type aids the LIS in determining how to use the provided
> measurement data. The content of this field is unconstrained and no
> mechanisms are specified to ensure uniqueness.
>
> 5.3.1. Wifi Measurement Requests
>
>
> Two elements are defined for requesting WiFi measurements in a
> measurement request:
>
> type: The "type" element identifies the desired type (or types that
> are requested.
>
> parameter: The "parameter" element identifies an optional
> measurements are requested for each measured access point. An
> element is identified by its qualified name. The optional
> "context" parameter can be used to specify if an element is
> included as a child of the "ap" or "device" elements; omission
> indicates that it applies to both.
>
> Multiple types or parameters can be requested by repeating either
> element.
>
>
> _______________________________________________
> 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
