tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7105

 
 
 

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

Part 2 of 4, p. 13 to 30
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 13 
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      Up      ToC       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
   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

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

Top      Up      ToC       Page 16 
             <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].

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

Top      Up      ToC       Page 20 
     <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

Top      Up      ToC       Page 21 
     <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

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

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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>192.0.2.10</src>
           <dest>192.0.2.61</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      Up      ToC       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"
           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 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      Up      ToC       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      Up      ToC       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
   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,

Top      Up      ToC       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 RFC Part