Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 7105

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

Pages: 74
Proposed Standard
Part 2 of 4 – Pages 13 to 30
First   Prev   Next

Top   ToC   RFC7105 - Page 13   prevText

5. Location-Related Measurement Data Types

This document defines location-related measurement data types for a range of common network types. All included measurement data definitions allow for arbitrary extension in the corresponding schema. New parameters that are applicable to location determination are added as new XML elements in a unique namespace, not by adding elements to an existing namespace.

5.1. LLDP Measurements

Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent between adjacent nodes in an IEEE 802 network (e.g., wired Ethernet, WiFi, 802.16). These messages all contain identification information for the sending node; the identification information can be used to determine location information. A Device that receives LLDP messages can report this information as a location-related measurement to the LIS, which is then able to use the measurement data in determining the location of the Device. Note: The LLDP extensions defined in LLDP Media Endpoint Discovery (LLDP-MED) [ANSI-TIA-1057] provide the ability to acquire location information directly from an LLDP endpoint. Where this information is available, it might be unnecessary to use any other form of location configuration. Values are provided as hexadecimal sequences. The Device MUST report the values directly as they were provided by the adjacent node. Attempting to adjust or translate the type of identifier is likely to cause the measurement data to be useless. Where a Device has received LLDP messages from multiple adjacent nodes, it should provide information extracted from those messages by repeating the "lldp" element.
Top   ToC   RFC7105 - Page 14
   An example of an LLDP measurement is shown in Figure 4.  This shows
   an adjacent node (chassis) that is identified by the IP address (hexadecimal c000022d), and the port on that node is
   numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
       <lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
         <chassis type="4">c000022d</chassis>
         <port type="6">a2</port>

                    Figure 4: LLDP Measurement Example

   IEEE 802 Devices that are able to obtain information about adjacent
   network switches and their attachment to them by other means MAY use
   this data type to convey this information.

5.2. DHCP Relay Agent Information Measurements

The DHCP Relay Agent Information option [RFC3046] provides measurement data about the network attachment of a Device. This measurement data can be included in the "dhcp-rai" element. The elements in the DHCP relay agent information options are opaque data types assigned by the DHCP relay agent. The three items MAY be omitted if unknown: circuit identifier ("circuit", circuit [RFC3046], or Interface-Id [RFC3315]), remote identifier ("remote", Remote ID [RFC3046], or remote-id [RFC4649]), and subscriber identifier ("subscriber", subscriber-id [RFC3993], or Subscriber-ID [RFC4580]). The DHCPv6 remote-id has an associated enterprise number [IANA.enterprise] as an XML attribute. <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" time="2008-04-29T14:33:58"> <dhcp-rai xmlns="urn:ietf:params:xml:ns:geopriv:lm:dhcp"> <giaddr></giaddr> <circuit>108b</circuit> </dhcp-rai> </measurements> Figure 5: DHCP Relay Agent Information Measurement Example
Top   ToC   RFC7105 - Page 15
   The "giaddr" element is specified as a dotted quad IPv4 address or an
   RFC 4291 [RFC4291] IPv6 address, using the forms defined in
   [RFC3986]; IPv6 addresses SHOULD use the form described in [RFC5952].
   The enterprise number is specified as a decimal integer.  All other
   information is included verbatim from the DHCP request in hexadecimal

   The "subscriber" element could be considered sensitive.  This
   information MUST NOT be provided to a LIS that is not authorized to
   receive information about the access network.  See Section 7.1.3 for
   more details.

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) to which it is attached, 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. <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" time="2011-04-29T14:33:58"> <wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi"> <nicType>Intel(r)PRO/Wireless 2200BG</nicType> <ap serving="true"> <bssid>AB-CD-EF-AB-CD-EF</bssid> <ssid>example</ssid> <channel>5</channel> <location> <gml:Point xmlns:gml=""> <gml:pos>-34.4 150.8</gml:pos> </gml:Point> </location> <type>a</type> <band>5</band> <regclass country="AU">2</regclass> <antenna>2</antenna> <flightTime rmsError="4e-9" samples="1">2.56e-9</flightTime> <apSignal> <transmit>23</transmit> <gain>5</gain> <rcpi dBm="true" rmsError="12" samples="1">-59</rcpi> <rsni rmsError="15" samples="1">23</rsni> </apSignal> <deviceSignal> <transmit>10</transmit> <gain>9</gain> <rcpi dBm="true" rmsError="9.5" samples="1">-98.5</rcpi>
Top   ToC   RFC7105 - Page 16
             <rsni rmsError="6" samples="1">7.5</rsni>

                 Figure 6: 802.11 WLAN Measurement Example

   A "wifi" element is made up of one or more access points, and a
   "nicType" element, which MAY be omitted.  Each access point is
   described using the "ap" element, which is comprised of the following

   bssid:  The Basic Service Set (BSS) identifier.  In an Infrastructure
      BSS network, the bssid is the 48-bit MAC address of the access

      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 attribute 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
      an ASCII [ASCII] 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.

   channel:  The channel number (frequency) on which the access point

   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].
