tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7105

Proposed STD
Pages: 74
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: GEOPRIV

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

Part 1 of 4, p. 1 to 13
None       Next RFC Part

 


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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       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 RFC Part