Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7105

Using Device-Provided Location-Related Measurements in Location Configuration Protocols

Pages: 74
Proposed Standard
Errata
Part 1 of 4 – Pages 1 to 13
None   None   Next

Top   ToC   RFC7105 - Page 1
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 Protocols

Abstract

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.
Top   ToC   RFC7105 - Page 2
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
Top   ToC   RFC7105 - Page 3
   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
Top   ToC   RFC7105 - Page 4
      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
Top   ToC   RFC7105 - Page 5
   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].
Top   ToC   RFC7105 - Page 6

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.
Top   ToC   RFC7105 - Page 7
   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 Example

4.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".
Top   ToC   RFC7105 - Page 8
   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.
Top   ToC   RFC7105 - Page 9

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.
Top   ToC   RFC7105 - Page 10
   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.
Top   ToC   RFC7105 - Page 11
   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.
Top   ToC   RFC7105 - Page 12
   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>
Top   ToC   RFC7105 - Page 13
             </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)

Next Section