Top   ToC   RFC7105 - Page 17
   type:  The network type for the network access.  This element
      includes the alphabetic suffix of the 802.11 specification that
      introduced the radio interface, or PHY, e.g., "a", "b", "g",
      or "n".

   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.

   regclass:  The operating class (regulatory domain and class in older
      versions of 802.11); see Annex E of [IEEE.80211].  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.

   antenna:  The antenna identifier for the antenna that the access
      point is using to transmit the measured signals.

   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.80211].  Measurement of this value requires that stations
      synchronize their clocks.  This value can be measured by an 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 permits the use of the
      "rmsError" and "samples" attributes.  RMS error might be derived
      from the reported RMS error in TOD and TOA.

   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.80211] messages exchanged between the
      Device and access point.  The contents of this element include:

      transmit:  The transmit power reported by the access point,
         in dBm.

      gain:  The gain of the access point antenna reported by the access
         point, in dB.

      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
Top   ToC   RFC7105 - Page 18
         dBm, and the value reported by the hardware should be included
         without modification.  This element permits the use of the
         "rmsError" and "samples" attributes.

      rsni:  The received signal-to-noise indicator in dB.  This element
         permits the use of the "rmsError" and "samples" attributes.

   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.

   The only mandatory element in this structure is "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.  This field is
   unlikely to be useful, except under tightly controlled circumstances.

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 measurements that are requested for each measured access point. An element is identified by its qualified name. The "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.

5.4. Cellular Measurements

Cellular Devices are common throughout the world, and base station identifiers can provide a good source of coarse location information. Cellular measurements can be provided to a LIS run by the cellular operator, or may be provided to an alternative LIS operator that has access to one of several global cell-id to location mapping databases.
Top   ToC   RFC7105 - Page 19
   A number of advanced location determination methods have been
   developed for cellular networks.  For these methods, a range of
   measurement parameters can be collected by the network, Device, or
   both in cooperation.  This document includes a basic identifier for
   the wireless transmitter only; future efforts might define additional
   parameters that enable more accurate methods of location

   The cellular measurement set allows a Device to report to a LIS any
   LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9), or CDMA (Figure 10)
   cells that it is able to observe.  Cells are reported using their
   global identifiers.  All Third Generation Partnership Project (3GPP)
   cells are identified by a public land mobile network (PLMN), which
   comprises a mobile country code (MCC) and mobile network code (MNC);
   specific fields are added for each network type.

   Formats for 3GPP cell identifiers are described in [TS.3GPP.23.003].
   Bit-level formats for CDMA cell identifiers are described in
   [TIA-2000.5]; decimal representations are used.

   MCC and MNC are provided as decimal digit sequences; a leading zero
   in an MCC or MNC is significant.  All other values are decimal

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
       <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">

   Long term evolution (LTE) cells are identified by a 28-bit cell
   identifier (eucid).

                Figure 7: Example LTE Cellular Measurement
Top   ToC   RFC7105 - Page 20
     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
       <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">

   Universal mobile telephony service (UMTS) cells are identified by a
   12- or 16-bit radio network controller (rnc) id and a 16-bit cell id

                Figure 8: Example UMTS Cellular Measurement

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
       <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">

   Global System for Mobile communication (GSM) cells are identified by
   a 16-bit location area code (lac) and a 16-bit cell id (cid).

                Figure 9: Example GSM Cellular Measurement
Top   ToC   RFC7105 - Page 21
     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
       <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">

   Code division multiple access (CDMA) cells are not identified by a
   PLMN; instead, these use a 15-bit system id (sid), a 16-bit network
   id (nid), and a 16-bit base station id (baseid).

               Figure 10: Example CDMA Cellular Measurement

   In general, a cellular Device will be attached to the cellular
   network, so the notion of a serving cell exists.  Cellular networks
   also provide overlap between neighboring sites, so a mobile Device
   can hear more than one cell.  The measurement schema supports sending
   both the serving cell and any other cells that the mobile might be
   able to hear.  In some cases, the Device could simply be listening to
   cell information without actually attaching to the network; mobiles
   without a SIM are an example of this.  In this case, the Device could
   report cells it can hear without identifying any particular cell as a
   serving cell.  An example of this is shown in Figure 11.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
       <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">

             Figure 11: Example Observed Cellular Measurement
