Subject: [Geopriv] Expert review of location measurements

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 28 Oct 2011 06:43:45 +0800

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

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 20:01:03 +0000

I don't necessarily agree with all the comments. Specifically:

<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

<Gabor> In managed networks, APs change dynamically their operating channel to avoid overlapping BSS operations.

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Thomson, Martin
Sent: Thursday, October 27, 2011 3:44 PM
To: GEOPRIV
Subject: [Geopriv] Expert review of location measurements

--Martin
----

[MT: snipped example]

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.

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 1 Nov 2011 07:05:29 +0800

Hi Gabor,

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, [email-masked] wrote:
> <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
>
>
> 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.
>
>
> 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
>
> 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.
>
> From what I can tell this is correct.  It is useful, especially for
> location determination based on searching databases of SSID-Location.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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.
>
> 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.
>
> 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.
>
>
> 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.
>
> I think it is useful as part of determining the path loss from AP to
> device, thus deducing range using log-normal propagation model.
>
> 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.
>
> 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.
>