Using Device-provided Location Measurements in HELD

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

Abstract

A method is described by which a Device is able to provide measurement data to a LIS within a HELD request. Measurement information are observations about the position of a Device, which could be data about network attachment or about the physical environment around the LIS. When a LIS generates location information for a device, information from the device can improve the accuracy of the location estimate. A basic set of measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters.

1. Introduction
2. Conventions used in this document
3. Location Measurements in HELD Requests
4. Measurement Types
    4.1. LLDP Measurements
    4.2. DHCP Measurements
    4.3. 802.11 SSID Measurement
    4.4. GNSS Measurements
        4.4.1. GNSS System and Signal
        4.4.2. Time
        4.4.3. Per-Satellite Measurements
    4.5. DSL Measurements
        4.5.1. L2TP Measurements
        4.5.2. RADIUS Measurements
        4.5.3. Ethernet VLAN Tag Measurements
        4.5.4. ATM Virtual Circuit Measurements
5. Measurement Schema
6. Security Considerations
    6.1. Expiry Time on Measurements
7. IANA Considerations
    7.1. IANA Registry for GNSS Types
    7.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:lm
    7.3. XML Schema Registration for Measurement Schema
    7.4. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:ip
    7.5. XML Schema Registration for IP Address Type Schema
8. References
    8.1. Normative References
    8.2. Informative References
§ Authors' Addresses
§ Intellectual Property and Copyright Statements

1. Introduction

HELD (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.) [I‑D.ietf‑geopriv‑http‑location‑delivery] describes a means for a device to request location information from an access network. The LIS is expected to be able to retrieve the information necessary to generate location information. As a part of the access network, the LIS is able to acquire measurements from network devices within the network to determine location information. The LIS also has access to information about the network topology that can be used to turn measurement data into location information. However, this information can be enhanced with information acquired from the Device itself.

This document describes a means for the Device to report location measurements to the LIS. These measurements can be used by the LIS to improve the quality of the location estimate it produces.

2. Conventions used in this document

3. Location Measurements in HELD Requests

This document defines a standard container for the conveyance of measurement parameters in HELD requests. This is an XML container that identifies measurements by type and allows the Device to provide any measurements it has.

Multiple measurements, either of the same type or from different sources can be included in the measurements element. The measurements element SHOULD NOT be repeated.

The LIS SHOULD validate any location information derived based on Device-provided measurements. Any measurements that produce location information that is significantly different to location information that the LIS is able to generate independently SHOULD be discarded. The allowable degree of difference is left to local configuration or implementation.

Using measurements is at the discretion of the LIS, but the method parameter in the PIDF-LO SHOULD be adjusted reflect the method used.

4. Measurement Types

4.1. LLDP Measurements

LLDP messages are sent between adjacent nodes in an 802.x network (e.g. wired Ethernet, WiFi, WiMAX). These messages all contain identification information for the sending node, which can be used to determine location information. A Device that receives LLDP messages can report this information as a measurement to the LIS, which is then able to use the measurement in determining the location of the Device.

The Device MUST report the values directly as they were provided by the adjacent node. Attempting to adjust the type of identifier is likely to cause the measurement 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.

802.x 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.

4.2. DHCP Measurements

4.3. 802.11 SSID Measurement

In WiFi, or 802.11, networks a Device might be able to provide the service set identifier (SSID) of the wireless network that it is attached to. This is provided using the ssid element, as shown in Figure 4 (802.11 SSID Measurement Example).

4.4. GNSS Measurements

GNSS use orbiting satellites to transmit signals. A Device with a GNSS receiver is able to take measurements from the satellite signals. These measurements can be used to determine time and the location of the Device.

A Device that uses a GNSS receiver is able to report measurements after the first stage of this process. A LIS can use these measurements to determine a location. In the case where there are fewer measurements available than the optimal minimum, the LIS might be able to use other sources of measurement information and combine the measurements to determine a position.

Figure 5 (Example GNSS Measurement) shows an example GNSS measurement. The measurement shown is for the GPS system and includes measurements for three satellites only.

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.

4.4.1. GNSS System 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 and Galileo. Details for the registry are included in Section 7.1 (IANA Registry for GNSS Types).

4.4.2. Time

