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

Status of this Memo

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 10, 2008.

Abstract

A method is described by which a Device is able to provide location-related measurement data to a LIS within a HELD request. Location-related measurement information are observations concerning properties related to 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 location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters.

Table of Contents

1.  Introduction
2.  Conventions used in this document
3.  Location-Related Measurements in HELD Requests
4.  Location-Related Measurement Data Types
    4.1.  Common Location-Related Measurement Fields
        4.1.1.  Time of Measurement
        4.1.2.  Expiry Time on Location-Related Measurement Data
        4.1.3.  RMS Error and Number of Samples
    4.2.  LLDP Measurements
    4.3.  DHCP Relay Agent Information Measurements
    4.4.  802.11 WLAN Measurements
    4.5.  Cellular Measurements
    4.6.  GNSS Measurements
        4.6.1.  GNSS System and Signal
        4.6.2.  Time
        4.6.3.  Per-Satellite Measurement Data
    4.7.  DSL Measurements
        4.7.1.  L2TP Measurements
        4.7.2.  RADIUS Measurements
        4.7.3.  Ethernet VLAN Tag Measurements
        4.7.4.  ATM Virtual Circuit Measurements
5.  Measurement Schemas
    5.1.  Measurement Container Schema
    5.2.  Base Type Schema
    5.3.  LLDP Measurement Schema
    5.4.  DHCP Measurement Schema
    5.5.  WiFi Measurement Schema
    5.6.  Cellular Measurement Schema
    5.7.  GNSS Measurement Schema
    5.8.  DSL Measurement Schema
6.  Security Considerations
7.  IANA Considerations
    7.1.  IANA Registry for GNSS Types
    7.2.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm
    7.3.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:basetypes
    7.4.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:lldp
    7.5.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:dhcp
    7.6.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:wifi
    7.7.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:cell
    7.8.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:gnss
    7.9.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:dsl
    7.10.  XML Schema Registration for Measurement Container Schema
    7.11.  XML Schema Registration for Base Types Schema
    7.12.  XML Schema Registration for LLDP Schema
    7.13.  XML Schema Registration for DHCP Schema
    7.14.  XML Schema Registration for WiFi Schema
    7.15.  XML Schema Registration for Cellular Schema
    7.16.  XML Schema Registration for GNSS Schema
    7.17.  XML Schema Registration for DSL Schema
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.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 measurement results from network devices within the network that are related to Device location. 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-related measurement data to the LIS. This measurement data can be used by the LIS to improve the quality of the location estimate it produces.

2.  Conventions used in this document

The terms LIS and Device are used in this document in a manner consistent with the usage in [I‑D.ietf‑geopriv‑http‑location‑delivery] (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.).

This document also uses the following definitions:

Location Measurement:

An observation about the physical properties of a particular device's network access. The result of a location measurement -- "location-related measurement data", or simply "measurement data" given sufficient context -- can be used to determine the location of a device; however, location-related measurement data does not identify a Device. Measurement data can change with time if the location of the Device also changes.
A location-related measurement data does not necessarily contain location information directly, but it can be used in combination with contextual knowledge of the network, or algorithms to derive location information. Examples of location-related measurement data are: radio signal strength or timing measurements, Ethernet switch and port identifiers.

Location-related measurement data can be considered sighting information, based on the definition in [RFC3693] (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.).

Location Estimate:

The result of location determination, a location estimate is an approximation of where the Device is located. Location estimates are subject to uncertainty, which arise from errors in measurement results.

GNSS:

Global Navigation Satellite System. A satellite-based system that provides positioning and time information. For example, the US Global Positioning System (GPS) or the European Galileo system.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Location-Related Measurements in HELD Requests

This document defines a standard container for the conveyance of location-related measurement parameters in HELD requests. This is an XML container that identifies parameters by type and allows the Device to provide the results of any measurement it is able to perform. A set of measurement schemas are also defined that can be carried in the generic container.