Top   ToC   RFC7105 - Page 22

5.4.1. Cellular Measurement Requests

Two elements can be used in measurement requests for cellular measurements: type: A label indicating the type of identifier to provide: one of "gsm", "umts", "lte", or "cdma". network: The network portion of the cell identifier. For 3GPP networks, this is the combination of MCC and MNC; for CDMA, this is the network identifier. Multiple identifier types or networks can be identified by repeating either element.

5.5. GNSS Measurements

A Global Navigation Satellite System (GNSS) uses orbiting satellites to transmit signals. A Device with a GNSS receiver is able to take measurements from the satellite signals. The results of these measurements can be used to determine time and the location of the Device. Determining location and time in autonomous GNSS receivers follows three steps: Signal acquisition: During the signal acquisition stage, the receiver searches for the repeating code that is sent by each GNSS satellite. Successful operation typically requires measurement data for a minimum of 5 satellites. At this stage, measurement data is available to the Device. Navigation message decode: Once the signal has been acquired, the receiver then receives information about the configuration of the satellite constellation. This information is broadcast by each satellite and is modulated with the base signal at a low rate; for instance, GPS sends this information at about 50 bits per second. Calculation: The measurement data is combined with the data on the satellite constellation to determine the location of the receiver and the current time. A Device that uses a GNSS receiver is able to report measurements after the first stage of this process. A LIS can use the results of these measurements to determine a location. In the case where there are fewer results available than the optimal minimum, the LIS might be able to use other sources of measurement information and combine these with the available measurement data to determine a position.
Top   ToC   RFC7105 - Page 23
      Note: The use of different sets of GNSS assistance data can reduce
      the amount of time required for the signal acquisition stage and
      obviate the need for the receiver to extract data on the satellite
      constellation.  Provision of assistance data is outside the scope
      of this document.

   Figure 12 shows an example of GNSS measurement data.  The measurement
   shown is for the GPS satellite system and includes measurement data
   for three satellites only.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
           time="2008-04-29T14:33:58" timeError="2e-5">
       <gnss xmlns="urn:ietf:params:xml:ns:geopriv:lm:gnss"
         system="gps" signal="L1">
         <sat num="19">
           <codephase rmsError="1.6e-9">0.87595747</codephase>
         <sat num="27">
           <codephase rmsError="1.6e-9">0.56639479</codephase>
         <sat num="20">
           <codephase rmsError="1.6e-9">0.57016835</codephase>

                    Figure 12: Example GNSS Measurement

   Each "gnss" element represents a single set of GNSS measurement data,
   taken at a single point in time.  Measurements taken at different
   times can be included in different "gnss" elements to enable
   iterative refinement of results.

   GNSS measurement parameters are described in more detail in the
   following sections.

5.5.1. GNSS: System Type and Signal

The GNSS measurement structure is designed to be generic and to apply to different GNSS types. Different signals within those systems are also accounted for and can be measured separately.
Top   ToC   RFC7105 - Page 24
   The GNSS type determines the time system that is used.  An indication
   of the type of system and signal can ensure that the LIS is able to
   correctly use measurements.

   Measurements for multiple GNSS types and signals can be included by
   repeating the "gnss" element.

   This document creates an IANA registry for GNSS types.  Two satellite
   systems are registered by this document: GPS [GPS.ICD] and Galileo
   [Galileo.ICD].  Details for the registry are included in Section 9.1.

5.5.2. Time

Each set of GNSS measurements is taken at a specific point in time. The "time" attribute is used to indicate the time that the measurement was acquired, if the receiver knows how the time system used by the GNSS relates to UTC time. Alternative to (or in addition to) the measurement time, the "gnssTime" element MAY be included. The "gnssTime" element includes a relative time in milliseconds using the time system native to the satellite system. For the GPS satellite system, the "gnssTime" element includes the time of week in milliseconds. For the Galileo system, the "gnssTime" element includes the time of day in milliseconds. The accuracy of the time measurement provided is critical in determining the accuracy of the location information derived from GNSS measurements. The receiver SHOULD indicate an estimated time error for any time that is provided. An RMS error can be included for the "gnssTime" element, with a value in milliseconds.

5.5.3. Per-Satellite Measurement Data

