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