The simplest example of measurement data conveyance is illustrated by the example message in Figure 1 (HELD Location Request with Measurement Data). This shows a HELD location request message with an Ethernet switch and port measurement taken using LLDP (IEEE, “IEEE Standard for Local and Metropolitan area networks, Station and Media Access Control Connectivity Discovery,” June 2005.) [IEEE.8021AB].

  <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
    <locationType exact="true">civic</locationType>
    <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">0a01003c</chassis>
        <port type="6">c2</port>
      </lldp>
    </measurements>
  </locationRequest>

Measurement data that the LIS does not support or understand can be ignored.

Multiple sets of measurement data, either of the same type or from different sources can be included in the measurements element. See Section 4.1.1 (Time of Measurement) for details on repetition of this element.

The LIS SHOULD validate any location information that is derived from measurement data provided by Devices. Location information generated from measurement data SHOULD be compared against location information that the LIS is able to generate independently. If the two results differ significantly, the LIS SHOULD discard the result that is derived from measurement data; the allowable degree of difference is left to local configuration or implementation.

Using location-related measurement data is at the discretion of the LIS, but the method parameter in the PIDF-LO SHOULD be adjusted to reflect the method used.

4.  Location-Related Measurement Data Types

This document defines location-related measurement data types for a range of common network types.

Note:

Not all of these measurement data types are provided by a Device; they may be acquired by other hosts in situations such as those described in [I‑D.winterbottom‑geopriv‑lis2lis‑req] (Winterbottom, J. and S. Norreys, “LIS to LIS Protocol Requirements,” November 2007.).

4.1.  Common Location-Related Measurement Fields

This section describes metadata that is common to a wide range of measurement data. Time of measurement and expiry time apply to all measurements; RMS error and number of samples apply to selected measurement types.

4.1.1.  Time of Measurement

The time attribute records the time that the measurement or observation was made. This time can be different to the time that the measurement information was reported. Time information can be used to populate a timestamp on the location result, or to determine if the measurement information is used.

The time attribute is optional to avoid forcing an arbitrary choice of timestamp for relatively static types of measurement (for instance, the DSL measurements in Section 4.7 (DSL Measurements)) and for legacy devices that don't record time information (such as the Home Location Register/Home Subscriber Server for cellular). However, it is RECOMMENDED that it be provided whenever possible.

The time attribute is attached to the root measurement element. If it is necessary to provide multiple sets of measurement data with different times, multiple measurement elements SHOULD be provided.

4.1.2.  Expiry Time on Location-Related Measurement Data

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. A Device MAY use this attribute to prevent the LIS from retaining measurement data or limit the time that a LIS retains this information.

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

Figure 2 (Expiry Time Example) shows an example of a measurement that includes an expiry attribute.

  <lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
                   time="2008-04-29T14:33:58"
                   expires="2008-04-29T17:33:58">
    <wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
      <servingWap>
        <ssid>wlan-home</ssid>
        <bssid>00-12-F0-A0-80-EF</bssid>
      </servingWap>
    </wifi>
  </lm:measurements>

4.1.3.  RMS Error and Number of Samples

Often a measurement is taken more than once over a period of time. Reporting the average of a number of measurement results mitigates the effects of random errors that occur in the measurement process. Typically, a mean value is reported, but additional information about the measurement process can be useful in determining location uncertainty. Two optional attributes are provided for certain measurement values:

rmsError:

The root-mean-squared (RMS) error of the set of measurement values used in calculating the result. RMS error is expressed in the same units as the measurement, unless otherwise stated.

samples:

The number of samples that were taken in determining the measurement value. If omitted, this value can be assumed to be a very large value, such that the RMS error is an indication of the standard deviation of the sample set.

4.2.  LLDP Measurements