Each set of GNSS measurements is taken at a specific point in time. The time element includes a relative time in milliseconds using the time system native to the satellite system.

For the GPS satellite system, the time element includes the time of week in milliseconds. For the Galileo system, the time element includes the time of day in milliseconds.

Alternatively, a specific instant of time can be specified using the abstime element. This element includes an ISO 8601 formatted date and time, which SHOULD be measured to within one millisecond.

The time element includes an attribute, coarse, that indicates whether or not the time was accurately recovered by the receiver. This parameter SHOULD be set to false if the receiver does not determine the time accurate to within a millisecond. If the coarse attribute is set to false, the actual time is derived from the other measurement data; typically this means that additional per-satellite measurements are required.

4.4.3. Per-Satellite Measurements

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.

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.

4.5. DSL Measurements

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, the infrastructure provider has 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 information relating to the Device to a LIS operated by the infrastructure provider.

4.5.1. L2TP Measurements

Layer 2 Tunneling Protocol (L2TP) is a common means of linking the infrastructure provider and the ISP. The infrastructure provider LIS requires a measurement that identifies a single L2TP tunnel, from which it can generate location information. Figure 6 (Example DSL L2TP Measurement) shows an example L2TP measurement.

4.5.2. RADIUS Measurements

When authenticating network access, the infrastructure provider might employ RADIUS (Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” June 2000.) [RFC2865] proxying 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 that the Device is attached on. These data can be provided as a measurement, which allows the infrastructure provider LIS to generate location information.

4.5.3. Ethernet VLAN Tag Measurements

For Ethernet-based DSL access networks, the DSL Access Module (DSLAM) or Access Node (AN) provide 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 8 (Example DSL VLAN Tag Measurement).

Alternatively, the C-TAG can be replaced by data on the slot and port that the Device is attached to. This information might be included in RADIUS requests that are proxied from the infrastructure provider to the ISP RADIUS server.

4.5.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 9 (Example DSL ATM Measurement).

5. Measurement Schema

Note that the pattern rules in the following schema wrap due to length constraints in RFC. None of the patterns contain whitespace.