Multiple satellites are included in each set of GNSS measurements using the "sat" element. Each satellite is identified by a number in the "num" attribute. The satellite number is consistent with the identifier used in the given GNSS. Both the GPS and Galileo systems use satellite numbers between 1 and 64. The GNSS receiver measures the following parameters for each satellite: doppler: The observed Doppler shift of the satellite signal, measured in meters per second. This is converted from a value in Hertz by the receiver to allow the measurement to be used without
Top   ToC   RFC7105 - Page 25
      knowledge of the carrier frequency of the satellite system.  This
      value permits the use of RMS error attributes, also measured in
      meters per second.

   codephase:  The observed code phase for the satellite signal,
      measured in milliseconds.  This is converted from the system-
      specific value of chips or wavelengths into a system-independent
      value.  Larger values indicate larger distances from satellite to
      receiver.  This value permits the use of RMS error attributes,
      also measured in milliseconds.

   cn0:  The signal-to-noise ratio for the satellite signal, measured in
      decibel-Hertz (dB-Hz).  The expected range is between 20 and
      50 dB-Hz.

   mp:  An estimation of the amount of error that multipath signals
      contribute in meters.  This parameter MAY be omitted.

   cq:  An indication of the carrier quality.  Two attributes are
      included: "continuous" (which can be either "true" or "false") and
      "direct" (which can be either "direct" or "inverted").  This
      parameter MAY be omitted.

   adr:  The accumulated Doppler range, measured in meters.  This
      parameter MAY be omitted and is not useful unless multiple sets of
      GNSS measurements are provided or differential positioning is
      being performed.

   All values are converted from measures native to the satellite system
   to generic measures to ensure consistency of interpretation.  Unless
   necessary, the schema does not constrain these values.

5.5.4. GNSS Measurement Requests

Measurement requests can include a "gnss" element, which includes the "system" and "signal" attributes. Multiple elements can be included to indicate requests for GNSS measurements from multiple systems or signals.

5.6. DSL Measurements

Digital Subscriber Line (DSL) networks rely on a range of network technologies. DSL deployments regularly require cooperation between multiple organizations. These fall into two broad categories: infrastructure providers and Internet service providers (ISPs). For the same end user, an infrastructure and Internet service can be provided by different entities. Infrastructure providers manage the bulk of the physical infrastructure, including cabling. End users
Top   ToC   RFC7105 - Page 26
   obtain their service from an ISP, which manages all aspects visible
   to the end user, including IP address allocation and operation of a
   LIS.  See [DSL.TR025] and [DSL.TR101] for further information on DSL
   network deployments and the parameters that are available.

   Exchange of measurement information between these organizations is
   necessary for location information to be correctly generated.  The
   ISP LIS needs to acquire location information from the infrastructure
   provider.  However, since the infrastructure provider could have no
   knowledge of Device identifiers, it can only identify a stream of
   data that is sent to the ISP.  This is resolved by passing
   measurement data relating to the Device to a LIS operated by the
   infrastructure provider.

5.6.1. L2TP Measurements

The Layer 2 Tunneling Protocol (L2TP) [RFC2661] is a common means of linking the infrastructure provider and the ISP. The infrastructure provider LIS requires measurement data that identifies a single L2TP tunnel, from which it can generate location information. Figure 13 shows an example L2TP measurement. <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" time="2008-04-29T14:33:58"> <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl"> <l2tp> <src></src> <dest></dest> <session>528</session> </l2tp> </dsl> </measurements> Figure 13: Example DSL L2TP Measurement

5.6.2. RADIUS Measurements

When authenticating network access, the infrastructure provider might employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or Access Node (AN). These messages provide the ISP RADIUS server with an identifier for the DSLAM or AN, plus the slot and port to which the Device is attached. These data can be provided as a measurement that allows the infrastructure provider LIS to generate location information.
Top   ToC   RFC7105 - Page 27
   The format of the AN, slot, and port identifiers is not defined in
   the RADIUS protocol.  The slot and port together identify a circuit
   on the AN, analogous to the circuit identifier in [RFC3046].  These
   items are provided directly, as they would be in the RADIUS message.
   An example is shown in Figure 14.

     <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
       <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">

                 Figure 14: Example DSL RADIUS Measurement

5.6.3. Ethernet VLAN Tag Measurements

For Ethernet-based DSL access networks, the DSLAM or AN provides two VLAN tags on packets. A C-TAG is used to identify the incoming residential circuit, while the S-TAG is used to identify the DSLAM or AN. The C-TAG and S-TAG together can be used to identify a single point of network attachment. An example is shown in Figure 15. <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" time="2008-04-29T14:33:58"> <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl"> <stag>613</stag> <ctag>1097</ctag> </dsl> </measurements> Figure 15: Example DSL VLAN Tag Measurement Alternatively, the C-TAG can be replaced by data on the slot and port to which the Device is attached. This information might be included in RADIUS requests that are proxied from the infrastructure provider to the ISP RADIUS server.
Top   ToC   RFC7105 - Page 28