LLDP 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, which 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.

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 3 (LLDP Measurement Example). 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 (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) [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>

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.

4.3.  DHCP Relay Agent Information Measurements

The DHCP Relay Agent Information option (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) [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 are all optional: circuit identifier (circuit, [RFC3046] (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.)), remote identifier (remote, [RFC3046] (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.), [RFC4649] (Volz, B., “Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option,” August 2006.)) and subscriber identifier (subscriber, [RFC3993] (Johnson, R., Palaniappan, T., and M. Stapp, “Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option,” March 2005.), [RFC4580] (Volz, B., “Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option,” June 2006.)). The DHCPv6 remote identifier has an associated enterprise number (IANA, “Private Enterprise Numbers,” .) [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>::ffff:192.0.2.158</giaddr>
      <circuit>108b</circuit>
    </dhcp-rai>
  </measurements>

4.4.  802.11 WLAN Measurements

In WiFi, or 802.11, networks a Device might be able to provide information about the wireless access point (WAP) that it is attached to, or other WiFi points it is able to see. This is provided using the wifi element, as shown in Figure 5 (802.11 WLAN Measurement Example).

A wifi element is made up of a serving WAP, zero or more neighbouring WAPs, and an optional nicType element. Each WAP element is comprised of the following fields:

ssid:

The service set identifier for the wireless network. This parameter must be provided.

bssid:

The basic service set identifier. This is the 48 bit Ethernet MAC address of the wireless access point and it must be provided.

wapname:

The broadcast name for the wireless access point. This element is optional.

rssi:

The received signal strength indicator of the WAP as seen by the wireless receiver. This value SHOULD be in units of dBm (with RMS error in dB). If the units are unknown, the dBm attribute MUST be set to false. Signal strength reporting on current hardware uses a range of different units; 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 is optional and includes optional rmsError and samples attributes.

The nicType element is used to specify the make and model of the wireless network interface card in the device. Different 802.11 chipsets report the signal strength in different ways, so the nic type must be specified in order for the LIS to use signal strength indicators as part of its location determination process.

  <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                time="2008-04-29T14:33:58">
    <wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
      <nicType>Intel(r)PRO/Wireless 2200BG</nicType>
      <servingWap>
        <ssid>wlan-home</ssid>
        <bssid>00-12-F0-A0-80-EF</bssid>
        <rssi dBm="false">95</rssi>
      </servingWap>
      <neighbourWap>
        <ssid>wlan-home</ssid>
        <bssid>00-12-F0-A0-80-F0</bssid>
        <rssi dBm="false">15</rssi>
      </neighbourWap>
      <neighbourWap>
        <ssid>wlan-home</ssid>
        <bssid>00-12-F0-A0-80-F1</bssid>
        <rssi dBm="false">12</rssi>
      </neighbourWap>
      <neighbourWap>
        <ssid>wlan-home</ssid>
        <bssid>00-12-F0-A0-80-F2</bssid>
        <rssi dBm="false">5</rssi>
      </neighbourWap>
    </wifi>
  </measurements>

4.5.  Cellular Measurements

GSM and UMTS cellular devices are common throughout the world and base station identifiers can provide a good source of coarse location information. This information can be provided to a LIS run by the cellar operator, or may be provided to an alternative LIS operator that has access to one of several global cell-id to location mapping databases. The cellular measurement set allows a device to report to a LIS any UMTS or GSM cells that it is able to hear, cells are reported using their global identifiers.

  <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>123</mcc><mnc>06</mnc>
        <lac>16383</lac><cid>32767</cid>
      </servingCell>
    </cellular>
  </measurements>

  <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>456</mcc><mnc>20</mnc>
        <rnc>2000</rnc><cid>65000</cid>
      </servingCell>
      <observedCell>
        <mcc>123</mcc><mnc>06</mnc>
        <lac>16383</lac><cid>32767</cid>
      </observedCell>
    </cellular>
  </measurements>

In general a cellular device will be attached to the cellular network and so the notion of a serving cell exists. Cellular network also provide overlap between neighbouring 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 may 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 may simply report cells it can hear without flagging one as a serving cell. An example of this is shown in Figure 8 (Example Observed 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">
      <observedCell>
        <mcc>456</mcc><mnc>20</mnc>
        <rnc>2000</rnc><cid>65000</cid>
      </observedCell>
      <observedCell>
        <mcc>123</mcc><mnc>06</mnc>
        <lac>16383</lac><cid>32767</cid>
      </observedCell>
    </cellular>
  </measurements>

4.6.  GNSS Measurements

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

Determining location and time in autonomous GNSS receivers follows three steps:

Signal acquisition:

During the signal acquisition stage, the receiver searches for the repeating code that is sent by each GNSS satellite. Successful operation typically requires measurement data for a minimum of 5 satellites. At this stage, measurement data is available to the device.

Navigation message decode:

Once the signal has been acquired, the receiver then receives information about the configuration of the satellite constellation. This information is broadcast by each satellite and is modulated with the base signal at a low rate; for instance, GPS sends this information at about 50 bits per second.

Calculation:

The measurement data is combined with the data on the satellite constellation to determine the location of the receiver and the current time.

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

Note: The use of different sets of GNSS assistance data can reduce the amount of time required for the signal acquisition stage and obviate the need for the receiver to extract data on the satellite constellation. Provision of assistance data is outside the scope of this document.

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

  <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
                time="2008-04-29T14:33:58">
    <gnss xmlns="urn:ietf:params:xml:ns:geopriv:lm:gnss"
          system="gps" signal="L1" coarsetime="false">
      <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>

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.6.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.6.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 gnss element includes an attribute, coarsetime, that indicates whether or not the time was accurately recovered by the receiver. The default value of false indicates that the uncertainty of the time value provided (either in the measurement set or in the the gnssTime element) is accurate to an uncertainty of less than one millisecond. This parameter SHOULD be set to true if the receiver does not determine an accurate time before reporting measurement results. If the coarse attribute is set to true, the actual time is derived from the other measurement data; typically this means that additional per-satellite measurements are required.

4.6.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 metres per second. This is converted from a value in Hertz.

codephase:

The observed code phase for the satellite signal, measured in milliseconds. This is converted from a value in chips or wavelengths. Increasing values indicate increasing pseudoranges. This value includes an optional RMS error attribute, 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 metres. This parameter is optional.

cq:

An indication of the carrier quality. Two attributes are included: continuous may be either true or false; direct may be either direct or inverted. This parameter is optional.

adr:

The accumulated Doppler range, measured in metres. This parameter is optional and is not necessary unless multiple sets of GNSS measurements are provided.

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.7.  DSL Measurements

Digital Subscriber Line (DSL) networks rely on a range of network technology. DSL deployments regularly require cooperation between multiple organizations. These fall into two broad categories: infrastructure providers and Internet service providers (ISPs). 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] (Wang, R., “Core Network Architecture Recommendations for Access to Legacy Data Networks over ADSL,” September 1999.) and [DSL.TR101] (Cohen, A. and E. Shrum, “Migration to Ethernet-Based DSl Aggregation,” April 2006.) for further information on DSL network deployments.

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

4.7.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 measurement data that identifies a single L2TP tunnel, from which it can generate location information. Figure 10 (Example DSL L2TP Measurement) 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>

4.7.2.  RADIUS Measurements

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

The format of the AN, slot and port identifiers are not defined in the RADIUS protocol. Slot and port together identify a circuit on the AN, analogous to the circuit identifier in [RFC3046] (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.). These items are provided directly, as they were in the RADIUS message. An example is shown in Figure 11 (Example DSL RADIUS 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">
      <an>AN-7692</an>
      <slot>3</slot>
      <port>06</port>
    </dsl>
  </measurements>

4.7.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 12 (Example DSL VLAN Tag 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">
      <stag>613</stag>
      <ctag>1097</ctag>
    </dsl>
  </measurements>

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.7.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 13 (Example DSL ATM 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">
      <vpi>55</vpi>
      <vci>6323</vci>
    </dsl>
  </measurements>

5.  Measurement Schemas

The schema are broken up into their relative functions. There is a base container schema into which all measurements are placed. There is a basic types schema, that contains various base type definitions for things such as the rmsError and samples attributes IPv4, IPv6 and MAC addresses. Then each of the specific measurement types is defined in its own schema.

5.1.  Measurement Container Schema

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

  <xs:annotation>
    <xs:appinfo
        source="urn:ietf:params:xml:schema:geopriv:held:lm">
    </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.
    </xs:documentation>
  </xs:annotation>

  <xs:element name="measurements">
    <xs:complexType>
      <xs:complexContent>
        <xs:restriction base="xs:anyType">
          <xs:sequence>
            <xs:any namespace="##other" processContents="lax"
                    minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="time" type="xs:dateTime"/>
          <xs:attribute name="expires" type="xs:dateTime"/>
          <xs:anyAttribute namespace="##any" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>

</xs:schema>

5.2.  Base Type Schema

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

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

  <xs:annotation>
    <xs:appinfo
        source="urn:ietf:params:xml:schema:geopriv:lm:basetypes">
    </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 set of base type elements.
    </xs:documentation>
  </xs:annotation>

  <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="nonNegativeDouble">
    <xs:restriction base="xs:double">
      <xs:minInclusive value="0.0"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="positiveDouble">
    <xs:restriction base="bt:nonNegativeDouble">
      <xs:minExclusive value="0.0"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="doubleWithRMSError">
    <xs:simpleContent>
      <xs:extension base="xs:double">
        <xs:attribute name="rmsError" type="bt:positiveDouble"/>
        <xs:attribute name="samples" type="xs:positiveInteger"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="nnDoubleWithRMSError">
    <xs:simpleContent>
      <xs:restriction base="bt:doubleWithRMSError">
        <xs:minInclusive value="0"/>
      </xs:restriction>
    </xs:simpleContent>
  </xs:complexType>

  <xs:simpleType name="ipAddressType">
    <xs:union memberTypes="bt:IPv6AddressType bt: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>

  <!-- IEEE specifies a MAC address as having a -
       between 2 hex digit pairs -->
  <xs:simpleType name="macAddressType">
    <xs:restriction base="xs:token">
      <xs:pattern value="([0-9A-Fa-f]{2}-){5}([0-9A-Fa-f]{2})"/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

5.3.  LLDP Measurement Schema

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

  <xs:annotation>
    <xs:appinfo
        source="urn:ietf:params:xml:schema:geopriv:lm:lldp">
    </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 set of LLDP location measurements.
    </xs:documentation>
  </xs:annotation>

  <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>

  <xs:element name="lldp" type="lldp:lldpMeasurementType"/>
  <xs:complexType name="lldpMeasurementType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="chassis" type="lldp:lldpDataType"/>
          <xs:element name="port" type="lldp: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="lldp:lldpOctetStringType">
        <xs:attribute name="type" type="bt: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>

</xs:schema>

5.4.  DHCP Measurement Schema

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

  <xs:annotation>
    <xs:appinfo
        source="urn:ietf:params:xml:schema:geopriv:lm:dhcp">
    </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 set of DHCP location measurements.
    </xs:documentation>
  </xs:annotation>

  <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>

  <!-- DHCP Relay Agent Information Option -->
  <xs:element name="dhcp-rai" type="dhcp:dhcpType"/>
  <xs:complexType name="dhcpType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="giaddr" type="bt:ipAddressType"/>
          <xs:element name="circuit"
                      type="xs:hexBinary" minOccurs="0"/>
          <xs:element name="remote"
                      type="dhcp: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>

</xs:schema>

5.5.  WiFi Measurement Schema

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

  <xs:annotation>
    <xs:appinfo
        source="urn:ietf:params:xml:schema:geopriv:lm:wifi">
      WiFi location measurements
    </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 basic set of WiFi location measurements.
    </xs:documentation>
  </xs:annotation>

  <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>

  <xs:element name="wifi" type="wifi:wifiNetworkType"/>

  <xs:complexType name="wifiNetworkType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="nicType" type="xs:token"
                      minOccurs="0"/>
          <xs:choice>
            <xs:element name="servingWap" type="wifi:wifiType"/>
            <xs:element name="neighbourWap" type="wifi:wifiType"/>
          </xs:choice>
          <xs:element name="neighbourWap" type="wifi:wifiType"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="wifiType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="ssid" type="wifi:ssidBaseType"/>
          <xs:element name="bssid" type="bt:macAddressType"/>
          <xs:element name="wapname" type="wifi:ssidBaseType"
                      minOccurs="0"/>
          <xs:element name="rssi" type="wifi:rssiType"
                      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:simpleType name="ssidBaseType">
    <xs:restriction base="xs:token">
      <xs:maxLength value="32"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="rssiType">
    <xs:simpleContent>
      <xs:extension base="bt:doubleWithRMSError">
        <xs:attribute name="dBm" type="xs:boolean" default="true"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

</xs:schema>

5.6.  Cellular Measurement Schema

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

  <xs:annotation>
    <xs:appinfo
        source="urn:ietf:params:xml:schema:geopriv:lm:cell">
    </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 set of cellular location measurements.
    </xs:documentation>
  </xs:annotation>

  <xs:element name="cellular" type="cell:cellularType"/>

  <xs:complexType name="cellularType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:choice>
            <xs:element name="servingCell" type="cell:cellType"/>
            <xs:element name="observedCell" type="cell:cellType"/>
          </xs:choice>
          <xs:element name="observedCell" type="cell:cellType"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="cellType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:choice>
          <xs:sequence>
            <xs:element name="mcc" type="cell:mccType"/>
            <xs:element name="mnc" type="cell:mncType"/>
            <xs:choice>
              <xs:element name="rnc" type="cell:cellIdType"/>
              <xs:element name="lac" type="cell:cellIdType"/>
            </xs:choice>
            <xs:element name="cid" type="cell:cellIdType"/>
          </xs:sequence>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
        </xs:choice>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:simpleType name="mccType">
    <xs:restriction base="xs:token">
      <xs:pattern value="[0-9]{3}"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="mncType">
    <xs:restriction base="xs:token">
      <xs:pattern value="[0-9]{2,3}"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="cellIdType">
    <xs:restriction base="xs:nonNegativeInteger">
      <xs:maxInclusive value="65535"/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

5.7.  GNSS Measurement Schema

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

  <xs:annotation>
    <xs:appinfo
        source="urn:ietf:params:xml:schema:geopriv:lm:gnss">
    </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 set of GNSS location measurements
    </xs:documentation>
  </xs:annotation>

  <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>

  <xs:element name="gnss" type="gnss: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:element name="gnssTime" type="bt:nonNegativeDouble"
                      minOccurs="0"/>
          <xs:element name="sat" type="gnss: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:attribute name="coarsetime" type="xs:boolean"
                      default="false"/>
        <xs:anyAttribute namespace="##any" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="gnssSatelliteType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="doppler" type="xs:double"/>
          <xs:element name="codephase" type="bt:nnDoubleWithRMSError"/>
          <xs:element name="cn0" type="bt:nonNegativeDouble"/>
          <xs:element name="mp" type="bt:positiveDouble"
                      minOccurs="0"/>
          <xs:element name="cq" type="gnss:codePhaseQualityType"
                      minOccurs="0"/>
          <xs:element name="adr" type="xs:double" 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>
</xs:schema>

5.8.  DSL Measurement Schema

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

  <xs:annotation>
    <xs:appinfo
        source="urn:ietf:params:xml:schema:geopriv:lm:dsl">
      DSL measurement definitions
    </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 basic set of DSL location measurements.
    </xs:documentation>
  </xs:annotation>

  <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>

  <xs:element name="dsl" type="dsl: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="bt:ipAddressType"/>
                    <xs:element name="dest" type="bt: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="dsl:dslSlotPort"/>
          </xs:sequence>
          <xs:sequence>
            <xs:element name="stag" type="dsl:vlanIDType"/>
            <xs:choice>
              <xs:sequence>
                <xs:element name="ctag" type="dsl:vlanIDType"/>
                <xs:group ref="dsl:dslSlotPort" minOccurs="0"/>
              </xs:sequence>
              <xs:group ref="dsl:dslSlotPort"/>
            </xs:choice>
          </xs:sequence>
          <xs:sequence>
            <xs:element name="vpi" type="bt:byteType"/>
            <xs:element name="vci" type="bt: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>

</xs:schema>

6.  Security Considerations

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

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

A Device is able to explicitly limit the time that a LIS stores measurement data by adding an expiry time to the measurement data, see Section 4.1.2 (Expiry Time on Location-Related Measurement Data).

7.  IANA Considerations

This section creates a registry for GNSS types (GNSS Measurements) and registers the schema from Section 5 (Measurement Schemas).

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.

Each entry in the registry requires the following information:

GNSS name:

the name and a brief description of the GNSS

Brief description:

the name and a brief description of the GNSS

GNSS token:

a token that can be used to identify the GNSS

Signals:

a set of tokens that represent each of the signals that the system provides

Documentation reference:

a reference to a stable, public specification that outlines usage of the GNSS, including (but not limited to) signal specifications and time systems; additionally assistance data formats and supporting protocols can be specified

The registry initially includes two registrations:

GNSS name:

Global Positioning System (GPS)

Brief description:

a system of satellites that use spread-spectrum transmission, operated by the US military for commercial and military applications

GNSS token:

gps

Signals:

L1, L2, L1C, L2C, L5

Documentation reference:

Navstar GPS Space Segment/Navigation User Interface (, “Navstar GPS Space Segment/Navigation User Interface,” Apr 2000.) [GPS.ICD]

GNSS name:

Galileo

Brief description:

a system of satellites that operate in the same spectrum as GPS, operated by the European Union for commercial applications

GNSS Token:

galileo

Signals:

L1, E5A, E5B, E5A+B, E6

Documentation Reference:

Galileo Open Service Signal In Space Interface Control Document (SIS ICD) (GJU, “Galileo Open Service Signal In Space Interface Control Document (SIS ICD),” May 2006.) [Galileo.ICD]

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

This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI: urn:ietf:params:xml:ns:geopriv:lm

Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

XML:

      BEGIN
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
            <title>Measurement Container</title>
          </head>
          <body>
            <h1>Namespace for Location Measurement Container</h1>
            <h2>urn:ietf:params:xml:ns:geopriv:lm</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
    with the RFC number for this specification.]]
            <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
          </body>
        </html>
      END

7.3.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:basetypes

This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:basetypes, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes

Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

XML:

      BEGIN
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
            <title>Base Device Types</title>
          </head>
          <body>
            <h1>Namespace for Base Types</h1>
            <h2>urn:ietf:params:xml:ns:geopriv:lm:basetypes</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
    with the RFC number for this specification.]]
            <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
          </body>
        </html>
      END

7.4.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:lldp

This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:lldp, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI: urn:ietf:params:xml:ns:geopriv:lm:lldp

Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

XML:

      BEGIN
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
            <title>LLDP Measurement Set</title>
          </head>
          <body>
            <h1>Namespace for LLDP Measurement Set</h1>
            <h2>urn:ietf:params:xml:ns:geopriv:lm:lldp</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
    with the RFC number for this specification.]]
            <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
          </body>
        </html>
      END