<?xml version="1.0"?>
<xs:schema
    xmlns:lm="urn:ietf:params:xml:ns:geopriv:held:lm"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="urn:ietf:params:xml:ns:geopriv:held:lm"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">

  <xs:annotation>
    <xs:appinfo
        source="urn:ietf:params:xml:schema:geopriv:held:lm">
      HELD Capabilities
    </xs:appinfo>
    <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
      <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
           published RFC and remove this note.]] -->
      This schema defines a framework for location measurements
      in HELD and several measurement formats.
    </xs:documentation>
  </xs:annotation>

  <xs:element name="measurements">
    <xs:complexType>
      <xs:complexContent>
        <xs:restriction base="xs:anyType">
          <xs:sequence>
            <xs:element ref="lm:lldp" minOccurs="0"/>
            <xs:element ref="lm:dhcp-rai" minOccurs="0"/>
            <xs:element ref="lm:ssid" minOccurs="0"/>
            <xs:element ref="lm:gnss" minOccurs="0"/>
            <xs:element ref="lm:dsl" minOccurs="0"/>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:anyAttribute namespace="##any" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>

  <!-- LLDP -->
  <xs:element name="lldp" type="lm:lldpMeasurementType"/>
  <xs:complexType name="lldpMeasurementType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="chassis" type="lm:lldpDataType"/>
          <xs:element name="port" type="lm:lldpDataType"/>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="lldpDataType">
    <xs:simpleContent>
      <xs:extension base="lm:lldpOctetStringType">
        <xs:attribute name="type" type="lm:byteType"
                      use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:simpleType name="lldpOctetStringType">
    <xs:restriction base="xs:hexBinary">
      <xs:minLength value="1"/>
      <xs:maxLength value="255"/>
    </xs:restriction>
  </xs:simpleType>

  <!-- DHCP Relay Agent Information Option -->
  <xs:element name="dhcp-rai" type="lm:dhcpType"/>
  <xs:complexType name="dhcpType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="giaddr" type="lm:ipAddressType"/>
          <xs:element name="circuit"
                      type="xs:hexBinary" minOccurs="0"/>
          <xs:element name="remote"
                      type="lm:dhcpRemoteType" minOccurs="0"/>
          <xs:element name="subscriber"
                      type="xs:hexBinary" minOccurs="0"/>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="dhcpRemoteType">
    <xs:simpleContent>
      <xs:extension base="xs:hexBinary">
        <xs:attribute name="enterprise" type="xs:positiveInteger"
                      use="optional"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <!-- 802.11 SSID -->
  <xs:element name="ssid" type="lm:ssidType"/>
  <xs:simpleType name="ssidType">
    <xs:restriction base="xs:token">
      <xs:maxLength value="32"/>
    </xs:restriction>
  </xs:simpleType>

  <!-- GNSS -->
  <xs:element name="gnss" type="lm:gnssMeasurementType">
    <xs:unique name="gnssSatellite">
      <xs:selector xpath="sat"/>
      <xs:field xpath="@num"/>
    </xs:unique>
  </xs:element>

  <xs:complexType name="gnssMeasurementType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:choice>
            <xs:element name="abstime" type="lm:gnssAbsoluteTime"/>
            <xs:element name="time" type="lm:gnssTime"/>
          </xs:choice>
          <xs:element name="sat" type="lm:gnssSatelliteType"
                      minOccurs="1" maxOccurs="64"/>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="system" type="xs:token" use="required"/>
        <xs:attribute name="signal" type="xs:token"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="gnssAbsoluteTime">
    <xs:simpleContent>
      <xs:extension base="xs:dateTime">
        <xs:attribute name="coarse" type="xs:boolean"
                      default="false"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name="gnssTime">
    <xs:simpleContent>
      <xs:extension base="lm:nonNegativeDecimal">
        <xs:attribute name="coarse" type="xs:boolean"
                      default="false"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name="gnssSatelliteType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="doppler" type="xs:decimal"/>
          <xs:element name="codephase" type="lm:nonNegativeDecimal"/>
          <xs:element name="cn0" type="xs:nonNegativeInteger"/>
          <xs:element name="err" type="lm:nonNegativeDecimal"/>
          <xs:element name="mp" type="xs:positiveInteger"
                      minOccurs="0"/>
          <xs:element name="cq" type="lm:codePhaseQualityType"
                      minOccurs="0"/>
          <xs:element name="adr" type="xs:decimal" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="num" type="xs:positiveInteger"
                      use="required"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="codePhaseQualityType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:attribute name="continuous" type="xs:boolean"
                      default="true"/>
        <xs:attribute name="direct" use="required">
          <xs:simpleType>
            <xs:restriction base="xs:token">
              <xs:enumeration value="direct"/>
              <xs:enumeration value="inverted"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:attribute>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <!-- DSL Measurements -->
  <xs:element name="dsl" type="lm:dslVlanType"/>
  <xs:complexType name="dslVlanType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:choice>
          <xs:element name="l2tp">
            <xs:complexType>
              <xs:complexContent>
                <xs:restriction base="xs:anyType">
                  <xs:sequence>
                    <xs:element name="src" type="lm:ipAddressType"/>
                    <xs:element name="dest" type="lm:ipAddressType"/>
                    <xs:element name="session"
                                type="xs:nonNegativeInteger"/>
                  </xs:sequence>
                </xs:restriction>
              </xs:complexContent>
            </xs:complexType>
          </xs:element>
          <xs:sequence>
            <xs:element name="an" type="xs:token"/>
            <xs:group ref="lm:dslSlotPort"/>
          </xs:sequence>
          <xs:sequence>
            <xs:element name="stag" type="lm:vlanIDType"/>
            <xs:choice>
              <xs:sequence>
                <xs:element name="ctag" type="lm:vlanIDType"/>
                <xs:group ref="lm:dslSlotPort" minOccurs="0"/>
              </xs:sequence>
              <xs:group ref="lm:dslSlotPort"/>
            </xs:choice>
          </xs:sequence>
          <xs:sequence>
            <xs:element name="vpi" type="lm:byteType"/>
            <xs:element name="vci" type="lm:twoByteType"/>
          </xs:sequence>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:choice>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  <xs:simpleType name="vlanIDType">
    <xs:restriction base="xs:nonNegativeInteger">
      <xs:maxInclusive value="4095"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:group name="dslSlotPort">
    <xs:sequence>
      <xs:element name="slot" type="xs:token"/>
      <xs:element name="port" type="xs:token"/>
    </xs:sequence>
  </xs:group>

  <!-- Common Data Types -->
  <xs:simpleType name="byteType">
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="0"/>
      <xs:maxInclusive value="255"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="twoByteType">
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="0"/>
      <xs:maxInclusive value="65535"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="nonNegativeDecimal">
    <xs:restriction base="xs:decimal">
      <xs:minInclusive value="0.0"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="ipAddressType">
    <xs:union memberTypes="lm:IPv6AddressType lm:IPv4AddressType"/>
  </xs:simpleType>

  <!-- IPv6 format definition -->
  <xs:simpleType name="IPv6AddressType">
    <xs:annotation>
      <xs:documentation>
        An IP version 6 address, based on RFC 4291.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:token">
      <!-- Fully specified address -->
      <xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/>
      <!-- Double colon start -->
      <xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/>
      <!-- Double colon middle -->
      <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6}
                         (:[0-9A-Fa-f]{1,4}){1}"/>
      <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
                         (:[0-9A-Fa-f]{1,4}){1,2}"/>
      <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
                         (:[0-9A-Fa-f]{1,4}){1,3}"/>
      <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,3}
                         (:[0-9A-Fa-f]{1,4}){1,4}"/>
      <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
                         (:[0-9A-Fa-f]{1,4}){1,5}"/>
      <xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
                         (:[0-9A-Fa-f]{1,4}){1,6}"/>
      <!-- Double colon end -->
      <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,7}:"/>
      <!-- IPv4-Compatible and IPv4-Mapped Addresses -->
      <xs:pattern value="((:(:0{1,4}){0,3}:[fF]{4})
                          |(0{1,4}:(:0{1,4}){0,2}:[fF]{4})
                          |((0{1,4}:){2}(:0{1,4})?:[fF]{4})
                          |((0{1,4}:){3}:[fF]{4})
                          |((0{1,4}:){4}[fF]{4}))
                         :(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
                         \.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
                         \.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
                         \.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])"/>
      <!-- The unspecified address -->
      <xs:pattern value="::"/>
    </xs:restriction>
  </xs:simpleType>

  <!-- IPv4 format definition -->
  <xs:simpleType name="IPv4AddressType">
    <xs:restriction base="xs:token">
      <xs:pattern value="(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
                         \.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
                         \.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
                         \.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])"/>
    </xs:restriction>
  </xs:simpleType>
