RFC 7105
Using Device-Provided Location-Related Measurements in Location Configuration Protocols
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.
An example of an LLDP measurement is shown in Figure 4. This shows an adjacent node (chassis) that is identified by the IP address 192.0.2.45 (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" time="2008-04-29T14:33:58"> <lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp"> <chassis type="4">c000022d</chassis> <port type="6">a2</port> </lldp> </measurements> 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>192.0.2.158</giaddr> <circuit>108b</circuit> </dhcp-rai> </measurements> Figure 5: DHCP Relay Agent Information Measurement Example
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 format. 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="http://opengis.net/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>
<rsni rmsError="6" samples="1">7.5</rsni> </deviceSignal> </ap> </wifi> </measurements> 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 fields: bssid: The Basic Service Set (BSS) identifier. In an Infrastructure BSS network, the bssid is the 48-bit MAC address of the access point. The "verified" attribute of this element describes whether the Device has verified the MAC address or it authenticated the access point or the network operating the access point (for example, a captive portal accessed through the access point has been authenticated). This 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 operates. 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].
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
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.
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 determination. 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 integers. <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" time="2008-04-29T14:33:58"> <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell"> <servingCell> <mcc>465</mcc><mnc>20</mnc><eucid>80936424</eucid> </servingCell> <observedCell> <mcc>465</mcc><mnc>06</mnc><eucid>10736789</eucid> </observedCell> </cellular> </measurements> Long term evolution (LTE) cells are identified by a 28-bit cell identifier (eucid). Figure 7: Example LTE Cellular Measurement
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" time="2008-04-29T14:33:58"> <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell"> <servingCell> <mcc>465</mcc><mnc>20</mnc> <rnc>2000</rnc><cid>65000</cid> </servingCell> <observedCell> <mcc>465</mcc><mnc>06</mnc> <lac>16383</lac><cid>32767</cid> </observedCell> </cellular> </measurements> 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 (cid). Figure 8: Example UMTS Cellular Measurement <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" time="2008-04-29T14:33:58"> <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell"> <servingCell> <mcc>465</mcc><mnc>06</mnc> <lac>16383</lac><cid>32767</cid> </servingCell> </cellular> </measurements> 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
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" time="2008-04-29T14:33:58"> <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell"> <servingCell> <sid>15892</sid><nid>4723</nid><baseid>12</baseid> </servingCell> <observedCell> <sid>15892</sid><nid>4723</nid><baseid>13</baseid> </observedCell> </cellular> </measurements> 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" time="2008-04-29T14:33:58"> <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell"> <observedCell> <mcc>465</mcc><mnc>20</mnc> <rnc>2000</rnc><cid>65000</cid> </observedCell> <observedCell> <mcc>465</mcc><mnc>06</mnc> <lac>16383</lac><cid>32767</cid> </observedCell> </cellular> </measurements> Figure 11: Example Observed Cellular Measurement
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.
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">
<doppler>499.9395</doppler>
<codephase rmsError="1.6e-9">0.87595747</codephase>
<cn0>45</cn0>
</sat>
<sat num="27">
<doppler>378.2657</doppler>
<codephase rmsError="1.6e-9">0.56639479</codephase>
<cn0>52</cn0>
</sat>
<sat num="20">
<doppler>-633.0309</doppler>
<codephase rmsError="1.6e-9">0.57016835</codephase>
<cn0>48</cn0>
</sat>
</gnss>
</measurements>
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.
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
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
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>192.0.2.10</src> <dest>192.0.2.61</dest> <session>528</session> </l2tp> </dsl> </measurements> Figure 13: Example DSL L2TP Measurement5.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.
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" time="2008-04-29T14:33:58"> <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl"> <an>AN-7692</an> <slot>3</slot> <port>06</port> </dsl> </measurements> Figure 14: Example DSL RADIUS Measurement5.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.
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 Measurement6. 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.
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 provided. No entity is permitted to redistribute measurement data. The Device directs other entities regarding how measurement data is used and retained. 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,
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)