7.5.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:dhcp

This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:dhcp, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp

Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

XML:

      BEGIN
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
            <title>DHCP Measurement Set</title>
          </head>
          <body>
            <h1>Namespace for DHCP Measurement Set</h1>
            <h2>urn:ietf:params:xml:ns:geopriv:lm:dhcp</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
    with the RFC number for this specification.]]
            <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
          </body>
        </html>
      END

7.6.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:wifi

This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:wifi, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI: urn:ietf:params:xml:ns:geopriv:lm:wifi

Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

XML:

      BEGIN
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
            <title>WiFi Measurement Set</title>
          </head>
          <body>
            <h1>Namespace for WiFi Measurement Set</h1>
            <h2>urn:ietf:params:xml:ns:geopriv:lm:wifi</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
    with the RFC number for this specification.]]
            <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
          </body>
        </html>
      END

7.7.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:cell

This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:cell, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI: urn:ietf:params:xml:ns:geopriv:lm:cell

Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

XML:

      BEGIN
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
            <title>Cellular Measurement Set</title>
          </head>
          <body>
            <h1>Namespace for Cellular Measurement Set</h1>
            <h2>urn:ietf:params:xml:ns:geopriv:lm:cell</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
    with the RFC number for this specification.]]
            <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
          </body>
        </html>
      END