</xs:schema>

6. Security Considerations

Location measurements are provided by the Device for the sole purpose of generating more accurate location information. The LIS SHOULD NOT retain location measurements for any longer than is necessary to generate location information.

A LIS MUST NOT reveal location measurements to any other entity unless given explicit permission by the Device. This document does not include any means to indicate such permission.

6.1. Expiry Time on Measurements

A Device is able to indicate a time in the location measurement using the expires attribute. Nominally, this attribute indicates how long information is expected to be valid for, but a Device MAY use this attribute to prevent the LIS from retaining measurement data.

The LIS MUST NOT keep location measurements beyond the time indicated in the expires attribute. Where the expires attribute is not provided, the LIS MUST discard location measurements immediately after servicing the current request.

7. IANA Considerations

7.1. IANA Registry for GNSS Types

This document establishes a new IANA registry for Global Navigation Satellite System (GNSS) types. The registry includes tokens for the GNSS type and for each of the signals within that type. Referring to [RFC2434] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.), this registry operates under both "Expert Review" and "Specification Required" rules. The IESG will appoint an Expert Reviewer who will advise IANA promptly on each request for a new or updated GNSS type.

7.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:lm

7.3. XML Schema Registration for Measurement Schema

7.4. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:ip

7.5. XML Schema Registration for IP Address Type Schema

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses

Full Copyright Statement

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2434]	Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 2434, October 1998 (TXT, HTML, XML).
[I-D.ietf-geopriv-http-location-delivery]	Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” draft-ietf-geopriv-http-location-delivery-16 (work in progress), August 2009 (TXT).

