One document matched: draft-thomson-geopriv-held-measurements-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2434 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY RFC2865 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC3046 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3046.xml">
<!ENTITY RFC3688 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC3693 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml">
<!ENTITY RFC4649 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4649.xml">
<!ENTITY RFC3993 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3993.xml">
<!ENTITY RFC4580 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4580.xml">
<!ENTITY I-D.ietf-geopriv-http-location-delivery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml">
<!ENTITY I-D.winterbottom-geopriv-lis2lis-req PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-lis2lis-req.xml">
]>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<rfc category="std" ipr="full3978" docName="draft-thomson-geopriv-held-measurements-00.txt">
<front>
<title abbrev="Location Measurements for HELD">
Using Device-provided Location Measurements in HELD
</title>
<author initials="M." surname="Thomson"
fullname="Martin Thomson">
<organization>Andrew</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>Wollongong University Campus</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<phone>+61 2 4221 2915</phone>
<email>martin.thomson@andrew.com</email>
<uri>http://www.andrew.com/</uri>
</address>
</author>
<author initials="J." surname="Winterbottom"
fullname="James Winterbottom">
<organization>Andrew</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>Wollongong University Campus</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<phone>+61 2 4221 2938</phone>
<email>james.winterbottom@andrew.com</email>
<uri>http://www.andrew.com/</uri>
</address>
</author>
<date month="October" year="2007"/>
<area>Application</area>
<workgroup>GEOPRIV</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>HELD</keyword>
<keyword>Location</keyword>
<keyword>Measurements</keyword>
<keyword>Device-based</keyword>
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref> 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.
</t>
<t>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.
</t>
</section>
<section anchor="conventions" title="Conventions used in this document">
<t>The terms LIS and Device are used in this document in a manner consistent with the usage in <xref target="I-D.ietf-geopriv-http-location-delivery"/>.
</t>
<t>This document also uses the following definitions:
<list style="hanging">
<t hangText="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.
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
Location measurements can be considered sighting information, based on the definition in <xref target="RFC3693"/>.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
</list>
</t>
<t>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 <xref target="RFC2119"/>.
</t>
</section>
<section title="Location Measurements in HELD Requests">
<t>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.
</t>
<t>The simplest example of measurement conveyance is illustrated by the example message in <xref target="ex-basic"/>. This shows a HELD location request message with an Ethernet switch and port measurement taken using <xref target="IEEE.8021AB">LLDP</xref>.
</t>
<figure anchor="ex-basic" title="HELD Location Request with Measurement">
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
<t>Measurements that the LIS does not support or understand can be ignored.
</t>
<t>Multiple measurements, either of the same type or from different sources can be included in the <spanx style="verb">measurements</spanx> element. The <spanx style="verb">measurements</spanx> element SHOULD NOT be repeated.
</t>
<t>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.
</t>
<t>Using measurements is at the discretion of the LIS, but the <spanx style="verb">method</spanx> parameter in the PIDF-LO SHOULD be adjusted reflect the method used.
</t>
</section>
<section title="Measurement Types">
<t>This document defines measurements for a range of common network types.
<list style="hanging">
<t hangText="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 <xref target="I-D.winterbottom-geopriv-lis2lis-req"/>.
</t>
</list>
</t>
<section title="LLDP Measurements">
<t>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.
</t>
<t>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.
</t>
<t>Where a Device has received LLDP messages from multiple adjacent nodes, it should provide information extracted from those messages by repeating the <spanx style="verb">lldp</spanx> element.
</t>
<t>An example of an LLDP measurement is shown in <xref target="ex-lldp"/>. 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 <xref target="RFC3046">agent circuit ID</xref> of 162.
</t>
<figure anchor="ex-lldp" title="LLDP Measurement Example">
<artwork><![CDATA[
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<lldp>
<chassis type="4">c000022d</chassis>
<port type="6">a2</port>
</lldp>
</measurements>
]]></artwork>
</figure>
<t>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.
</t>
</section>
<section title="DHCP Measurements">
<t>The <xref target="RFC3046">DHCP Relay Agent Information option</xref> provides measurement information about a Device. This measurement information can be included in the <spanx style="verb">dhcp-rai</spanx> element.
</t>
<t>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 (<spanx style="verb">circuit</spanx>, <xref target="RFC3046"/>), remote identifier (<spanx style="verb">remote</spanx>, <xref target="RFC3046"/>, <xref target="RFC4649"/>) and subscriber identifier (<spanx style="verb">subscriber</spanx>, <xref target="RFC3993"/>, <xref target="RFC4580"/>). The DHCPv6 remote identifier has an associated <xref target="IANA.enterprise">enterprise number</xref> as an XML attribute.
</t>
<figure anchor="ex-dhcp" title="DHCP Relay Agent Information Measurement Example">
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
</section>
<section title="802.11 SSID Measurement">
<t>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 <spanx style="verb">ssid</spanx> element, as shown in <xref target="ex-ssid"/>.
</t>
<figure anchor="ex-ssid" title="802.11 SSID Measurement Example">
<artwork><![CDATA[
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<ssid>wlan-home</ssid>
</measurements>
]]></artwork>
</figure>
</section>
<section anchor="gnss" title="GNSS Measurements">
<t>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.
</t>
<t>Determining location and time in autonomous GNSS receivers follows three steps:
<list style="hanging">
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="Calculation:">The measurement information is combined with the data on the satellite constellation to determine the location of the receiver and the current time.
</t>
</list></t>
<t>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.
</t>
<t><list style="empty">
<t>Note: The use of different sets of GNSS <spanx style="emph">assistance data</spanx> 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.
</t>
</list></t>
<t><xref target="ex-agnss"/> shows an example GNSS measurement. The measurement shown is for the GPS system and includes measurements for three satellites only.
</t>
<figure anchor="ex-agnss" title="Example GNSS Measurement">
<artwork><![CDATA[
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<gnss system="gps" signal="L1">
<time>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>
]]></artwork>
</figure>
<t>Each <spanx style="verb">gnss</spanx> 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 <spanx style="verb">gnss</spanx> elements to enable iterative refinement of results.
</t>
<t>GNSS measurement parameters are described in more detail in the following sections.
</t>
<section title="GNSS System and Signal">
<t>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.
</t>
<t>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.
</t>
<t>Measurements for multiple GNSS types and signals can be included by repeating the <spanx style="verb">gnss</spanx> element.
</t>
<t>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 <xref target="iana-gnss"/>.
</t>
</section>
<section title="Time">
<t>Each set of GNSS measurements is taken at a specific point in time. The <spanx style="verb">time</spanx> element includes a relative time in milliseconds using the time system native to the satellite system.
</t>
<t>For the GPS satellite system, the <spanx style="verb">time</spanx> element includes the time of week in milliseconds. For the Galileo system, the <spanx style="verb">time</spanx> element includes the time of day in milliseconds.
</t>
<t>Alternatively, a specific instant of time can be specified using the <spanx style="verb">abstime</spanx> element. This element includes an ISO 8601 formatted date and time, which SHOULD be measured to within one millisecond.
</t>
</section>
<section title="Per-Satellite Measurements">
<t>Multiple satellites are included in each set of GNSS measurements using the <spanx style="verb">sat</spanx> element. Each satellite is identified by a number in the <spanx style="verb">num</spanx> attribute. The satellite number is consistent with the identifier used in the given GNSS.
</t>
<t>Both the GPS and Galileo systems use satellite numbers between 1 and 64.
</t>
<t>The GNSS receiver measures the following parameters for each satellite:
<list style="hanging">
<t hangText="doppler:">The observed Doppler shift of the satellite signal, measured in meters per second. This is converted from a value in Hertz.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="err:">The estimated RMS error for the code phase measurement; i.e. an estimate of code phase uncertainty. This value is measured in meters.
</t>
<t hangText="mp:">An estimation of the amount of error that multipath signals contribute in meters. This measurement parameter is optional.
</t>
<t hangText="cq:">An indication of the carrier quality. Two attributes are included: <spanx style="verb">continuous</spanx> may be either <spanx style="verb">true</spanx> or <spanx style="verb">false</spanx>; direct may be either <spanx style="verb">direct</spanx> or <spanx style="verb">inverted</spanx>. This measurement parameter is optional.
</t>
<t hangText="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.
</t>
</list>
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.
</t>
</section>
</section>
<section title="DSL Measurements">
<t>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 <xref target="DSL.TR025"/> and <xref target="DSL.TR101"/> for further information on DSL network deployments.
</t>
<t>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.
</t>
<t>
</t>
<section title="L2TP Measurements">
<t>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. <xref target="ex-dsl-l2tp"/> shows an example L2TP measurement.
</t>
<figure anchor="ex-dsl-l2tp" title="Example DSL L2TP Measurement">
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
</section>
<section title="RADIUS Measurements">
<t>When authenticating network access, the infrastructure provider might employ <xref target="RFC2865">RADIUS</xref> 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.
</t>
<t>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 <xref target="RFC3046"/>. These items are provided directly, as they were in the RADIUS message. An example is shown in <xref target="ex-dsl-radius"/>.
</t>
<figure anchor="ex-dsl-radius" title="Example DSL RADIUS Measurement">
<artwork><![CDATA[
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<dsl>
<an>AN-7692</an>
<slot>3</slot>
<port>06</port>
</dsl>
</measurements>
]]></artwork>
</figure>
</section>
<section title="Ethernet VLAN Tag Measurements">
<t>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 <xref target="ex-dsl-vlan"/>.
</t>
<figure anchor="ex-dsl-vlan" title="Example DSL VLAN Tag Measurement">
<artwork><![CDATA[
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<dsl>
<stag>613</stag>
<ctag>1097</ctag>
</dsl>
</measurements>
]]></artwork>
</figure>
<t>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.
</t>
</section>
<section title="ATM Virtual Circuit Measurements">
<t>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 <xref target="ex-dsl-atm"/>.
</t>
<figure anchor="ex-dsl-atm" title="Example DSL ATM Measurement">
<artwork><![CDATA[
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<dsl>
<vpi>55</vpi>
<vci>6323</vci>
</dsl>
</measurements>
]]></artwork>
</figure>
</section>
</section>
</section>
<section anchor="schema" title="Measurement Schema">
<t>Note that the pattern rules in the following schema wrap due to length constraints in RFC. None of the patterns contain whitespace.
</t>
<figure>
<artwork><![CDATA[
<?xml version="1.0"?>
<xs:schema
xmlns:lm="urn:ietf:params:xml:ns:geopriv:held:lm"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:lm"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:lm">
HELD Capabilities
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a framework for location measurements
in HELD and several measurement formats.
</xs:documentation>
</xs:annotation>
<xs:element name="measurements">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="lm:lldp" minOccurs="0"/>
<xs:element ref="lm:dhcp-rai" minOccurs="0"/>
<xs:element ref="lm:ssid" minOccurs="0"/>
<xs:element ref="lm:gnss" minOccurs="0"/>
<xs:element ref="lm:dsl" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!-- LLDP -->
<xs:element name="lldp" type="lm:lldpMeasurementType"/>
<xs:complexType name="lldpMeasurementType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="chassis" type="lm:lldpDataType"/>
<xs:element name="port" type="lm:lldpDataType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="lldpDataType">
<xs:simpleContent>
<xs:extension base="lm:lldpOctetStringType">
<xs:attribute name="type" type="lm:byteType"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="lldpOctetStringType">
<xs:restriction base="xs:hexBinary">
<xs:minLength value="1"/>
<xs:maxLength value="255"/>
</xs:restriction>
</xs:simpleType>
<!-- DHCP Relay Agent Information Option -->
<xs:element name="dhcp-rai" type="lm:dhcpType"/>
<xs:complexType name="dhcpType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="giaddr" type="lm:ipAddressType"/>
<xs:element name="circuit"
type="xs:hexBinary" minOccurs="0"/>
<xs:element name="remote"
type="lm:dhcpRemoteType" minOccurs="0"/>
<xs:element name="subscriber"
type="xs:hexBinary" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="dhcpRemoteType">
<xs:simpleContent>
<xs:extension base="xs:hexBinary">
<xs:attribute name="enterprise" type="xs:positiveInteger"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- 802.11 SSID -->
<xs:element name="ssid" type="lm:ssidType"/>
<xs:simpleType name="ssidType">
<xs:restriction base="xs:token">
<xs:maxLength value="32"/>
</xs:restriction>
</xs:simpleType>
<!-- GNSS -->
<xs:element name="gnss" type="lm:gnssMeasurementType">
<xs:unique name="gnssSatellite">
<xs:selector xpath="sat"/>
<xs:field xpath="@num"/>
</xs:unique>
</xs:element>
<xs:complexType name="gnssMeasurementType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:choice>
<xs:element name="abstime" type="xs:dateTime"/>
<xs:element name="time" type="lm:nonNegativeDecimal"/>
</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="gnssSatelliteType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="doppler" type="xs:decimal"/>
<xs:element name="codephase" type="lm:nonNegativeDecimal"/>
<xs:element name="cn0" type="xs:nonNegativeInteger"/>
<xs:element name="err" type="lm:nonNegativeDecimal"/>
<xs:element name="mp" type="xs:positiveInteger"
minOccurs="0"/>
<xs:element name="cq" type="lm:codePhaseQualityType"
minOccurs="0"/>
<xs:element name="adr" type="xs:decimal" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="num" type="xs:positiveInteger"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="codePhaseQualityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:attribute name="continuous" type="xs:boolean"
default="true"/>
<xs:attribute name="direct" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="direct"/>
<xs:enumeration value="inverted"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- DSL Measurements -->
<xs:element name="dsl" type="lm:dslVlanType"/>
<xs:complexType name="dslVlanType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:element name="l2tp">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="src" type="lm:ipAddressType"/>
<xs:element name="dest" type="lm:ipAddressType"/>
<xs:element name="session"
type="xs:nonNegativeInteger"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:sequence>
<xs:element name="an" type="xs:token"/>
<xs:group ref="lm:dslSlotPort"/>
</xs:sequence>
<xs:sequence>
<xs:element name="stag" type="lm:vlanIDType"/>
<xs:choice>
<xs:sequence>
<xs:element name="ctag" type="lm:vlanIDType"/>
<xs:group ref="lm:dslSlotPort" minOccurs="0"/>
</xs:sequence>
<xs:group ref="lm:dslSlotPort"/>
</xs:choice>
</xs:sequence>
<xs:sequence>
<xs:element name="vpi" type="lm:byteType"/>
<xs:element name="vci" type="lm:twoByteType"/>
</xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="vlanIDType">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="4095"/>
</xs:restriction>
</xs:simpleType>
<xs:group name="dslSlotPort">
<xs:sequence>
<xs:element name="slot" type="xs:token"/>
<xs:element name="port" type="xs:token"/>
</xs:sequence>
</xs:group>
<!-- Common Data Types -->
<xs:simpleType name="byteType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="255"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="twoByteType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="65535"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="nonNegativeDecimal">
<xs:restriction base="xs:decimal">
<xs:minInclusive value="0.0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ipAddressType">
<xs:union memberTypes="lm:IPv6AddressType lm:IPv4AddressType"/>
</xs:simpleType>
<!-- IPv6 format definition -->
<xs:simpleType name="IPv6AddressType">
<xs:annotation>
<xs:documentation>
An IP version 6 address, based on RFC 4291.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:token">
<!-- Fully specified address -->
<xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/>
<!-- Double colon start -->
<xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/>
<!-- Double colon middle -->
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6}
(:[0-9A-Fa-f]{1,4}){1}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
(:[0-9A-Fa-f]{1,4}){1,2}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
(:[0-9A-Fa-f]{1,4}){1,3}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,3}
(:[0-9A-Fa-f]{1,4}){1,4}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
(:[0-9A-Fa-f]{1,4}){1,5}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
(:[0-9A-Fa-f]{1,4}){1,6}"/>
<!-- Double colon end -->
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,7}:"/>
<!-- IPv4-Compatible and IPv4-Mapped Addresses -->
<xs:pattern value="((:(:0{1,4}){0,3}:[fF]{4})
|(0{1,4}:(:0{1,4}){0,2}:[fF]{4})
|((0{1,4}:){2}(:0{1,4})?:[fF]{4})
|((0{1,4}:){3}:[fF]{4})
|((0{1,4}:){4}[fF]{4}))
:(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
\.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
\.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
\.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])"/>
<!-- The unspecified address -->
<xs:pattern value="::"/>
</xs:restriction>
</xs:simpleType>
<!-- IPv4 format definition -->
<xs:simpleType name="IPv4AddressType">
<xs:restriction base="xs:token">
<xs:pattern value="(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
\.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
\.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])
\.(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
]]></artwork>
</figure>
</section>
<section anchor="security" title="Security Considerations">
<t>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.
</t>
<t>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.
</t>
<!-- <t>Knowledge of appropriate network configuration or algorithms enables the receiver of location measurements to generate location information. Therefore, the privacy considerations relating to location measurements are, at worst, as significant as the privacy considerations for location information.
</t>
-->
<section title="Expiry Time on Measurements">
<t>A Device is able to indicate a time in the location measurement using the <spanx style="verb">expires</spanx> 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.
</t>
<t>The LIS MUST NOT keep location measurements beyond the time indicated in the <spanx style="verb">expires</spanx> attribute. Where the <spanx style="verb">expires</spanx> attribute is not provided, the LIS MUST discard location measurements immediately after servicing the current request.
</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This section creates a registry for <xref target="gnss">GNSS types</xref> and registers the schema from <xref target="schema"/>.
</t>
<section anchor="iana-gnss" title="IANA Registry for GNSS Types">
<t>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 <xref target="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.
</t>
<t>Each entry in the registry requires the following information:
<list style="hanging">
<t hangText="GNSS name:">the name and a brief description of the GNSS
</t>
<t hangText="Brief description:">the name and a brief description of the GNSS
</t>
<t hangText="GNSS token:">a token that can be used to identify the GNSS
</t>
<t hangText="Signals:">a set of tokens that represent each of the signals that the system provides
</t>
<t hangText="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
</t>
</list>
</t>
<t>The registry initially includes two registrations:
<list style="hanging">
<t hangText="GNSS name:">Global Positioning System (GPS)
</t>
<t hangText="Brief description:">a system of satellites that use spread-spectrum transmission, operated by the US military for commercial and military applications
</t>
<t hangText="GNSS token:">gps
</t>
<t hangText="Signals:">L1, L2, L1C, L2C, L5
</t>
<t hangText="Documentation reference:"><xref target="GPS.ICD">Navstar GPS Space Segment/Navigation User Interface</xref>
</t>
</list>
<list style="hanging">
<t hangText="GNSS name:">Galileo
</t>
<t hangText="Brief description:">a system of satellites that operate in the same spectrum as GPS, operated by the European Union for commercial applications
</t>
<t hangText="GNSS Token:">galileo
</t>
<t hangText="Signals:">L1, E5A, E5B, E5A+B, E6
</t>
<t hangText="Documentation Reference:"><xref target="Galileo.ICD">Galileo Open Service Signal In Space Interface Control Document (SIS ICD)</xref>
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:lm">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:held:lm</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:held:lm</t>
<t>Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t>XML:
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="XML Schema Registration for Measurement Schema">
<t>This section registers an XML schema as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:held:lm</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t hangText="Schema:">The XML for this schema can be found in <xref target="schema"/> of this document.
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:ip">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:ip</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:ip</t>
<t>Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t>XML:
<figure>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="XML Schema Registration for IP Address Type Schema">
<t>This section registers an XML schema as per the guidelines in <xref target="RFC3688"/>.
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:ip</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).</t>
<t hangText="Schema:">The XML for this schema can be found in <xref target="schema"/> of this document.
</t>
</list>
</t>
</section>
</section>
<!--
<appendix title="Change Log">
<t>[[The RFC Editor is requested to remove this section at publication.]]</t>
<t>Changes since -0-1:
<list style="symbols">
<t>Document created.</t>
</list>
</t>
</appendix>
-->
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2434;
&I-D.ietf-geopriv-http-location-delivery;
</references>
<references title="Informative References">
&RFC3693;
&RFC3046;
&RFC4649;
<reference anchor="IANA.enterprise" target="http://www.iana.org/assignments/enterprise-numbers">
<front>
<title>Private Enterprise Numbers</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
&RFC3993;
&RFC4580;
&RFC3688;
<reference anchor="IEEE.8021AB">
<front>
<title>IEEE Standard for Local and Metropolitan area networks, Station and Media Access Control Connectivity Discovery</title>
<author>
<organization>IEEE</organization>
</author>
<date month="June" day="28" year="2005" />
</front>
<seriesInfo name="" value="802.1AB"/>
</reference>
<reference anchor="GPS.ICD">
<front>
<title>Navstar GPS Space Segment/Navigation User Interface</title>
<author>
<organization></organization>
</author>
<date month="Apr" year="2000" />
</front>
<seriesInfo name="ICD" value="GPS-200"/>
</reference>
<reference anchor="Galileo.ICD">
<front>
<title>Galileo Open Service Signal In Space Interface Control Document (SIS ICD)</title>
<author>
<organization>GJU</organization>
</author>
<date month="May" year="2006" />
</front>
</reference>
&I-D.winterbottom-geopriv-lis2lis-req;
<reference anchor="DSL.TR025">
<front>
<title>Core Network Architecture Recommendations for Access to Legacy Data Networks over ADSL</title>
<author initials="R" surname="Wang" fullname="Ray Wang">
<organization>DSL Forum</organization>
</author>
<date month="September" year="1999" />
<abstract>
<t>This document presents the Core Network architecture for ADSL service access to legacy data networks. The content of the text is derived from several ADSL Forum architecture contributions and other references.
</t>
</abstract>
</front>
</reference>
<reference anchor="DSL.TR101">
<front>
<title>Migration to Ethernet-Based DSl Aggregation</title>
<author initials="A" surname="Cohen" fullname="Amit Cohen">
<organization>ECI Telecom</organization>
</author>
<author initials="E" surname="Shrum" fullname="Ed Shrum">
<organization>BellSouth Telecommunications</organization>
</author>
<date month="April" year="2006" />
<abstract>
<t>This Technical Report outlines how an ATM aggregation network can be migrated to an Ethernet based aggregation network in the context of TR-25 and TR-59 based architectures. This document provides an architectural/topological model of such an Ethernet based aggregation network that supports the business requirements in TR-058. In doing so it describes requirements for protocol translation and interworking, QoS, multicast, security, and OAM for a DSL aggregation network.
</t>
</abstract>
</front>
</reference>
&RFC2865;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:36:21 |