RFC 7105
Using Device-Provided Location-Related Measurements in Location Configuration Protocols
Internet Engineering Task Force (IETF) M. Thomson Request for Comments: 7105 Mozilla Category: Standards Track J. Winterbottom ISSN: 2070-1721 Unaffiliated January 2014 Using Device-Provided Location-Related Measurements in Location Configuration ProtocolsAbstract
This document describes a protocol for a Device to provide location- related measurement data to a Location Information Server (LIS) within a request for location information. Location-related measurement information provides observations concerning properties related to the position of a Device; this information could be data about network attachment or about the physical environment. A LIS is able to use the location-related measurement data to improve the accuracy of the location estimate it provides to the Device. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7105.
Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction ....................................................4 2. Conventions Used in This Document ...............................5 3. Location-Related Measurements in LCPs ...........................6 4. Location-Related Measurement Data Types .........................7 4.1. Measurement Container ......................................7 4.1.1. Time of Measurement .................................8 4.1.2. Expiry Time on Location-Related Measurement Data ....8 4.2. RMS Error and Number of Samples ............................9 4.2.1. Time RMS Error ......................................9 4.3. Measurement Request .......................................10 4.4. Identifying Location Provenance ...........................11 5. Location-Related Measurement Data Types ........................13 5.1. LLDP Measurements .........................................13 5.2. DHCP Relay Agent Information Measurements .................14 5.3. 802.11 WLAN Measurements ..................................15 5.3.1. WiFi Measurement Requests ..........................18 5.4. Cellular Measurements .....................................18 5.4.1. Cellular Measurement Requests ......................22 5.5. GNSS Measurements .........................................22 5.5.1. GNSS: System Type and Signal .......................23 5.5.2. Time ...............................................24 5.5.3. Per-Satellite Measurement Data .....................24 5.5.4. GNSS Measurement Requests ..........................25 5.6. DSL Measurements ..........................................25 5.6.1. L2TP Measurements ..................................26 5.6.2. RADIUS Measurements ................................26 5.6.3. Ethernet VLAN Tag Measurements .....................27 5.6.4. ATM Virtual Circuit Measurements ...................28
6. Privacy Considerations .........................................28 6.1. Measurement Data Privacy Model ............................28 6.2. LIS Privacy Requirements ..................................29 6.3. Measurement Data and Location URIs ........................29 6.4. Measurement Data Provided by a Third Party ................30 7. Security Considerations ........................................30 7.1. Threat Model ..............................................30 7.1.1. Acquiring Location Information without Authorization ......................................31 7.1.2. Extracting Network Topology Data ...................32 7.1.3. Exposing Network Topology Data .....................32 7.1.4. Lying by Proxy .....................................33 7.1.5. Measurement Replay .................................33 7.1.6. Environment Spoofing ...............................34 7.2. Mitigation ................................................35 7.2.1. Measurement Validation .............................36 7.2.1.1. Effectiveness .............................36 7.2.1.2. Limitations (Unique Observer) .............37 7.2.2. Location Validation ................................38 7.2.2.1. Effectiveness .............................38 7.2.2.2. Limitations ...............................39 7.2.3. Supporting Observations ............................39 7.2.3.1. Effectiveness .............................40 7.2.3.2. Limitations ...............................40 7.2.4. Attribution ........................................40 7.2.5. Stateful Correlation of Location Requests ..........42 7.3. An Unauthorized or Compromised LIS ........................42 8. Measurement Schemas ............................................42 8.1. Measurement Container Schema ..............................43 8.2. Measurement Source Schema .................................45 8.3. Base Types Schema .........................................46 8.4. LLDP Measurement Schema ...................................49 8.5. DHCP Measurement Schema ...................................50 8.6. WiFi Measurement Schema ...................................51 8.7. Cellular Measurement Schema ...............................55 8.8. GNSS Measurement Schema ...................................57 8.9. DSL Measurement Schema ....................................59 9. IANA Considerations ............................................61 9.1. IANA Registry for GNSS Types ..............................61 9.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc ...............62 9.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm .........................63 9.4. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:basetypes ...............63 9.5. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:lldp ....................64
9.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dhcp ....................65
9.7. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:wifi ....................65
9.8. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:cell ....................66
9.9. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:gnss ....................67
9.10. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dsl ....................67
9.11. XML Schema Registration for Measurement Source Schema ....68
9.12. XML Schema Registration for Measurement Container
Schema ...................................................68
9.13. XML Schema Registration for Base Types Schema ............69
9.14. XML Schema Registration for LLDP Schema ..................69
9.15. XML Schema Registration for DHCP Schema ..................69
9.16. XML Schema Registration for WiFi Schema ..................69
9.17. XML Schema Registration for Cellular Schema ..............70
9.18. XML Schema Registration for GNSS Schema ..................70
9.19. XML Schema Registration for DSL Schema ...................70
10. Acknowledgements ..............................................70
11. References ....................................................71
11.1. Normative References .....................................71
11.2. Informative References ...................................73
1. Introduction
A Location Configuration Protocol (LCP) provides a means for a Device
to request information about its physical location from an access
network. A Location Information Server (LIS) is the server that
provides location information that is available due to the knowledge
it has about the network and physical environment.
As a part of the access network, the LIS is able to acquire
measurement results related to Device location from network elements.
The LIS also has access to information about the network topology
that can be used to turn measurement data into location information.
This information can be further enhanced with information acquired
from the Device itself.
A Device is able to make observations about its network attachment,
or its physical environment. The location-related measurement data
might be unavailable to the LIS; alternatively, the LIS might be able
to acquire the data, but at a higher cost in terms of time or some
other metric. Providing measurement data gives the LIS more options
in determining location; this could in turn improve the quality of
the service provided by the LIS. Improvements in accuracy are one potential gain, but improved response times and lower error rates are also possible. This document describes a means for a Device to report location- related measurement data to the LIS. Examples based on the HTTP-Enabled Location Delivery (HELD) [RFC5985] location configuration protocol are provided.2. Conventions Used in This Document
The terms "LIS" and "Device" are used in this document in a manner consistent with the usage in [RFC5985]. This document also uses the following definitions: Location Measurement: An observation about the physical properties of a particular Device's position in time and space. The result of a location measurement -- "location-related measurement data", or simply "measurement data" given sufficient context -- can be used to determine the location of a Device. Location-related measurement data does not directly identify a Device, though it could do so indirectly. Measurement data can change with time if the location of the Device also changes. Location-related measurement data does not necessarily contain location information directly, but it can be used in combination with contextual knowledge and/or algorithms to derive location information. Examples of location-related measurement data are radio signal strength or timing measurements, Ethernet switch identifiers, and port identifiers. Location-related measurement data can be considered sighting information, based on the definition in [RFC3693]. Location Estimate: An approximation of where the Device is located. Location estimates are derived from location measurements. Location estimates are subject to uncertainty, which arises from errors in measurement results. GNSS: Global Navigation Satellite System. A satellite-based system that provides positioning and time information -- for example, the US Global Positioning System (GPS) or the European Galileo system. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
3. Location-Related Measurements in LCPs
This document defines a standard container for the conveyance of location-related measurement parameters in location configuration protocols. This is an XML container that identifies parameters by type and allows the Device to provide the results of any measurement it is able to perform. A set of measurement schemas are also defined that can be carried in the generic container. A simple example of measurement data conveyance is illustrated by the example message in Figure 1. This shows a HELD location request message with an Ethernet switch and port measurement taken using the Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB]. <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationType exact="true">civic</locationType> <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" time="2008-04-29T14:33:58"> <lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp"> <chassis type="4">0a01003c</chassis> <port type="6">c2</port> </lldp> </measurements> </locationRequest> Figure 1: HELD Location Request with Measurement Data This LIS can ignore measurement data that it does not support or understand. The measurements defined in this document follow this rule: extensions that could result in backward incompatibility MUST be added as new measurement definitions rather than extensions to existing types. Multiple sets of measurement data, either of the same type or from different sources, can be included in the "measurements" element. See Section 4.1.1 for details on repetition of this element. A LIS can choose to use or ignore location-related measurement data in determining location, as long as rules regarding use and retention (Section 6) are respected. The "method" parameter in the Presence Information Data Format - Location Object (PIDF-LO) [RFC4119] SHOULD be adjusted to reflect the method used. A correct "method" can assist location recipients in assessing the quality (both accuracy and integrity) of location information, though there could be reasons to withhold information about the source of data.
Measurement data is typically only used to serve the request in which it is included. There may be exceptions, particularly with respect to location URIs. Section 6 provides more information on usage rules. Location-related measurement data need not be provided exclusively by Devices. A third-party location requester (for example, see [RFC6155]) can request location information using measurement data, if the requester is able to acquire measurement data and authorized to distribute it. There are specific privacy considerations relating to the use of measurements by third parties, which are discussed in Section 6.4. Location-related measurement data and its use present a number of privacy and security challenges. These are described in more detail in Sections 6 and 7.4. Location-Related Measurement Data Types
A common container is defined for the expression of location measurement data, as well as a simple means of identifying specific types of measurement data for the purposes of requesting them. The following example shows a measurement container with measurement time and expiration time included. A WiFi measurement is enclosed. <lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm" time="2008-04-29T14:33:58" expires="2008-04-29T17:33:58"> <wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi"> <ap serving="true"> <bssid>00-12-F0-A0-80-EF</bssid> <ssid>wlan-home</ssid> </ap> </wifi> </lm:measurements> Figure 2: Measurement Example4.1. Measurement Container
The "measurements" element is used to encapsulate measurement data that is collected at a certain point in time. It contains time-based attributes that are common to all forms of measurement data, and it permits the inclusion of arbitrary measurement data. The elements that are included within the "measurements" element are generically referred to as "measurement elements".
This container can be added to a request for location information in any protocol capable of carrying XML, such as a HELD location request [RFC5985].4.1.1. Time of Measurement
The "time" attribute records the time that the measurement or observation was made. This time can be different from the time that the measurement information was reported. Time information can be used to populate a timestamp on the location result or to determine if the measurement information is used. The "time" attribute SHOULD be provided whenever possible. This allows a LIS to avoid selecting an arbitrary timestamp. Exceptions to this, where omitting time might make sense, include relatively static types of measurement (for instance, the DSL measurements in Section 5.6) or for legacy Devices that don't record time information (such as the Home Location Register/Home Subscriber Server for cellular). The "time" attribute is attached to the root "measurement" element. Multiple measurements can often be given the same timestamp, even when the measurements were not actually taken at the same time (consider a set of measurements taken sequentially, where the difference in time between observations is not significant). Measurements cannot be grouped if they have different types or if there is a need for independent time values on each measurement. In these instances, multiple measurement sets are necessary.4.1.2. Expiry Time on Location-Related Measurement Data
A Device is able to indicate an expiry time in the location measurement using the "expires" attribute. Nominally, this attribute indicates how long information is expected to be valid, but it can also indicate a time limit on the retention and use of the measurement data. A Device can use this attribute to request that the LIS not retain measurement data beyond the indicated time. Note: Movement of the Device might result in the measurement data being invalidated before the expiry time. A Device is advised to set the "expires" attribute to the earlier of the time that measurements are likely to be unusable and the time that it desires to have measurements discarded by the LIS. A Device that does not desire measurement data to be retained can omit the "expires" attribute. Section 6 describes more specific rules regarding measurement data retention.
4.2. RMS Error and Number of Samples
Often a measurement is taken more than once. Reporting the average of a number of measurement results mitigates the effects of random errors that occur in the measurement process. Reporting each measurement individually can be the most effective method of reporting multiple measurements. This is achieved by providing multiple measurement elements for different times. The alternative is to aggregate multiple measurements and report a mean value across the set of measurements. Additional information about the distribution of the results can be useful in determining location uncertainty. Two attributes are provided for use on some measurement values: rmsError: The root-mean-squared (RMS) error of the set of measurement values used in calculating the result. RMS error is expressed in the same units as the measurement, unless otherwise stated. If an accurate value for the RMS error is not known, this value can be used to indicate an upper bound or estimate for the RMS error. samples: The number of samples that were taken in determining the measurement value. If omitted, this value can be assumed to be large enough that the RMS error is an indication of the standard deviation of the sample set. For some measurement techniques, measurement error is largely dependent on the measurement technique employed. In these cases, measurement error is largely a product of the measurement technique and not the specific circumstances, so the RMS error does not need to be actively measured. A fixed value MAY be provided for the RMS error where appropriate. The "rmsError" and "samples" elements are added as attributes of specific measurement data types.4.2.1. Time RMS Error
Measurement of time can be significant in certain circumstances. The GNSS measurements included in this document are one such case where a small error in time can result in a large error in location. Factors such as clock drift and errors in time synchronization can result in small, but significant, time errors. Including an indication of the quality of time measurements can be helpful.
A "timeError" attribute MAY be added to the "measurement" element to indicate the RMS error in time. "timeError" indicates an upper bound on the time RMS error in seconds. The "timeError" attribute does not apply where multiple samples of a measurement are taken over time. If multiple samples are taken, each SHOULD be included in a different "measurement" element.4.3. Measurement Request
A measurement request is used by a protocol peer to describe a set of measurement data that it desires. A "measurementRequest" element is defined that can be included in a protocol exchange. For instance, a LIS can use a measurement request in HELD responses. If the LIS is unable to provide location information, but it believes that a particular measurement type would enable it to provide a location, it can include a measurement request in an error response. The "measurement" element of the measurement request identifies the type of measurement that is requested. The "type" attribute of this element indicates the type of measurement, as identified by an XML qualified name. A "samples" attribute MAY be used to indicate how many samples of the identified measurement are requested. The "measurement" element can be repeated to request multiple (or alternative) measurement types. Additional XML content might be defined for a particular measurement type that is used to further refine a request. These elements either constrain what is requested or specify non-mandatory components of the measurement data that are needed. These are defined along with the specific measurement type. In the HELD protocol, the inclusion of a measurement request in an error response with a code of "locationUnknown" indicates that providing measurements would increase the likelihood of a subsequent request being successful.
The following example shows a HELD error response that indicates that WiFi measurement data would be useful if a later request were made. Additional elements indicate that received signal strength for an 802.11n access point is requested. <error xmlns="urn:ietf:params:xml:ns:geopriv:held" code="locationUnknown"> <message xml:lang="en">Insufficient measurement data</message> <measurementRequest xmlns="urn:ietf:params:xml:ns:geopriv:lm" xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi"> <measurement type="wifi:wifi"> <wifi:type>n</wifi:type> <wifi:parameter context="ap">wifi:rcpi</wifi:parameter> </measurement> </measurementRequest> </error> Figure 3: HELD Error Requesting Measurement Data A measurement request that is included in other HELD messages has undefined semantics and can be safely ignored. Other specifications might define semantics for measurement requests under other conditions.4.4. Identifying Location Provenance
An extension is made to the PIDF-LO [RFC4119] that allows a location recipient to identify the source (or sources) of location information and the measurement data that was used to determine that location information. The "source" element is added to the "geopriv" element of the PIDF-LO. This element does not identify specific entities. Instead, it identifies the type of measurement source. The following values are defined for the "source" element: lis: Location information is based on measurement data that the LIS or sources that it trusts have acquired. This label MAY be used if measurement data provided by the Device has been completely validated by the LIS. device: A LIS MUST include this value if the location information is based (in whole or in part) on measurement data provided by the Device and if the measurement data isn't completely validated.
other: Location information is based on measurement data that a
third party has provided. This might be an authorized third party
that uses identity parameters [RFC6155] or any other entity. The
LIS MUST include this, unless the third party is trusted by the
LIS to provide measurement data.
No assertion is made about the veracity of the measurement data from
sources other than the LIS. A combination of tags MAY be included to
indicate that measurement data from multiple types of sources was
used.
For example, the first tuple of the following PIDF-LO indicates that
measurement data from a LIS and a Device was combined to produce the
result; the second tuple was produced by the LIS alone.
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
entity="pres:lm@example.com">
<tuple id="deviceLoc">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>7.34324 134.47162</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</gp:location-info>
<gp:usage-rules/>
<gp:method>OTDOA</gp:method>
<lmsrc:source>lis device</lmsrc:source>
</gp:geopriv>
</status>
</tuple>
<tuple id="lisLoc">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>7.34379 134.46484</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
9000
</gs:radius>
</gs:Circle>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Cell</gp:method>
<lmsrc:source>lis</lmsrc:source>
</gp:geopriv>
</status>
</tuple>
</presence>
PIDF-LO Document with Source Labels
(page 13 continued on part 2)