[RFC3693]	Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” RFC 3693, February 2004 (TXT).
[RFC3046]	Patrick, M., “DHCP Relay Agent Information Option,” RFC 3046, January 2001 (TXT).
[RFC4649]	Volz, B., “Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option,” RFC 4649, August 2006 (TXT).
[IANA.enterprise]	IANA, “Private Enterprise Numbers.”
[RFC3993]	Johnson, R., Palaniappan, T., and M. Stapp, “Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option,” RFC 3993, March 2005 (TXT).
[RFC4580]	Volz, B., “Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option,” RFC 4580, June 2006 (TXT).
[RFC3688]	Mealling, M., “The IETF XML Registry,” BCP 81, RFC 3688, January 2004 (TXT).
[IEEE.8021AB]	IEEE, “IEEE Standard for Local and Metropolitan area networks, Station and Media Access Control Connectivity Discovery,” 802.1AB, June 2005.
[GPS.ICD]	“Navstar GPS Space Segment/Navigation User Interface,” ICD GPS-200, Apr 2000.
[Galileo.ICD]	GJU, “Galileo Open Service Signal In Space Interface Control Document (SIS ICD),” May 2006.
[I-D.winterbottom-geopriv-lis2lis-req]	Winterbottom, J. and S. Norreys, “LIS to LIS Protocol Requirements,” draft-winterbottom-geopriv-lis2lis-req-01 (work in progress), November 2007 (TXT).
[DSL.TR025]	Wang, R., “Core Network Architecture Recommendations for Access to Legacy Data Networks over ADSL,” September 1999.
[DSL.TR101]	Cohen, A. and E. Shrum, “Migration to Ethernet-Based DSl Aggregation,” April 2006.
[RFC2865]	Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” RFC 2865, June 2000 (TXT).

	Martin Thomson
	Andrew
	PO Box U40
	Wollongong University Campus, NSW 2500
	AU
Phone:	+61 2 4221 2915
Email:	martin.thomson@andrew.com
URI:	http://www.andrew.com/

	James Winterbottom
	Andrew
	PO Box U40
	Wollongong University Campus, NSW 2500
	AU
Phone:	+61 2 4221 2938
Email:	james.winterbottom@andrew.com
URI:	http://www.andrew.com/

Using Device-provided Location Measurements in HELD
draft-thomson-geopriv-held-measurements-01.txt

Status of this Memo

Abstract

Table of Contents

1. Introduction

2. Conventions used in this document

3. Location Measurements in HELD Requests

4. Measurement Types

4.1. LLDP Measurements

4.2. DHCP Measurements

4.3. 802.11 SSID Measurement

4.4. GNSS Measurements

4.4.1. GNSS System and Signal

4.4.2. Time

4.4.3. Per-Satellite Measurements

4.5. DSL Measurements

4.5.1. L2TP Measurements

4.5.2. RADIUS Measurements

4.5.3. Ethernet VLAN Tag Measurements

4.5.4. ATM Virtual Circuit Measurements

5. Measurement Schema

6. Security Considerations

6.1. Expiry Time on Measurements

7. IANA Considerations

7.1. IANA Registry for GNSS Types

7.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:lm

7.3. XML Schema Registration for Measurement Schema

7.4. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:ip

7.5. XML Schema Registration for IP Address Type Schema

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses

Full Copyright Statement

Intellectual Property

Using Device-provided Location Measurements in HELDdraft-thomson-geopriv-held-measurements-01.txt

Status of this Memo

Abstract

Table of Contents

1. Introduction

2. Conventions used in this document

3. Location Measurements in HELD Requests

4. Measurement Types

4.1. LLDP Measurements

4.2. DHCP Measurements

4.3. 802.11 SSID Measurement

4.4. GNSS Measurements

4.4.1. GNSS System and Signal

4.4.2. Time

4.4.3. Per-Satellite Measurements

4.5. DSL Measurements

4.5.1. L2TP Measurements

4.5.2. RADIUS Measurements

4.5.3. Ethernet VLAN Tag Measurements

4.5.4. ATM Virtual Circuit Measurements

5. Measurement Schema

6. Security Considerations

6.1. Expiry Time on Measurements

7. IANA Considerations

7.1. IANA Registry for GNSS Types

7.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:lm

7.3. XML Schema Registration for Measurement Schema

7.4. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:ip

7.5. XML Schema Registration for IP Address Type Schema

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses

Full Copyright Statement

Intellectual Property

Using Device-provided Location Measurements in HELD
draft-thomson-geopriv-held-measurements-01.txt