One document matched: draft-thomson-geopriv-held-measurements-04.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 RFC4291 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.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 RFC5491 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5491.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">
<!ENTITY I-D.thomson-geopriv-uncertainty PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-uncertainty.xml">
]>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<rfc category="std" ipr="pre5378Trust200902">
<front>
<title abbrev="Location Measurements">
Using Device-provided Location-Related Measurements in Location Configuration Protocols
</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="May" year="2009"/>
<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 location-related measurement data to a LIS within a request for location information. 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. 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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>A location configuration protocol (LCP) provides a means for a Device to request information about its physical location from an access network. A location information server (LIS) is the server that provides location information; information that is available due to the knowledge about the network and physical environment that is available to the LIS.
</t>
<t>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.
</t>
<t>A Device is able to make observations about its network attachment, or its physical environment. The location-related measurement data might be unavailable to the LIS; alternatively, the LIS might be able to acquire the data, but at a higher cost in time or otherwise. Providing measurement data gives the LIS more options in determining location, which could improve the quality of the service provided by the LIS. Improvements in accuracy are one potential gain, but improved response times and lower error rates are also possible.
</t>
<t>This document describes a means for a Device to report location-related measurement data to the LIS. Examples based on the <xref target="I-D.ietf-geopriv-http-location-delivery">HELD</xref> location configuration protocol are provided.
</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. 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. Location-related measurement data does not identify a Device; measurement data can change with time if the location of the Device also changes.
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
Location-related measurement data 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 errors in measurement results.
</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-Related Measurements in LCPs">
<t>This document defines a standard container for the conveyance of location-related measurement parameters in location configuration protocols. 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.
</t>
<t>The simplest example of measurement data 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 Data">
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
<t>Location-related measurement data need not be provided exclusively by Devices. Intermediaries involved in cooperative location determination, such as a the second LIS in <xref target="I-D.winterbottom-geopriv-lis2lis-req"/>, might provide a LIS with measurement data.
</t>
<t>Measurement data that the LIS does not support or understand can be ignored. The measurements defined in this document follow this rule; extensions that could result in backward incompatibility MUST be added as new measurement definitions rather than extensions to existing types.
</t>
<t>Multiple sets of measurement data, either of the same type or from different sources can be included in the <spanx style="verb">measurements</spanx> element. See <xref target="time"/> for details on repetition of this element.
</t>
<section anchor="using" title="Using Location-Releated Measurement Data">
<t>Using location-related measurement data is at the discretion of the LIS, but the <spanx style="verb">method</spanx> parameter in the PIDF-LO SHOULD be adjusted to reflect the method used.
</t>
<t>Location-related measurement data provides an attack vector for malicious Devices. If it is in the interest of the Device to induce the LIS to provide false information about its location, measurement data can be indirectly used to influence the result that the LIS provides. This is particularly important where the LIS provides certitude on the location information, either through digital signature or simply by serving a location reference.
</t>
<t>To prevent the propagation of indirectly falsified location information, the LIS SHOULD validate location-related measurements. The amount of verification might depend on the expected use of that data. Any measurement data that is determined to be suspect is discarded.
</t>
<t>In one potential solution, the LIS validates any location information that is derived from Device-provided measurement data. The resulting location information is compared against location information that the LIS is able to generate independently. If the two results differ significantly, the measurement data is regarded as suspect and the results derived from that are discarded. The allowable degree of difference is left to local configuration or implementation.
</t>
<t>Even with validation, falsified measurement data might be below a threshold where independent checks performed by the LIS do not reveal differences. For instance, LIS might only be able to determine that the Device is within a certain suburb independently. A falsified measurement might be provided such that the resulting location information is on the northern part of the suburb, when the Device is truly in the southern part. The independent validation of the LIS might not be able to detect this attack. However, in using independent validation, the LIS has limited the distance over which the malicious Device is able to move the result by falsifying measurement data.
</t>
<t>Whether measurement data is accepted and what validation are required is a matter for local policy. For instance, different degrees of trust can be assigned to location-related measurement data based on the source of the data. Unauthenticated Devices might be subjected to rigorous checking before being accepted, if the data is accepted at all. Conversely, measurement data from trusted intermediaries might not be subjected to validation at all.
</t>
<t>If absolute certitude of the resulting location information is required, then the LIS MUST NOT use unverified information. In this case, Device-provided measurement data is only of benefit if validation of measurement data is more efficient than collection.
</t>
<t>Given that the output of location determination is probabilistic, it could be that accepting a finite probability of falsified measurement data is acceptable. A decision on how much risk is accepted is left to local policy.
<list style="empty">
<t><xref target="I-D.thomson-geopriv-uncertainty">Confidence</xref> is a measure of the probability that location information is correct. <xref target="RFC5491"/> defines the confidence in PIDF-LO to be 95%. A confidence of 95% allows for 5% of PIDF-LO documents to be incorrect. Of course, it is understood that this 5% are statistical outliers that are still relatively close to the correct location. However, this 5% also allows for fallibility and other errors, such as inadvertent mistakes arising from human error. This might be extended to include an allowance for incorrect measurements, falsified or otherwise.
</t>
</list>
</t>
</section>
</section>
<section title="Location-Related Measurement Data Types">
<t>This document defines location-related measurement data types for a range of common network types.
</t>
<section anchor="common" title="Common Location-Related Measurement Fields">
<t>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.
</t>
<section anchor="time" title="Time of Measurement">
<t>The <spanx style="verb">time</spanx> 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.
</t>
<t>The <spanx style="verb">time</spanx> attribute is optional to avoid forcing an arbitrary choice of timestamp for relatively static types of measurement (for instance, the DSL measurements in <xref target="dsl"/>) and for legacy Devices that don't record time information (such as the Home Location Register/Home Subscriber Server for cellular). However, time SHOULD be provided whenever possible.
</t>
<t>The <spanx style="verb">time</spanx> attribute is attached to the root <spanx style="verb">measurement</spanx> element. If it is necessary to provide multiple sets of measurement data with different times, multiple <spanx style="verb">measurement</spanx> elements SHOULD be provided.
</t>
</section>
<section anchor="expires" title="Expiry Time on Location-Related Measurement Data">
<t>A Device is able to indicate an expiry 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 it can also indicate a time limit on the retention and use of the measurement data. A Device can use this attribute to prevent the LIS from retaining measurement data or limit the time that a LIS retains this information.
<list style="hanging">
<t hangText="Note:">Movement of a Device might result in the measurement data being invalidated before the expiry time.
</t>
</list>
</t>
<t>The LIS MUST NOT keep location-related measurement data 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 only use the location-related measurement data in serving the request that contained the data.
</t>
<t><xref target="ex-expires"/> shows an example of a measurement that includes an expiry attribute.
</t>
<figure anchor="ex-expires" title="Expiry Time Example">
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
</section>
<section title="RMS Error and Number of Samples">
<t>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 at the end of the measurement interval, but additional information about the distribution of the results can be useful in determining location uncertainty.
</t>
<t>Two optional attributes are provided for certain measurement values:
<list style="hanging">
<t hangText="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. If an accurate value for RMS error is not known, this value can be used to indicate an upper bound for the RMS error.
</t>
<t hangText="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, so that the RMS error is an indication of the standard deviation of the sample set.
</t>
</list>
</t>
<t>For some measurement techniques, measurement error is largely dependent on the measurement technique employed. In these cases, measurement error is largely a product of the measurement technique and not the specific circumstances, so RMS error does not need to be actively measured. A fixed value MAY be provided for RMS error where appropriate.
</t>
</section>
<section title="Time RMS Error">
<t>Measurement of time can be significant in certain circumstances. The GNSS measurements included in this document are one such case where a small error in time can result in a large error in location. Factors such as clock drift and errors in time sychronization can result in small, but significant, time errors. Including an indication of the quality of the time can be helpful.
</t>
<t>An optional <spanx style="verb">timeError</spanx> attribute can be added to the <spanx style="verb">measurement</spanx> element to indicate the RMS error in time. <spanx style="verb">timeError</spanx> indicates an upper bound on the time RMS error in seconds.
</t>
<t>The <spanx style="verb">timeError</spanx> attribute does not apply where multiple samples of a measurement is taken over time. If multiple samples are taken, each SHOULD be included in a different <spanx style="verb">measurement</spanx> element.
</t>
</section>
</section>
<section title="LLDP Measurements">
<t>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.
</t>
<t>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.
</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 (hexadecimal c000022d) and the port on that node is numbered using an <xref target="RFC3046">agent circuit ID</xref> of 162 (hexadecimal a2).
</t>
<figure anchor="ex-lldp" title="LLDP Measurement Example">
<artwork><![CDATA[
<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>
]]></artwork>
</figure>
<t>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.
</t>
</section>
<section title="DHCP Relay Agent Information Measurements">
<t>The <xref target="RFC3046">DHCP Relay Agent Information option</xref> provides measurement data about the network attachment of a Device. This measurement data 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: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>
]]></artwork>
</figure>
<t>The <spanx style="verb">giaddr</spanx> is specified as a dotted quad IPv4 address or an <xref target="RFC4291">RFC 4291</xref> IPv6 address. The enterprise number is specified as a decimal integer. All other information is included verbatim from the DHCP request in hexadecimal format.
</t>
</section>
<section title="802.11 WLAN Measurements">
<t>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 <spanx style="verb">wifi</spanx> element, as shown in <xref target="ex-wifi"/>.
</t>
<figure anchor="ex-wifi" title="802.11 WLAN Measurement Example">
<artwork><![CDATA[
<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>Example WiFi Device</nicType>
<servingWap>
<ssid>wlan-home</ssid>
<bssid>00-12-F0-A0-80-EF</bssid>
<channel>7</channel>
<rssi>-55</rssi>
</servingWap>
<neighbourWap>
<ssid>wlan-home</ssid>
<bssid>00-12-F0-A0-80-F0</bssid>
<rssi>-65</rssi>
</neighbourWap>
<neighbourWap>
<ssid>vendordefault</ssid>
<bssid>00-12-F0-A0-80-F1</bssid>
<rssi>-68</rssi>
</neighbourWap>
<neighbourWap>
<ssid>ironicname</ssid>
<bssid>00-12-F0-A0-80-F2</bssid>
<rssi>-75</rssi>
</neighbourWap>
</wifi>
</measurements>
]]></artwork>
</figure>
<t>A wifi element is made up of a serving WAP, zero or more neighbouring WAPs, and an optional <spanx style="verb">nicType</spanx> element. Each WAP element is comprised of the following fields:
<list style="hanging">
<t hangText="ssid:">The service set identifier for the wireless network. This parameter MAY be provided.
</t>
<t hangText="bssid:">The basic service set identifier. In an Infrastructure BSS network, the bssid is the 48 bit MAC address of the wireless access point, and it MUST be provided.
</t>
<t hangText="wapname:">The broadcast name for the wireless access point. This element is optional.
</t>
<t hangText="location:">The location of the wireless access point, as reported using by the wireless access point. This optional element contains GML geometry, following the restrictions described in <xref target="RFC5491"/>.
</t>
<t hangText="type:">The network type for the network access. This element includes the alphabetic suffix of the 802.11 specification that defines the radio interface; e.g. 'a', 'b', 'g', or 'n'. This element is optional.
</t>
<t hangText="channel:">The channel number (frequency) that the wireless access point operates on. This element is optional.
</t>
<t hangText="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 <spanx style="verb">dBm</spanx> attribute MUST be set to <spanx style="verb">false</spanx>. Signal strength reporting on current hardware uses a range of different units; therefore, the value of the <spanx style="verb">nicType</spanx> 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 <spanx style="verb">rmsError</spanx> and <spanx style="verb">samples</spanx> attributes.
</t>
<t hangText="snr:">The signal to noise ratio measured by the Device, in dBm. This element is optional and includes optional <spanx style="verb">rmsError</spanx> and <spanx style="verb">samples</spanx> attributes.
</t>
<t hangText="rtt:">The total round trip time from the time that a request is sent by the device to the time that it receives the response from the access point. This measurement includes any delays that might occur between the time that the access point receives the message and the time that it sends the response. If the delay at an access point is known, this value can be used to calculate an approximate distance between device and access point. This element is optional and includes optional <spanx style="verb">rmsError</spanx> and <spanx style="verb">samples</spanx> attributes.
</t>
</list>
</t>
<t>The <spanx style="verb">nicType</spanx> element is used to specify the make and model of the wireless network interface in the Device. Different 802.11 chipsets report the signal strength in different ways, so the network interface type must be specified in order for the LIS to use signal strength indicators as part of its location determination process. The content of this field is unconstrained and no mechanisms are specified to ensure uniqueness.
</t>
</section>
<section anchor="cellular" title="Cellular Measurements">
<t>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.
</t>
<t>A number of advanced location determination methods have been developed for cellular networks. For these methods a range of measurement parameters can be collected by the network, Device, or both in cooperation. This document includes a basic identifier for the wireless transmitter only; future efforts might define additional parameters that enabled more accurate location information to be determined.
</t>
<t>The cellular measurement set allows a Device to report to a LIS any LTE (<xref target="ex-lte"/>), UMTS (<xref target="ex-umts"/>), GSM (<xref target="ex-gsm"/>) or CDMA (<xref target="ex-cdma"/>) cells that it is able to hear. Cells are reported using their global identifiers. All 3GPP cells are identified by public land mobile network (PLMN), which is formed of mobile country code (MCC) and mobile network code (MNC); specific fields are added for each network type. All other values are decimal integers.
</t>
<figure anchor="ex-lte" title="Example LTE Cellular Measurement">
<artwork><![CDATA[
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<mcc>465</mcc><mnc>20</mnc>
<csg>1234</csg><lcid>65000</lcid>
</servingCell>
<observedCell>
<mcc>465</mcc><mnc>06</mnc>
<gid>16383</gid><cbid>32767</cbid>
</observedCell>
</cellular>
</measurements>
]]></artwork>
<postamble>Long term evolution (LTE) cells are identified by group id (gid) and cell broadcast id (cbid), or by closed subscription group (csg) and local cell id (lcid).
</postamble>
</figure>
<figure anchor="ex-umts" title="Example UMTS Cellular Measurement">
<artwork><![CDATA[
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<mcc>465</mcc><mnc>20</mnc>
<rnc>2000</rnc><cid>65000</cid>
</servingCell>
<observedCell>
<mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</observedCell>
</cellular>
</measurements>
]]></artwork>
<postamble>Universal mobile telephony service (UMTS) cells are identified by radio network controller (rnc) and cell id (cid).
</postamble>
</figure>
<figure anchor="ex-gsm" title="Example GSM Cellular Measurement">
<artwork><![CDATA[
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</servingCell>
</cellular>
</measurements>
]]></artwork>
<postamble>Groupe Spe'ciale Mobile (GSM) cells are identified by local radio network controller (rnc) and cell id (cid).
</postamble>
</figure>
<figure anchor="ex-cdma" title="Example CDMA Cellular Measurement">
<artwork><![CDATA[
<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>
<nid>4723</nid><sid>15892</sid><baseid>12</baseid>
</servingCell>
<observedCell>
<nid>4723</nid><sid>15892</sid><baseid>13</baseid>
</observedCell>
</cellular>
</measurements>
]]></artwork>
<postamble>Code division multiple access (CDMA) cells are not identified by PLMN, instead these use network id (nid), system id (sid) and base station id (baseid).
</postamble>
</figure>
<t>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 <xref target="ex-obs-only"/>.
</t>
<figure anchor="ex-obs-only" title="Example Observed Cellular Measurement">
<artwork><![CDATA[
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<observedCell>
<mcc>465</mcc><mnc>20</mnc>
<rnc>2000</rnc><cid>65000</cid>
</observedCell>
<observedCell>
<mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</observedCell>
</cellular>
</measurements>
]]></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. The results of 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 measurement data for a minimum of 5 satellites. At this stage, measurement data 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 data 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 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.
</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 of GNSS measurement data. The measurement shown is for the GPS system and includes measurement data for three satellites only.
</t>
<figure anchor="ex-agnss" title="Example GNSS Measurement">
<artwork><![CDATA[
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58" timeError="2e-5">
<gnss xmlns="urn:ietf:params:xml:ns:geopriv:lm:gnss"
system="gps" signal="L1">
<sat num="19">
<doppler>499.9395</doppler>
<codephase rmsError="1.6e-9">0.87595747</codephase>
<cn0>45</cn0>
</sat>
<sat num="27">
<doppler>378.2657</doppler>
<codephase rmsError="1.6e-9">0.56639479</codephase>
<cn0>52</cn0>
</sat>
<sat num="20">
<doppler>-633.0309</doppler>
<codephase rmsError="1.6e-9">0.57016835</codephase>
<cn0>48</cn0>
</sat>
</gnss>
</measurements>
]]></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> 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.
</t>
<t>Alternative to (or in addition to) the measurement time, the <spanx style="verb">gnssTime</spanx> element MAY be included. The <spanx style="verb">gnssTime</spanx> element includes a relative time in milliseconds using the time system native to the satellite system. For the GPS satellite system, the <spanx style="verb">gnssTime</spanx> element includes the time of week in milliseconds. For the Galileo system, the <spanx style="verb">gnssTime</spanx> element includes the time of day in milliseconds.
</t>
<t>The accuracy of the time measurement provided is critical in determining the accuracy of the location information derived from GNSS measurements. The receiver SHOULD indicate an estimated time error for any time that is provided. An RMS error can be included for the <spanx style="verb">gnssTime</spanx> element, with a value in milliseconds.
</t>
</section>
<section title="Per-Satellite Measurement Data">
<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 metres 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. This value includes an optional RMS error attribute, also measured in milliseconds.
</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="mp:">An estimation of the amount of error that multipath signals contribute in metres. This 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 parameter is optional.
</t>
<t hangText="adr:">The accumulated Doppler range, measured in metres. This parameter is optional and is not necessary 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 anchor="dsl" 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 data relating to the Device to a LIS operated by the infrastructure provider.
</t>
<section anchor="dsl-l2tp" 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 measurement data 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: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>
]]></artwork>
</figure>
</section>
<section anchor="dsl-radius" title="RADIUS Measurements">
<t>When authenticating network access, the infrastructure provider might employ a <xref target="RFC2865">RADIUS</xref> 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.
</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, analogous 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: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>
]]></artwork>
</figure>
</section>
<section anchor="dsl-enet" 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: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>
]]></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 anchor="dsl-atm" 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: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>
]]></artwork>
</figure>
</section>
</section>
</section>
<section anchor="schema" title="Measurement Schemas">
<t>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 <spanx style="verb">rmsError</spanx> and <spanx style="verb">samples</spanx> attributes IPv4, IPv6 and MAC addresses. Then each of the specific measurement types is defined in its own schema.
</t>
<section anchor="containerSchema" title="Measurement Container Schema">
<figure title="Measurement Containment Schema">
<artwork><![CDATA[
<?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:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<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="timeError" type="bt:positiveDouble"/>
<xs:attribute name="expires" type="xs:dateTime"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:schema>
]]></artwork>
</figure>
</section>
<section anchor="basetypeschema" title="Base Type Schema">
<t>Note that the pattern rules in the following schema wrap due to length constraints. None of the patterns contain whitespace.
</t>
<figure title="Base Type Schema">
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</section>
<section anchor="lldpschema" title="LLDP Measurement Schema">
<figure title="LLDP measurement schema">
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</section>
<section anchor="dhcpschema" title="DHCP Measurement Schema">
<figure title="DHCP measurement schema">
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</section>
<section anchor="wifischema" title="WiFi Measurement Schema">
<figure title="WiFi measurement schema">
<artwork><![CDATA[
<?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:gml="http://www.opengis.net/gml"
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:import namespace="http://www.opengis.net/gml"/>
<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"
minOccurs="0"/>
<xs:element name="bssid" type="bt:macAddressType"/>
<xs:element name="wapname" type="wifi:ssidBaseType"
minOccurs="0"/>
<xs:element name="location" minOccurs="0"
type="gml:GeometryPropertyType"/>
<xs:element name="type" type="wifi:networkType"
minOccurs="0"/>
<xs:element name="channel" type="xs:nonNegativeInteger"
minOccurs="0"/>
<xs:element name="rssi" type="wifi:rssiType"
minOccurs="0"/>
<xs:element name="snr" type="bt:doubleWithRMSError"
minOccurs="0"/>
<xs:element name="rtt" type="bt:doubleWithRMSError"
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:simpleType name="networkType">
<xs:restriction base="xs:token">
<xs:pattern value="[a-zA-Z]+"/>
</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>
]]></artwork>
</figure>
</section>
<section anchor="cellularschema" title="Cellular Measurement Schema">
<figure title="Cellular measurement schema">
<artwork><![CDATA[
<?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:sequence>
<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:sequence>
<xs:element name="gid" type="cell:cellIdType"/>
<xs:element name="cbid" type="cell:cellIdType"/>
</xs:sequence>
<xs:sequence>
<xs:element name="csg" type="cell:cellIdType"/>
<xs:element name="lcid" type="cell:cellIdType"/>
</xs:sequence>
</xs:choice>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:sequence>
<xs:element name="nid" type="cell:cellIdType"/>
<xs:element name="sid" type="cell:cellIdType"/>
<xs:element name="baseid" type="cell:cellIdType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</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="134217728"/> <!-- 2^27 (csg) -->
</xs:restriction>
</xs:simpleType>
</xs:schema>
]]></artwork>
</figure>
</section>
<section anchor="gnssschema" title="GNSS Measurement Schema">
<figure title="GNSS measurement Schema">
<artwork><![CDATA[
<?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"/>
<!-- GNSS -->
<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:nnDoubleWithRMSError"
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: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>
]]></artwork>
</figure>
</section>
<section anchor="dslschema" title="DSL Measurement Schema">
<figure title="DSL measurement schema">
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>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.
</t>
<t>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.
</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>
-->
<t>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 <xref target="expires"/>.
</t>
<t>Use of measurement data provides an opportunity for a malicious Device to include falsified information in the hopes of causing the LIS to provide a fake, or spoofed, location. If any degree of certitude is assigned to the location provided by the LIS—above that assigned to location provided by the device—the LIS SHOULD verify that the measurement data is correct. <xref target="using"/> discusses the risks and limitations involved in the use of measurement data.
</t>
</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 one or more stable, public specifications that outline usage of the GNSS, including (but not limited to) signal specifications and time systems
</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:geopriv:lm">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:lm</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv: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>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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:basetypes">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:lm:basetypes</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes</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>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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:lldp">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:lm:lldp</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:lm:lldp</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>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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:dhcp">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:lm:dhcp</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp</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>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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:wifi">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:lm:wifi</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:lm:wifi</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>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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:cell">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:lm:cell</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:lm:cell</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>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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:gnss">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:lm:gnss</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:lm:gnss</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>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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:dsl">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:lm:dsl</spanx>, as per the guidelines in <xref target="RFC3688"/>.
<list style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:lm:dsl</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>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
]]></artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="XML Schema Registration for Measurement Container 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: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="containerSchema"/> of this document.
</t>
</list>
</t>
</section>
<section title="XML Schema Registration for Base Types 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:lm:basetypes</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="basetypeschema"/> of this document.
</t>
</list>
</t>
</section>
<section title="XML Schema Registration for LLDP 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:lm:lldp</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="lldpschema"/> of this document.
</t>
</list>
</t>
</section>
<section title="XML Schema Registration for DHCP 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:lm:dhcp</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="dhcpschema"/> of this document.
</t>
</list>
</t>
</section>
<section title="XML Schema Registration for WiFi 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:lm:wifi</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="wifischema"/> of this document.
</t>
</list>
</t>
</section>
<section title="XML Schema Registration for Cellular 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:lm:cellular</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="cellularschema"/> of this document.
</t>
</list>
</t>
</section>
<section title="XML Schema Registration for GNSS 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:lm:gnss</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="gnssschema"/> of this document.
</t>
</list>
</t>
</section>
<section title="XML Schema Registration for DSL 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:lm:dsl</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="dslschema"/> of this document.
</t>
</list>
</t>
</section>
</section>
<section title="Acknowledgements">
<t>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 Neil Harper for his review and comments on the GNSS sections of this document. Thanks to Noor-E-Gagan Singh and Gabor Bajko for independent suggestions for improving the parameters associated with 802.11 measurements.
</t>
</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;
&RFC5491;
&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;
&RFC4291;
&I-D.thomson-geopriv-uncertainty;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:05:30 |