GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew
Expires: June 13, 2008 December 11, 2007
Using Device-provided Location Measurements in HELD
draft-thomson-geopriv-held-measurements-01.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 June 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Thomson & Winterbottom Expires June 13, 2008 [Page 1]
Internet-Draft Location Measurements for HELD December 2007
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Location Measurements in HELD Requests . . . . . . . . . . . . 5
4. Measurement Types . . . . . . . . . . . . . . . . . . . . . . 6
4.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 6
4.2. DHCP Measurements . . . . . . . . . . . . . . . . . . . . 7
4.3. 802.11 SSID Measurement . . . . . . . . . . . . . . . . . 7
4.4. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 7
4.4.1. GNSS System and Signal . . . . . . . . . . . . . . . . 9
4.4.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4.3. Per-Satellite Measurements . . . . . . . . . . . . . . 10
4.5. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 11
4.5.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 11
4.5.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 12
4.5.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 12
4.5.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 13
5. Measurement Schema . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6.1. Expiry Time on Measurements . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 22
7.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:held:lm . . . . . . . . . . . . . . 23
7.3. XML Schema Registration for Measurement Schema . . . . . . 23
7.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:ip . . . . . . . . . . . . . . . . 24
7.5. XML Schema Registration for IP Address Type Schema . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
Thomson & Winterbottom Expires June 13, 2008 [Page 2]
Internet-Draft Location Measurements for HELD December 2007
1. Introduction
HELD [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.
Thomson & Winterbottom Expires June 13, 2008 [Page 3]
Internet-Draft Location Measurements for HELD December 2007
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].
This document also uses the following definitions:
Location Measurement: An observation about the physical properties
of a particular device's network access. A location measurement
can be used to determine the location of a device; however,
location measurements do not identify a Device. Location
measurements can change with time if the location of the Device
also changes.
A location measurement does not necessarily contain location
information but it can be used in combination with contextual
knowledge of the network, or algorithms to derive location
information. Examples of location measurements: radio signal
strength or timing measurements, Ethernet switch and port
identifiers.
Location measurements can be considered sighting information,
based on the definition in [RFC3693].
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
measurement errors.
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].
Thomson & Winterbottom Expires June 13, 2008 [Page 4]
Internet-Draft Location Measurements for HELD December 2007
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.
The simplest example of measurement conveyance is illustrated by the
example message in Figure 1. This shows a HELD location request
message with an Ethernet switch and port measurement taken using LLDP
[IEEE.8021AB].
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">civic</locationType>
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<lldp>
<chassis type="4">0a01003c</chassis>
<port type="6">c2</port>
</lldp>
</measurements>
</locationRequest>
Figure 1: HELD Location Request with Measurement
Measurements that the LIS does not support or understand can be
ignored.
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.
Thomson & Winterbottom Expires June 13, 2008 [Page 5]
Internet-Draft Location Measurements for HELD December 2007
4. Measurement Types
This document defines measurements for a range of common network
types.
Note: Not all of these measurement types are provided by the Device;
they may be acquired by other hosts in situations such as those
described in [I-D.winterbottom-geopriv-lis2lis-req].
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.
An example of an LLDP measurement is shown in Figure 2. This shows
an adjacent node (chassis) that is identified by the IP address
192.0.2.45 and the port on that node is numbered using an agent
circuit ID [RFC3046] of 162.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<lldp>
<chassis type="4">c000022d</chassis>
<port type="6">a2</port>
</lldp>
</measurements>
Figure 2: LLDP Measurement Example
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.
Thomson & Winterbottom Expires June 13, 2008 [Page 6]
Internet-Draft Location Measurements for HELD December 2007
4.2. DHCP Measurements
The DHCP Relay Agent Information option [RFC3046] provides
measurement information about a Device. This measurement information
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]), remote
identifier ("remote", [RFC3046], [RFC4649]) and subscriber identifier
("subscriber", [RFC3993], [RFC4580]). The DHCPv6 remote identifier
has an associated enterprise number [IANA.enterprise] as an XML
attribute.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<dhcp-rai>
<giaddr>2001:DB8::215:c5ff:fee1:505e</giaddr>
<remote enterprise="331">108b</remote>
</dhcp-rai>
</measurements>
Figure 3: DHCP Relay Agent Information Measurement Example
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.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<ssid>wlan-home</ssid>
</measurements>
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.
Determining location and time in autonomous GNSS receivers follows
three steps:
Thomson & Winterbottom Expires June 13, 2008 [Page 7]
Internet-Draft Location Measurements for HELD December 2007
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 measurements
for a minimum of 5 satellites. At this stage, measurement
information 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 information 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 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.
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 5 shows an example GNSS measurement. The measurement shown is
for the GPS system and includes measurements for three satellites
only.
Thomson & Winterbottom Expires June 13, 2008 [Page 8]
Internet-Draft Location Measurements for HELD December 2007
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<gnss system="gps" signal="L1">
<time coarse="false">98375200</time>
<sat num="19">
<doppler>499.9395</doppler><codephase>0.87595747</codephase>
<cn0>45</cn0><err>0.5</err>
</sat>
<sat num="27">
<doppler>378.2657</doppler><codephase>0.56639479</codephase>
<cn0>52</cn0><err>0.5</err>
</sat>
<sat num="20">
<doppler>-633.0309</doppler><codephase>0.57016835</codephase>
<cn0>48</cn0><err>0.5</err>
</sat>
</gnss>
</measurements>
Figure 5: Example GNSS Measurement
Each "gnss" element represents a single set of GNSS measurement data,
taken at a single point in time. Measurements taken at different
times can be included in different "gnss" elements to enable
iterative refinement of results.
GNSS measurement parameters are described in more detail in the
following sections.
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.
Thomson & Winterbottom Expires June 13, 2008 [Page 9]
Internet-Draft Location Measurements for HELD December 2007
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.
Both the GPS and Galileo systems use satellite numbers between 1 and
64.
The GNSS receiver measures the following parameters for each
satellite:
doppler: The observed Doppler shift of the satellite signal,
measured in meters per second. This is converted from a value in
Hertz.
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.
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.
Thomson & Winterbottom Expires June 13, 2008 [Page 10]
Internet-Draft Location Measurements for HELD December 2007
err: The estimated RMS error for the code phase measurement; i.e. an
estimate of code phase uncertainty. This value is measured in
meters.
mp: An estimation of the amount of error that multipath signals
contribute in meters. This measurement 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 measurement parameter is
optional.
adr: The accumulated Doppler range, measured in meters. This
measurement parameter is optional and should not be included
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.5. 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] and [DSL.TR101] 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 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 shows an
Thomson & Winterbottom Expires June 13, 2008 [Page 11]
Internet-Draft Location Measurements for HELD December 2007
example L2TP measurement.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<dsl>
<l2tp>
<src>192.0.2.10</src>
<dest>192.0.2.61</dest>
<session>528</session>
</l2tp>
</dsl>
</measurements>
Figure 6: Example DSL L2TP Measurement
4.5.2. RADIUS Measurements
When authenticating network access, the infrastructure provider might
employ RADIUS [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.
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, analagous to the circuit identifier in [RFC3046]. These
items are provided directly, as they were in the RADIUS message. An
example is shown in Figure 7.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<dsl>
<an>AN-7692</an>
<slot>3</slot>
<port>06</port>
</dsl>
</measurements>
Figure 7: Example DSL RADIUS Measurement
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.
Thomson & Winterbottom Expires June 13, 2008 [Page 12]
Internet-Draft Location Measurements for HELD December 2007
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<dsl>
<stag>613</stag>
<ctag>1097</ctag>
</dsl>
</measurements>
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.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<dsl>
<vpi>55</vpi>
<vci>6323</vci>
</dsl>
</measurements>
Figure 9: Example DSL ATM Measurement
Thomson & Winterbottom Expires June 13, 2008 [Page 13]
Internet-Draft Location Measurements for HELD December 2007
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">
Thomson & Winterbottom Expires June 13, 2008 [Page 14]
Internet-Draft Location Measurements for HELD December 2007
<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>
Thomson & Winterbottom Expires June 13, 2008 [Page 15]
Internet-Draft Location Measurements for HELD December 2007
</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">
Thomson & Winterbottom Expires June 13, 2008 [Page 16]
Internet-Draft Location Measurements for HELD December 2007
<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>
Thomson & Winterbottom Expires June 13, 2008 [Page 17]
Internet-Draft Location Measurements for HELD December 2007
</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"/>
Thomson & Winterbottom Expires June 13, 2008 [Page 18]
Internet-Draft Location Measurements for HELD December 2007
</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 -->
Thomson & Winterbottom Expires June 13, 2008 [Page 19]
Internet-Draft Location Measurements for HELD December 2007
<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>
Thomson & Winterbottom Expires June 13, 2008 [Page 20]
Internet-Draft Location Measurements for HELD December 2007
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.
Thomson & Winterbottom Expires June 13, 2008 [Page 21]
Internet-Draft Location Measurements for HELD December 2007
7. IANA Considerations
This section creates a registry for GNSS types (Section 4.4) and
registers the schema from Section 5.
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], 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 [GPS.ICD]
Thomson & Winterbottom Expires June 13, 2008 [Page 22]
Internet-Draft Location Measurements for HELD December 2007
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) [Galileo.ICD]
7.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:lm
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:held:lm", as per the guidelines in [RFC3688].
URI: urn:ietf:params:xml:ns:held: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>HELD Measurements</title>
</head>
<body>
<h1>Namespace for HELD Measurements</h1>
<h2>urn:ietf:params:xml:ns:held: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. XML Schema Registration for Measurement Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
Thomson & Winterbottom Expires June 13, 2008 [Page 23]
Internet-Draft Location Measurements for HELD December 2007
URI: urn:ietf:params:xml:schema:held: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 of this
document.
7.4. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:ip
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:ip", as per the guidelines in [RFC3688].
URI: urn:ietf:params:xml:ns:ip
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>IP Address Types</title>
</head>
<body>
<h1>Namespace for IP Address Types</h1>
<h2>urn:ietf:params:xml:ns:ip</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. XML Schema Registration for IP Address Type Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:ip
Thomson & Winterbottom Expires June 13, 2008 [Page 24]
Internet-Draft Location Measurements for HELD December 2007
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 of this
document.
Thomson & Winterbottom Expires June 13, 2008 [Page 25]
Internet-Draft Location Measurements for HELD December 2007
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[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-03 (work in
progress), November 2007.
8.2. Informative References
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
August 2006.
[IANA.enterprise]
IANA, "Private Enterprise Numbers",
<http://www.iana.org/assignments/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.
[RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
June 2006.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[IEEE.8021AB]
IEEE, "IEEE Standard for Local and Metropolitan area
networks, Station and Media Access Control Connectivity
Discovery", 802.1AB, June 2005.
Thomson & Winterbottom Expires June 13, 2008 [Page 26]
Internet-Draft Location Measurements for HELD December 2007
[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.
[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.
Thomson & Winterbottom Expires June 13, 2008 [Page 27]
Internet-Draft Location Measurements for HELD December 2007
Authors' Addresses
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/
Thomson & Winterbottom Expires June 13, 2008 [Page 28]
Internet-Draft Location Measurements for HELD December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Thomson & Winterbottom Expires June 13, 2008 [Page 29]