5.6.4. ATM Virtual Circuit Measurements

An ATM virtual circuit can be employed between the ISP and infrastructure provider. Providing the virtual port ID (VPI) and virtual circuit ID (VCI) for the virtual circuit gives the infrastructure provider LIS the ability to identify a single data stream. A sample measurement is shown in Figure 16. <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" time="2008-04-29T14:33:58"> <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl"> <vpi>55</vpi> <vci>6323</vci> </dsl> </measurements> Figure 16: Example DSL ATM Measurement

6. Privacy Considerations

Location-related measurement data can be as privacy sensitive as location information [RFC6280]. Measurement data is effectively equivalent to location information if the contextual knowledge necessary to generate one from the other is readily accessible. Even where contextual knowledge is difficult to acquire, there can be no assurance that an authorized recipient of the contextual knowledge is also authorized to receive location information. In order to protect the privacy of the subject of location-related measurement data, measurement data MUST be protected with the same degree of protection as location information. The confidentiality and authentication provided by Transport Layer Security (TLS) MUST be used in order to convey measurement data over HELD [RFC5985]. Other protocols MUST provide comparable guarantees.

6.1. Measurement Data Privacy Model

It is not necessary to distribute measurement data in the same fashion as location information. Measurement data is less useful to location recipients than location information. A simple distribution model is described in this document.
Top   ToC   RFC7105 - Page 29
   In this simple model, the Device is the only entity that is able to
   distribute measurement data.  To use an analogy from the GEOPRIV
   architecture, the Device -- as the Location Generator or the
   Measurement Data Generator -- is the sole entity that can act in the
   role of both Rule Maker and Location Server.

   A Device that provides location-related measurement data MUST only do
   so as explicitly authorized by a Rule Maker.  This depends on having
   an interface that allows Rule Makers (for instance, users or
   administrators) to control where and how measurement data is

   No entity is permitted to redistribute measurement data.  The Device
   directs other entities regarding how measurement data is used and

   The GEOPRIV model [RFC6280] protects the location of a Target using
   direction provided by a Rule Maker.  For the purposes of measurement
   data distribution, this model relies on the assumptions made in
   Section 3 of HELD [RFC5985].  These assumptions effectively declare
   the Device to be a proxy for both Target and Rule Maker.

6.2. LIS Privacy Requirements

A LIS MUST NOT reveal location-related measurement data to any other entity. A LIS MUST NOT reveal location information based on measurement data to any other entity unless directed to do so by the Device. By adding measurement data to a request for location information, the Device implicitly grants permission for the LIS to generate the requested location information using the measurement data. Permission to use this data for any other purpose is not implied. As long as measurement data is only used in serving the request that contains it, rules regarding data retention are not necessary. A LIS MUST discard location-related measurement data after servicing a request, unless the Device grants permission to use that information for other purposes.

6.3. Measurement Data and Location URIs

A LIS MAY use measurement data provided by the Device to serve requests to location URIs, if the Device permits it. A Device permits this by including measurement data in a request that explicitly requests a location URI. By requesting a location URI,
Top   ToC   RFC7105 - Page 30
   the Device grants permission for the LIS to use the measurement data
   in serving requests to that location URI.  The LIS cannot provide
   location recipients with measurement data, as defined in Section 6.1.

      Note: In HELD, the "any" type is not an explicit request for a
      location URI, though a location URI might be provided.

   The usefulness of measurement data that is provided in this fashion
   is limited.  The measurement data is only valid at the time that it
   was acquired by the Device.  At the time that a request is made to a
   location URI, the Device might have moved, rendering the measurement
   data incorrect.

   A Device is able to explicitly limit the time that a LIS retains
   measurement data by adding an expiry time to the measurement data.  A
   LIS MUST NOT retain location-related measurement data in memory,
   storage, or logs beyond the time indicated in the "expires" attribute
   (Section 4.1.2).  A LIS MUST NOT retain measurement data if the
   "expires" attribute is absent.

6.4. Measurement Data Provided by a Third Party

An authorized third-party request for the location of a Device (see [RFC6155]) can include location-related measurement data. This is possible where the third party is able to make observations about the Device. A third party that provides measurement data MUST be authorized to provide the specific measurement for the identified Device. Either a third party MUST be trusted by the LIS for the purposes of providing measurement data of the provided type, or the measurement data MUST be validated (see Section 7.2.1) before being used. How a third party authenticates its identity or gains authorization to use measurement data is not covered by this document.

(page 30 continued on part 3)

Next Section