7.8.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:gnss

This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:gnss, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI: urn:ietf:params:xml:ns:geopriv:lm:gnss

Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

XML:

      BEGIN
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
            <title>GNSS Measurement Set</title>
          </head>
          <body>
            <h1>Namespace for GNSS Measurement Set</h1>
            <h2>urn:ietf:params:xml:ns:geopriv:lm:gnss</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
    with the RFC number for this specification.]]
            <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
          </body>
        </html>
      END

7.9.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:dsl

This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:dsl, as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI: urn:ietf:params:xml:ns:geopriv:lm:dsl

Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

XML:

      BEGIN
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
            <title>DSL Measurement Set</title>
          </head>
          <body>
            <h1>Namespace for DSL Measurement Set</h1>
            <h2>urn:ietf:params:xml:ns:geopriv:lm:dsl</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
    with the RFC number for this specification.]]
            <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
          </body>
        </html>
      END

7.10.  XML Schema Registration for Measurement Container Schema

This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:schema:lm

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

Schema:

The XML for this schema can be found in Section 5.1 (Measurement Container Schema) of this document.

7.11.  XML Schema Registration for Base Types Schema

This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:schema:lm:basetypes

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

Schema:

The XML for this schema can be found in Section 5.2 (Base Type Schema) of this document.

7.12.  XML Schema Registration for LLDP Schema

