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).
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.
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
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
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.
<flightTime rmsError="4e-9" samples="1">2.56e-9</flightTime>
<rcpi dBm="true" rmsError="12" samples="1">-59</rcpi>
<rsni rmsError="15" samples="1">23</rsni>
<rcpi dBm="true" rmsError="9.5" samples="1">-98.5</rcpi>
<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"
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
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].
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",
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,
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
type: The "type" element identifies the desired type (or types that
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
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
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
Long term evolution (LTE) cells are identified by a 28-bit cell
Figure 7: Example LTE Cellular Measurement
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"
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
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.
Figure 11: Example Observed Cellular Measurement
5.4.1. Cellular Measurement Requests
Two elements can be used in measurement requests for cellular
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
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
Determining location and time in autonomous GNSS receivers follows
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.
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
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.
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
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
The GNSS receiver measures the following parameters for each
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
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
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
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
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.
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
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.
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.
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.
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
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
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
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
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
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.