This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:schema:lm:lldp

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

Schema:

The XML for this schema can be found in Section 5.3 (LLDP Measurement Schema) of this document.

7.13.  XML Schema Registration for DHCP Schema

This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:schema:lm:dhcp

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

Schema:

The XML for this schema can be found in Section 5.4 (DHCP Measurement Schema) of this document.

7.14.  XML Schema Registration for WiFi Schema

This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:schema:lm:wifi

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

Schema:

The XML for this schema can be found in Section 5.5 (WiFi Measurement Schema) of this document.

7.15.  XML Schema Registration for Cellular Schema

This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:schema:lm:cellular

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

Schema:

The XML for this schema can be found in Section 5.6 (Cellular Measurement Schema) of this document.

7.16.  XML Schema Registration for GNSS Schema

This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:schema:lm:gnss

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

Schema:

The XML for this schema can be found in Section 5.7 (GNSS Measurement Schema) of this document.

7.17.  XML Schema Registration for DSL Schema

This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:schema:lm:dsl

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

Schema:

The XML for this schema can be found in Section 5.8 (DSL Measurement Schema) of this document.

8.  Acknowledgements

Thanks go to Simon Cox for his comments relating to terminology that have helped ensure that this document is aligns with ongoing work in the Open Geospatial Consortium (OGC). Thanks to Dr Neil Harper for his review and comments on the GNSS sections of this document. Thanks to Noor-E-Gagan Singh for his suggestions relating to the WiFi section of this document.

9.  References

9.1. Normative References

9.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

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.