| GEOPRIV | M. Thomson |
| Internet-Draft | Microsoft |
| Intended status: Standards Track | J. Winterbottom |
| Expires: December 31, 2012 | Commscope |
| July 2012 |
Using Device-provided Location-Related Measurements in Location Configuration Protocols
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
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.
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.
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.
This document describes a means for a Device to report location-related measurement data to the LIS. Examples based on the HELD [RFC5985] location configuration protocol are provided.
The terms LIS and Device are used in this document in a manner consistent with the usage in [RFC5985].
This document also uses the following definitions:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
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.
The simplest example of measurement data conveyance is illustrated by the example message in Figure 1. This shows a HELD location request message with an Ethernet switch and port measurement taken using LLDP [IEEE.8021AB].
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">civic</locationType>
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
<chassis type="4">0a01003c</chassis>
<port type="6">c2</port>
</lldp>
</measurements>
</locationRequest>
Measurement data that the LIS does not support or understand can be ignored. 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.
Multiple sets of measurement data, either of the same type or from different sources can be included in the measurements element. See Section 4.1.1 for details on repetition of this element.
Use of location-related measurement data is at the discretion of the LIS, but the method parameter in the PIDF-LO SHOULD be adjusted to reflect the method used.
Location-related measurement data need not be provided exclusively by Devices. A third party location requester can request location information using measurement data, if they are able and authorized. There are privacy considerations relating to the use of measurements by third parties, which are discussed in Section 6.4.
Location-related measurement data and its use presents a number of security challenges. These are described in more detail in Section 7.
A common container is defined for the expression of location measurement data, as well as a simple means of identifying specific types of measurement data for the purposes of requesting them.
The following example shows a measurement container with measurement time and expiration time included. A WiFi measurement is enclosed.
<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">
<ap serving="true">
<bssid>00-12-F0-A0-80-EF</bssid>
<ssid>wlan-home</ssid>
</ap>
</wifi>
</lm:measurements>
The measurement element is used to encapsulate measurement data that is collected at a certain point in time. It contains time-based attributes that are common to all forms of measurement data, and permits the inclusion of arbitrary measurement data.
This container can be added to any request for location information, such as a HELD location request [RFC5985].
The time attribute records the time that the measurement or observation was made. This time can be different to the time that the measurement information was reported. Time information can be used to populate a timestamp on the location result, or to determine if the measurement information is used.
The time attribute is optional to avoid forcing an arbitrary choice of timestamp for relatively static types of measurement (for instance, the DSL measurements in Section 5.6) 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.
The time attribute is attached to the root measurement element. If it is necessary to provide multiple sets of measurement data with different times, multiple measurement elements SHOULD be provided.
A Device is able to indicate an expiry time in the location measurement using the expires 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.
The LIS MUST NOT keep location-related measurement data beyond the time indicated in the expires attribute.
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.
Reporting each measurement individually can be the most effective method of reporting multiple measurements. This is achieved by providing multiple measurement elements for different times.
The alternative is to aggregate multiple measurements and report a mean value across the set of measurements. Additional information about the distribution of the results can be useful in determining location uncertainty.
Two optional attributes are provided for certain measurement values:
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.
The rmsError and samples elements are added as attributes of specific measurement data types.
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.
An optional timeError attribute can be added to the measurement element to indicate the RMS error in time. timeError indicates an upper bound on the time RMS error in seconds.
The timeError 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 measurement element.
A measurement request is used by a protocol peer to describe a set of measurement data that it desires. A measurementRequest element is defined that can be included in a protocol exchange.
For instance, a LIS can use a measurement request in HELD responses. If the LIS is unable to provide location information, but it believes that a particular measurement type would enable it to provide a location, it can include a measurement request in an error response.
The measurement element of the measurement request identifies the type of measurement that is requested. The type attribute of this element indicates the type of measurement, as identified by an XML qualified name. An optional samples attribute indicates how many samples of the identified measurement are requested.
The measurement element can be repeated to request multiple (or alternative) measurement types.
Additional XML content might be defined for a particular measurement type that is used to further refine a request. These elements either constrain what is requested or specify optional components of the measurement data that are needed. These are defined along with the specific measurement type.
In the HELD protocol, the inclusion of a measurement request in a error response with a code of locationUnknown indicates that the LIS believes that providing the indicated measurements would increase the likelihood of a subsequent request being successful.
The following example shows a HELD error response that indicates that WiFi measurement data would be useful if a later request were made. Additional elements indicate that received signal strength for an 802.11n access point is requested.
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown">
<message xml:lang="en">Insufficient measurement data</message>
<measurementRequest
xmlns="urn:ietf:params:xml:ns:geopriv:lm"
xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<measurement type="wifi:wifi">
<wifi:type>n</wifi:type>
<wifi:parameter context="ap">wifi:rcpi</wifi:parameter>
</measurement>
</measurementRequest>
</error>
A measurement request that is included in other HELD messages has undefined semantics and can be safely ignored. Other specifications might define semantics for measurement requests under other conditions.
An extension is made to the PIDF-LO [RFC4119] that allows a location recipient to identify the source (or sources) of location information and the measurement data that was used to determine that location information.
The source element is added to the geopriv element of the PIDF-LO. This element does not identify specific entities. Instead, it identifies the type of source.
The following types of measurement source are identified:
No assertion is made about the veracity of the measurement data from sources other than the LIS. A combination of tags MAY be included to indicate that measurement data from both sources was used.
For example, the first tuple of the following PIDF-LO indicates that measurement data from a LIS and a device was combined to produce the result, the second tuple was produced by the LIS alone.
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
entity="pres:lm@example.com">
<tuple id="deviceLoc">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>7.34324 134.47162</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</gp:location-info>
<gp:usage-rules/>
<gp:method>OTDOA</gp:method>
<lmsrc:source>lis device</lmsrc:source>
</gp:geopriv>
</status>
</tuple>
<tuple id="lisLoc">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>7.34379 134.46484</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
9000
</gs:radius>
</gs:Circle>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Cell</gp:method>
<lmsrc:source>lis</lmsrc:source>
</gp:geopriv>
</status>
</tuple>
</presence>
This document defines location-related measurement data types for a range of common network types.
All included measurement data definitions allow for arbitrary extension in the corresponding schema. As new parameters that are applicable to location determination are added, these can be added as new XML elements in a unique namespace. Though many of the underlying protocols support extension, creation of specific XML-based extensions to the measurement format is favored over accomodating protocol-specific extensions in generic containers.
Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] 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.
Values are provided as hexadecimal sequences. The Device MUST report the values directly as they were provided by the adjacent node. Attempting to adjust or translate the type of identifier is likely to cause the measurement data to be useless.
Where a Device has received LLDP messages from multiple adjacent nodes, it should provide information extracted from those messages by repeating the lldp element.
An example of an LLDP measurement is shown in Figure 5. This shows an adjacent node (chassis) that is identified by the IP address 192.0.2.45 (hexadecimal c000022d) and the port on that node is numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
<chassis type="4">c000022d</chassis>
<port type="6">a2</port>
</lldp>
</measurements>
IEEE 802 Devices that are able to obtain information about adjacent network switches and their attachment to them by other means MAY use this data type to convey this information.
The DHCP Relay Agent Information option [RFC3046] provides measurement data about the network attachment of a Device. This measurement data can be included in the dhcp-rai element.
The elements in the DHCP relay agent information options are opaque data types assigned by the DHCP relay agent. The three items are all optional: circuit identifier (circuit, [RFC3046]), remote identifier (remote, [RFC3046], [RFC4649]) and subscriber identifier (subscriber, [RFC3993], [RFC4580]). The DHCPv6 remote identifier has an associated enterprise number [IANA.enterprise] as an XML attribute.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv: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>
The giaddr is specified as a dotted quad IPv4 address or an RFC 4291 [RFC4291] IPv6 address, using the forms defined in [RFC3986]. The enterprise number is specified as a decimal integer. All other information is included verbatim from the DHCP request in hexadecimal format.
In WiFi, or 802.11 [IEEE.80211], networks a Device might be able to provide information about the access point (AP) that it is attached to, or other WiFi points it is able to see. This is provided using the wifi element, as shown in Figure 7, which shows a single complete measurement for a single access point.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2011-04-29T14:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<nicType>Intel(r)PRO/Wireless 2200BG</nicType>
<ap serving="true">
<bssid>AB-CD-EF-AB-CD-EF</bssid>
<ssid>example</ssid>
<channel>5</channel>
<location>
<gml:Point xmlns:gml="http://opengis.net/gml">
<gml:pos>-34.4 150.8</gml:pos>
</gml:Point>
</location>
<type>a</type>
<band>5</band>
<regclass country="AU">2</regclass>
<antenna>2</antenna>
<flightTime rmsError="4e-9" samples="1">2.56e-9</flightTime>
<apSignal>
<transmit>23</transmit>
<gain>5</gain>
<rcpi dBm="true" rmsError="12" samples="1">-59</rcpi>
<rsni rmsError="15" samples="1">23</rsni>
</apSignal>
<deviceSignal>
<transmit>10</transmit>
<gain>9</gain>
<rcpi dBm="true" rmsError="9.5" samples="1">-98.5</rcpi>
<rsni rmsError="6" samples="1">7.5</rsni>
</deviceSignal>
</ap>
</wifi>
</measurements>
A wifi element is made up of one or more access points, and an optional nicType element. Each access point is described using the ap element, which is comprised of the following fields: bssid.
All elements are optional except for
The nicType element is used to specify the make and model of the wireless network interface in the Device. Different 802.11 chipsets report measurements in different ways, so knowing the network interface type aids the LIS in determining how to use the provided measurement data. The content of this field is unconstrained and no mechanisms are specified to ensure uniqueness.
Two elements are defined for requesting WiFi measurements in a measurement request:
Multiple types or parameters can be requested by repeating either element.
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.
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 enable more accurate methods of location determination.
The cellular measurement set allows a Device to report to a LIS any LTE (Figure 8), UMTS (Figure 9), GSM (Figure 10) or CDMA (Figure 11) cells that it is able to observe. 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.
Formats for 3GPP cell identifiers are described in [TS.3GPP.23.003]. Bit-level formats for CDMA cell identifiers are described in [TIA-2000.5]; decimal representations are used.
MCC and MNC are provided as digit sequences; a leading zero in an MCC or MNC is significant. All other values are decimal integers.
<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><eucid>80936424</eucid>
</servingCell>
<observedCell>
<mcc>465</mcc><mnc>06</mnc><eucid>10736789</eucid>
</observedCell>
</cellular>
</measurements>
Long term evolution (LTE) cells are identified by a 28-bit cell identifier (eucid).
<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>
Universal mobile telephony service (UMTS) cells are identified by 12- or 16-bit radio network controller (rnc) id and a 16-bit cell id (cid).
<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>
Global System for Mobile communication (GSM) cells are identified by a 16-bit location area code (lac) and 16-bit cell id (cid).
<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>
<sid>15892</sid><nid>4723</nid><baseid>12</baseid>
</servingCell>
<observedCell>
<sid>15892</sid><nid>4723</nid><baseid>13</baseid>
</observedCell>
</cellular>
</measurements>
Code division multiple access (CDMA) cells are not identified by PLMN, instead these usea 15-bit system id (sid), a 16-bit network id (nid) and a 16-bit base station id (baseid).
In general a cellular Device will be attached to the cellular network and so the notion of a serving cell exists. Cellular network also provide overlap between neighbouring sites, so a mobile Device can hear more than one cell. The measurement schema supports sending both the serving cell and any other cells that the mobile might be able to hear. In some cases, the Device may simply be listening to cell information without actually attaching to the network, mobiles without a SIM are an example of this. In this case the Device may simply report cells it can hear without flagging one as a serving cell. An example of this is shown in Figure 12.
<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>
Two elements can be used in measurement requests for cellular measurements:
Multiple identifier types or networks can be identified by repeating either element.
GNSS use orbiting satellites to transmit signals. A Device with a GNSS receiver is able to take measurements from the satellite signals. The results of these measurements can be used to determine time and the location of the Device.
Determining location and time in autonomous GNSS receivers follows three steps:
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.
Figure 13 shows an example of GNSS measurement data. The measurement shown is for the GPS system and includes measurement data for three satellites only.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58" 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>
Each gnss element represents a single set of GNSS measurement data, taken at a single point in time. Measurements taken at different times can be included in different gnss elements to enable iterative refinement of results.
GNSS measurement parameters are described in more detail in the following sections.
The GNSS measurement structure is designed to be generic and to apply to different GNSS types. Different signals within those systems are also accounted for and can be measured separately.
The GNSS type determines the time system that is used. An indication of the type of system and signal can ensure that the LIS is able to correctly use measurements.
Measurements for multiple GNSS types and signals can be included by repeating the gnss element.
This document creates an IANA registry for GNSS types. Two satellite systems are registered by this document: GPS [GPS.ICD] and Galileo [Galileo.ICD]. Details for the registry are included in Section 9.1.
Each set of GNSS measurements is taken at a specific point in time. The time attribute is used to indicate the time that the measurement was acquired, if the receiver knows how the time system used by the GNSS relates to UTC time.
Alternative to (or in addition to) the measurement time, the gnssTime element MAY be included. The gnssTime element includes a relative time in milliseconds using the time system native to the satellite system. For the GPS satellite system, the gnssTime element includes the time of week in milliseconds. For the Galileo system, the gnssTime element includes the time of day in milliseconds.
The 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 gnssTime element, with a value in milliseconds.
Multiple satellites are included in each set of GNSS measurements using the sat element. Each satellite is identified by a number in the num attribute. The satellite number is consistent with the identifier used in the given GNSS.
Both the GPS and Galileo systems use satellite numbers between 1 and 64.
The GNSS receiver measures the following parameters for each satellite:
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.
Measurement requests can include a gnss element, which includes the system and signal attributes. Multiple elements can be included to indicate a requests for GNSS measurements from multiple systems or signals.
Digital Subscriber Line (DSL) networks rely on a range of network technologies. DSL deployments regularly require cooperation between multiple organizations. These fall into two broad categories: infrastructure providers and Internet service providers (ISPs). For the same end user, an infrastructure and Internet service can be provided by different entities. Infrastructure providers manage the bulk of the physical infrastructure including cabling. End users obtain their service from an ISP, which manages all aspects visible to the end user including IP address allocation and operation of a LIS. See [DSL.TR025] and [DSL.TR101] for further information on DSL network deployments and the parameters that are available.
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, since the infrastructure provider could have 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.
Layer 2 Tunneling Protocol (L2TP) is a common means of linking the infrastructure provider and the ISP. The infrastructure provider LIS requires measurement data that identifies a single L2TP tunnel, from which it can generate location information. Figure 14 shows an example L2TP measurement.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<l2tp>
<src>192.0.2.10</src>
<dest>192.0.2.61</dest>
<session>528</session>
</l2tp>
</dsl>
</measurements>
When authenticating network access, the infrastructure provider might employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or Access Node (AN). These messages provide the ISP RADIUS server with an identifier for the DSLAM or AN, plus the slot and port that the Device is attached on. These data can be provided as a measurement, which allows the infrastructure provider LIS to generate location information.
The format of the AN, slot and port identifiers are not defined in the RADIUS protocol. Slot and port together identify a circuit on the AN, analogous to the circuit identifier in [RFC3046]. These items are provided directly, as they were in the RADIUS message. An example is shown in Figure 15.
<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>
For Ethernet-based DSL access networks, the DSL Access Module (DSLAM) or Access Node (AN) provide two VLAN tags on packets. A C-TAG is used to identify the incoming residential circuit, while the S-TAG is used to identify the DSLAM or AN. The C-TAG and S-TAG together can be used to identify a single point of network attachment. An example is shown in Figure 16.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<stag>613</stag>
<ctag>1097</ctag>
</dsl>
</measurements>
Alternatively, the C-TAG can be replaced by data on the slot and port that the Device is attached to. This information might be included in RADIUS requests that are proxied from the infrastructure provider to the ISP RADIUS server.
An ATM virtual circuit can be employed between the ISP and infrastructure provider. Providing the virtual port ID (VPI) and virtual circuit ID (VCI) for the virtual circuit gives the infrastructure provider LIS the ability to identify a single data stream. A sample measurement is shown in Figure 17.
<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>
Location-related measurement data can be as privacy sensitive as location information.
Measurement data is effectively equivalent to location information if the contextual knowledge necessary to generate one from the other is readily accessible. Even where contextual knowledge is difficult to acquire, there can be no assurance that an authorized recipient of the contextual knowledge is also authorized to receive location information.
In order to protect the privacy of the subject of location-related measurement data, this implies that measurement data is protected with the same degree of protection as location information.
It is less desirable to distribute measurement data in the same fashion as location information. Measurement data is less useful to location recipients than location information. Therefore, a simple distribution model is desirable.
In this simple model, the Device is the only entity that is able to distribute measurement data. To use an analogy from the GEOPRIV architecture, the Device - as the Location Generator (or the Measurement Data Generator) - is the sole entity that can assume the roles of Rule Maker and Location Server.
No entity is permitted to redistribute measurement data. The Device directs other entities in how measurement data is used and retained.
A LIS MUST NOT reveal location-related measurement data or location information based on measurement data to any other entity unless directed to do so by the Device.
By adding measurement data to a request for location information, the Device implicitly grants permission for the LIS to generate the requested location information using the measurement data. Permission to use this data for any other purpose is not implied.
As long as measurement data is only used in serving the request that contains it, rules regarding data retention are not necessary. A LIS MUST discard location-related measurement data after servicing a request, unless the Device grants permission to use that information for other purposes.
A LIS MAY use measurement data provided by the Device to serve requests to location URIs, if the Device permits it. A Device permits this by including measurement data in a request that explcitly requests a location URI. By requesting a location URI, the Device grants permission for the LIS to use the measurement data in serving requests to that URI.
The usefulness of measurement data that is provided in this fashion is limited. The measurement data is only valid at the time that it was acquired by the Device. At the time that a request is made to a location URI, the Device might have moved, rendering the measurement data incorrect.
A Device is able to explicitly limit the time that a LIS retains measurement data by adding an expiry time to the measurement data, see Section 4.1.2.
An authorized third-party request for the location of a Device (see [I-D.ietf-geopriv-held-identity-extensions]) can include location-related measurement data. This is possible where the third-party is able to make observations about the Device.
A third-party that provides measurement data MUST be authorized to provide the specific measurement for the identified device. A third-party MUST either be trusted by the LIS for the purposes of providing measurement data of the provided type, or the measurement data MUST be validated (see Section 7.2.1) before being used.
How a third-party authenticates its identity or gains authorization to use measurement data is not covered by this document.
Use of location-related measurement data has privacy considerations that are discussed in Section 6.
The threat model for location-related measurement data concentrates on the Device providing falsified, stolen or incorrect measurement data.
A Device that provides location location-related measurement data might use data to:
Location-related measurement data describes the physical environment or network attachment of a Device. A third party adversary in the proximity of the Device might be able to alter the physical environment such that the Device provides measurement data that is controlled by the third party. This might be used to indirectly control the location information that is derived from measurement data.
Requiring authorization for location requests is an important part of privacy protections of a location protocol. A location configuration protocol usually operates under a restricted policy that allows a requester to obtain their own location. HELD identity extensions [I-D.ietf-geopriv-held-identity-extensions] allows other entities to be authorized, conditional on a Rule Maker providing sufficient authorization.
The intent of these protections is to ensure that a location recipient is authorized to acquire location information. Location-related measurement data could be used by an attacker to circumvent such authorization checks if the association between measurement data and Target Device is not validated by a LIS.
A LIS can be coerced into providing location information for a Device that a location recipient is not authorized to receive. A request identifies one Device (implicitly or explicitly), but measurement data is provided for another Device. If the LIS does not check that the measurement data is for the identified Device, it could incorrectly authorize the request.
By using unvalidated measurement data to generate a response, the LIS provides information about a Device without appropriate authorization.
The feasibility of this attack depends on the availability of information that links a Device with measurement data. In some cases, measurement data that is correlated with a target is readily available. For instance, LLDP measurements [lldp] are broadcast to all nodes on the same network segment. An attacker on that network segment can easily gain measurement data that relates a Device with measurements.
For some types of measurement data, it's necessary for an attacker to know the location of the target in order to determine what measurements to use. This attack is meaningless for types of measurement data that require that the attacker first know the location of the target before measurement data can be acquired or fabricated. GNSS measurements [gnss] share this trait with many wireless location determination methods.
Allowing requests with measurements might be used to collect information about a network topology. This is possible if requests containing measurements are permitted.
Network topology can be considered sensitive information by a network operator for commercial or security reasons. While it is impossible to completely prevent a Device from acquiring some knowledge of network topology if a location service is provided, a network operator might desire to limit how much of this information is made available.
Mapping a network topology does not require that an attacker be able to associate measurement data with a particular Device. If a requester is able to try a number of measurements, it is possible to acquire information about network topology.
It is not even necessary that the measurements are valid; random guesses are sufficient, provided that there is no penalty or cost associated with attempting to use the measurements.
Location information is a function of its inputs, which includes measurement data. Thus, falsified measurement data can be used to alter the location information that is provided by a LIS.
Some types of measurement data are relatively easy to falsify in a way that the resulting location information to be selected with little or no error. For instance, GNSS measurements are easy to use for this purpose because all the contextual information necessary to calculate a position using measurements is broadcast by the satellites [HARPER].
An attacker that falsifies measurement data gains little if they are the only recipients of the result. The attacker knows that the location information is bad. The attacker only gains if the information can somehow be attributed to the LIS by another location recipient.
A recipient might evaluate the trustworthiness of the location information based on the credibility of its source. By coercing the LIS into providing falsified location information, any credibility that the LIS might have - that the attacker does not - is gained by the attacker.
A third-party that is reliant on the integrity of the location information might base an evaluation of the credibility of the information on the source of the information. If that third party is able to attribute location information to the LIS, then an attacker might gain.
Location information that is provided to the Device without any means to identify the LIS as its source is not subject to this attack. The Device is identified as the source of the data when it distributes the location information to location recipients.
An attacker gains if they are able to coerce the LIS into providing location information based on falsified measurement data and that information can be attributed to the LIS.
Location information is attributed to the LIS either through the use of digital signatures or by having the location recipient directly interact with the LIS. A LIS that digitally signs location information becomes identifiable as the source of the data. Similarly, the LIS is identified as a source of data if a location recipient acquires information directly from a LIS using a location URI.
The value of some measured properties do not change over time for a single location. This allows for simple replay attacks, where an attacker acquires measurements that can later be used without being detected as being invalid.
Measurement data is frequently an observation of an time-invariant property of the environment at the subject location. For measurements of this nature, nothing in the measurement itself is sufficient proof that the Device is present at the resulting location. Measurement data might have been previously acquired and reused.
For instance, the identity of a radio transmitter, if broadcast by that transmitter, can be collected and stored. An attacker that wishes it known that they exist at a particular location, can claim to observe this transmitter at any time. Nothing inherent in the claim reveals it to be false.
For properties of a network, time-invariance is often directly as a result of the practicalities of operating the network. Limiting the changes to a network ensures greater consistency of service. A largely static network also greatly simplifies the data management tasks involved with providing a location service.
Some types of measurement data can be altered or influenced by a third party so that a Device. If it is possible for a third party to alter the measured phenomenon, then any location information that is derived from this data can be indirectly influenced.
Altering the environment in this fashion might not require involvement with either Device or LIS. Measurement that is passive - where the Device observes a signal or other phenomenon without direct interaction - are most susceptible to alteration by third parties.
Measurement of radio signal characteristics is especially vulnerable since an adversary need only be in the general vicinity of the Device and be able to transmit a signal. For instance, a GNSS spoofer is able to produce fake signals that claim to be transmitted by any satellite or set of satellites (see [GPS.SPOOF]).
Measurements that require direct interaction increases the complexity of the attack. For measurements relating to the communication medium, a third party cannot avoid direct interaction, they need only be on the comminications path (that is, man in the middle).
Even if the entity that is interacted with is authenticated, this does not provide any assurance about the integrity of measurement data. For instance, the Device might authenticate the identity of a radio transmitter through the use of cryptographic means and obtain signal strength measurements for that transmitter. Radio signal strength is trivial for an attacker to increase simply by receiving and amplifying the raw signal; it is not necessary for the attacker to be able to understand the signal content.
Attacks that rely on altering the observed environment of a Device require countermeasures that affect the measurement process. For radio signals, countermeasures could include the use of authenticated signals, altered receiver design. In general, countermeasures are highly specific to the individual measurement process. An exhaustive discussion of these issues is left to the relevant literature for each measurement technology.
A Device that provides measurement data is assumed to be responsible for applying appropriate countermeasures against this type of attack.
For a Device that is the ultimate recipient of location information derived from measurement data, a LIS might choose to provide location information without any validation. The responsibility for ensuring the veracity of the measurement data lies with the Device.
Measurement data that is susceptible to this sort of influence MUST be treated as though it were produced by an untrusted Device for those cases where a location recipient might attribute the location information to the LIS. Such measurement data MUST be subjected to the same validation as for other types of attacks that rely on measurement falsification.
The following measures can be applied to limit or prevent attacks. The effectiveness of each depends on the type of measurement data and how that measurement data is acquired.
Two general approaches are identified for dealing with untrusted measurement data: Section 7.2.1, Section 7.2.2, and Section 7.2.3. The impact of attributing location information to sources is discussed in more detail in Section 7.2.4.
This section goes into more detail on the different forms of validation in
Detecting that measurement data has been falsified is difficult in the absence of integrity mechanisms.
Independent confirmation of the veracity of measurement data ensures that the measurement is accurate and that it applies to the correct Device. By gathering the same measurement data from a trusted and independent source, the LIS is able to check that the measurement data is correct.
Measurement information might contain no inherent indication that it is falsified. On the contrary, it can be difficult to obtain information that would provide any degree of assurance that the measurement device is physically at any particular location. Measurements that are difficult to verify require other forms of assurance before they can be used.
Measurement validation MUST be used if measurement data for a particular Device can be easily acquired by unauthorized location recipients, as described in Section 7.1.1. This prevents unauthorized access to location information using measurement data.
Validation of measurement data can be significantly more effective than independent acquisition of the same. For instance, a Device in a large Ethernet network could provide a measurement indicating its point of attachment using LLDP measurements. For a LIS, acquiring the same measurement data might require a request to all switches in that network. With the measurement data, validation can target the identified switch with a specific query.
Validation is effective in identifying falsified measurement data [lying], including attacks involving replay of measurement data [replay]. Validation also limits the amount of network topology information [topomap] made available to Devices to that portion of the network topology that they are directly attached.
Measurement validation has no effect if the underlying effect is being spoofed [environment].
A Device is often in a unique position to make a measurement. It alone occupies the point in space-time that the location determination process seeks to determine. The Device becomes a unique observer for a particular property.
The ability of the Device to become a unique observer makes the Device invaluable to the location determination process. As a unique observer, it also makes the claims of a Device difficult to validate and easily to spoof.
As long as no other entity is capable of making the same measurements, there is also no other entity that can independently check that the measurements are correct and applicable to the Device. A LIS might be unable to validate all or part of the measurement data it receives from a unique observer. For instance, a signal strength measurement of the signal from a radio tower cannot be validated directly.
Some portion of the measurement data might still be independently verified, even if all information cannot. In the previous example, the radio tower might be able to provide verification that the Device is present if it is able to observe a radio signal sent by the Device.
If measurement data can only be partially validated, the extent to which it can be validated determines the effectiveness of validation against these attacks.
The advantage of having the Device as a unique observer is that it makes it difficult for an attacker to acquire measurements without the assistance of the Device. Attempts to use measurements to gain unauthorized access to measurement data [unauth] are largely ineffectual against a unique observer.
Location information that is derived from location-related measurement data can also be verified against trusted location information. Rather than validating inputs to the location determination process, suspect locations are identified at the output of the process.
Trusted location information is acquired using sources of measurement data that are trusted. Untrusted location information is acquired using measurement data provided from untrusted sources, which might include the Device. These two locations are compared. If the untrusted location agrees with the trusted location, the untrusted location information is used.
Algorithms for the comparison of location information are not included in this document. However, a simple comparison for agreement might require that the untrusted location be entirely contained within the uncertainty region of the trusted location.
There is little point in using a less accurate, less trusted location. Untrusted location information that has worse accuracy than trusted information can be immediately discarded. There are multiple factors that affect accuracy, uncertainty and currency being the most important. How location information is compared for accuracy is not defined in this document.
Location validation limits the extent to which falsified - or erroneous - measurement data can cause an incorrect location to be reported.
Location validation can be more efficient than validation of inputs, particularly for a unique observer [uniqueobs].
Validating location ensures that the Device is at or near the resulting location. Location validation can be used to limit or prevent all of the attacks identified in this document.
The trusted location that is used for validation is always less accurate than the location that is being checked. The amount by which the untrusted location is more accurate, is the same amount that an attacker can exploit.
For example, a trusted location might indicate a five kilometer radius uncertainty region. An untrusted location that describes a 100 meter uncertainty within the larger region might be accepted as more accurate. An attacker might still falsify measurement data to select any location within the larger uncertainty region. While the 100 meter uncertainty that is reported seems more accurate, a falsified location could be anywhere in the five kilometer region.
Where measurement data might have been falsified, the actual uncertainty is effectively much higher. Local policy might allow differing degrees of trust to location information derived from untrusted measurement data. This might not be a boolean operation with only two possible outcomes: untrusted location information might be used entirely or not at all, or it could be combined with trusted location information with the degree to which each contributes based on a value set in local policy.
Replay attacks using previously acquired measurement data are particularly hard to detect without independent validation. Rather than validate the measurement data directly, supplementary data might be used to validate measurements or the location information derived from those measurements.
These supporting observations could be used to convey information that provides additional assurance that the Device was acquired at a specific time and place. In effect, the Device is requested to provide proof of its presence at the resulting location.
For instance, a Device that measures attributes of a radio signal could also be asked to provide a sample of the measured radio signal. If the LIS is able to observe the same signal, the two observations could be compared. Providing that the signal cannot be predicted in advance by the Device, this could be used to support the claim that the Device is able to receive the signal. Thus, the Device is likely to be within the range that the signal is transmitted. A LIS could use this to attribute a higher level of trust in the associated measurement data or resulting location.
The use of supporting observations is limited by the ability of the LIS to acquire and validate these observations. The advantage of selecting observations independent of measurement data is that observations can be selected based on how readily available the data is for both LIS and Device. The amount and quality of the data can be selected based on the degree of assurance that is desired.
Use of supporting observations is similar to both measurement validation and location validation. All three methods rely on independent validation of one or more properties. Applicability of each method is similar.
Use of supporting observations can be used to limit or prevent all of the attacks identified in this document.
The effectiveness of the validation method depends on the quality of the supporting observation: how hard it is to obtain at a different time or place, how difficult it is to guess and what other costs might be involved in acquiring this data.
In the example of an observed radio signal, requesting a sample of the signal only provides an assurance that the Device is able to receive the signal transmitted by the measured radio transmitter. This only provides some assurance that the Device is within range of the transmitter.
As with location validation, a Device might still be able to provide falsified measurements that could alter the value of the location information as long as the result is within this region.
Requesting additional supporting observations can reduce the size of the region over which location information can be altered by an attacker, or increase trust in the result, but each additional has a cost. Supporting observations contribute little or nothing toward the primary goal of determining the location of the Device. Any costs in acquiring supporting observations are balanced against the degree of integrity desired of the resulting location information.
Lying by proxy [lying] relies on the location recipient being able to attribute location information to a LIS. The effectiveness of this attack is negated if location information is explicitly attributed to a particular source.
This requires an extension to the location object that explicitly identifies the source (or sources) of each item of location information.
Rather than relying on a process that seeks to ensure that location information is accurate, this approach instead provides a location recipient with the information necessary to reach their own conclusion about the trustworthiness of the location information.
Including an authenticated identity for all sources of measurement data is presents a number of technical and operational challenges. It is possible that the LIS has a transient relationship with a Device. A Device is not expected to share authentication information with a LIS. There is no assurance that Device identification is usable by a potential location recipient. Privacy concerns might also prevent the sharing identification information, even if it were available and usable.
Identifying the type of measurement source allows a location recipient to make a decision about the trustworthiness of location information without depending on having authenticated identity information for each source. An element for this purpose is defined in Section 4.4.
When including location information that is based on measurement data from sources that might be untrusted, a LIS SHOULD include alternative location information that is derived from trusted sources of measurement data. Each item of location information can then be labelled with the source of that data.
A location recipient that is able to identify a specific source of measurement data (whether it be LIS or Device) can use this information to attribute location information to either or both entity. The location recipient is then better able to make decisions about trustworthiness based on the source of the data.
A location recipient that does not understand the source element is unable to make this distinction. When constructing a PIDF-LO document, trusted location information MUST be placed in the PIDF-LO so that it is given higher priority to any untrusted location information according to Rule #8 of [RFC5491].
Attribution of information does nothing to address attacks that alter the observed parameters that are used in location determination [environment].
Stateful examination of requests can be used to prevent a Device from attempting to map network topology using requests for location information (Section 7.1.2).
Simply limiting the rate of requests from a single Device reduces the amount of data that a Device can acquire about network topology.
The schema are broken up into their respective functions. There is a base container schema into which all measurements are placed, plus definitions for a measurement request (Section 8.1). A PIDF-LO extension is defined in a separate schema (Section 8.2). There is a basic types schema, that contains various base type definitions for things such as the rmsError and samples attributes IPv4, IPv6 and MAC addresses (Section 8.3). Then each of the specific measurement types is defined in its own schema.
<?xml version="1.0"?>
<xs:schema
xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
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"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv: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:element name="measurementRequest"
type="lm:measurementRequestType"/>
<xs:complexType name="measurementRequestType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="lm:measurement"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="measurement" type="lm:measurementType"/>
<xs:complexType name="measurementType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="type" type="xs:QName" use="required"/>
<xs:attribute name="samples" type="xs:positiveInteger"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- PIDF-LO extension for source -->
<xs:element name="source" type="lm:sourceType"/>
<xs:simpleType name="sourceType">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="lis"/>
<xs:enumeration value="device"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
</xs:schema>
<?xml version="1.0"?>
<xs:schema
xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc">
</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 an extension to PIDF-LO that indicates the
type of source that produced the measurement data used in
generating the associated location information.
</xs:documentation>
</xs:annotation>
<xs:element name="source" type="lmsrc:sourceType"/>
<xs:simpleType name="sourceType">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="lis"/>
<xs:enumeration value="device"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
</xs:schema>
Note that the pattern rules in the following schema wrap due to length constraints. None of the patterns contain whitespace.
<?xml version="1.0"?>
<xs:schema
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:basetypes">
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a set of base type elements.
</xs:documentation>
</xs:annotation>
<xs:simpleType name="byteType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="255"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="twoByteType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="65535"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="nonNegativeDouble">
<xs:restriction base="xs:double">
<xs:minInclusive value="0.0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="positiveDouble">
<xs:restriction base="bt:nonNegativeDouble">
<xs:minExclusive value="0.0"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="doubleWithRMSError">
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:attribute name="rmsError" type="bt:positiveDouble"/>
<xs:attribute name="samples" type="xs:positiveInteger"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="nnDoubleWithRMSError">
<xs:simpleContent>
<xs:restriction base="bt:doubleWithRMSError">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="ipAddressType">
<xs:union memberTypes="bt:IPv6AddressType bt:IPv4AddressType"/>
</xs:simpleType>
<!-- IPv6 format definition -->
<xs:simpleType name="IPv6AddressType">
<xs:annotation>
<xs:documentation>
An IP version 6 address, based on RFC 4291.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:token">
<!-- Fully specified address -->
<xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/>
<!-- Double colon start -->
<xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/>
<!-- Double colon middle -->
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6}
(:[0-9A-Fa-f]{1,4}){1}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
(:[0-9A-Fa-f]{1,4}){1,2}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
(:[0-9A-Fa-f]{1,4}){1,3}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,3}
(:[0-9A-Fa-f]{1,4}){1,4}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
(:[0-9A-Fa-f]{1,4}){1,5}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
(:[0-9A-Fa-f]{1,4}){1,6}"/>
<!-- Double colon end -->
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,7}:"/>
<!-- IPv4-Compatible and IPv4-Mapped Addresses -->
<xs:pattern value="((:(:0{1,4}){0,3}:[fF]{4})|(0{1,4}:
(:0{1,4}){0,2}:[fF]{4})|((0{1,4}:){2}
(:0{1,4})?:[fF]{4})|((0{1,4}:){3}:[fF]{4})
|((0{1,4}:){4}[fF]{4})):(25[0-5]|2[0-4][0-9]|
[0-1]?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]
?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
[0-9]?[0-9])"/>
<!-- The unspecified address -->
<xs:pattern value="::"/>
</xs:restriction>
</xs:simpleType>
<!-- IPv4 format definition -->
<xs:simpleType name="IPv4AddressType">
<xs:restriction base="xs:token">
<xs:pattern value="(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])"/>
</xs:restriction>
</xs:simpleType>
<!-- MAC address (EUI-48) or EUI-64 address -->
<xs:simpleType name="macAddressType">
<xs:restriction base="xs:token">
<xs:pattern
value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
<?xml version="1.0"?>
<xs:schema
xmlns:lldp="urn:ietf:params:xml:ns:geopriv:lm:lldp"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:lldp"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:lldp">
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a set of LLDP location measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:element name="lldp" type="lldp:lldpMeasurementType"/>
<xs:complexType name="lldpMeasurementType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="chassis" type="lldp:lldpDataType"/>
<xs:element name="port" type="lldp:lldpDataType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="lldpDataType">
<xs:simpleContent>
<xs:extension base="lldp:lldpOctetStringType">
<xs:attribute name="type" type="bt:byteType"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="lldpOctetStringType">
<xs:restriction base="xs:hexBinary">
<xs:minLength value="1"/>
<xs:maxLength value="255"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
<?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>
<?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">
802.11 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 802.11 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:element name="ap" type="wifi:wifiType"
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="bssid" type="wifi:bssidType"/>
<xs:element name="ssid" type="wifi:ssidType"
minOccurs="0"/>
<xs:element name="channel" type="xs:nonNegativeInteger"
minOccurs="0"/>
<xs:element name="location" minOccurs="0"
type="xs:anyType"/>
<xs:element name="type" type="wifi:networkType"
minOccurs="0"/>
<xs:element name="regclass" type="wifi:regclassType"
minOccurs="0"/>
<xs:element name="antenna" type="wifi:octetType"
minOccurs="0"/>
<xs:element name="flightTime" minOccurs="0"
type="bt:nnDoubleWithRMSError"/>
<xs:element name="apSignal" type="wifi:signalType"
minOccurs="0"/>
<xs:element name="deviceSignal" type="wifi:signalType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="serving" type="xs:boolean"
default="false"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="bssidType">
<xs:simpleContent>
<xs:extension base="bt:macAddressType">
<xs:attribute name="verified" type="xs:boolean"
default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- Note that this pattern does not prevent multibyte UTF-8
sequences that result in a SSID longer than 32 octets. -->
<xs:simpleType name="ssidType">
<xs:restriction base="xs:token">
<xs:pattern value="(\\[\da-fA-F]{2}|[^\\]){0,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="regclassType">
<xs:simpleContent>
<xs:extension base="wifi:octetType">
<xs:attribute name="country">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="[A-Z]{2}[OIX]?"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="octetType">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="255"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="signalType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="transmit" type="xs:double"
minOccurs="0"/>
<xs:element name="gain" type="xs:double" minOccurs="0"/>
<xs:element name="rcpi" type="wifi:rssiType"
minOccurs="0"/>
<xs:element name="rsni" type="bt:doubleWithRMSError"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<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>
<!-- Measurement Request elements -->
<xs:element name="type" type="wifi:networkType"/>
<xs:element name="parameter" type="wifi:parameterType"/>
<xs:complexType name="parameterType">
<xs:simpleContent>
<xs:extension base="xs:QName">
<xs:attribute name="context" use="optional">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="ap"/>
<xs:enumeration value="device"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
<?xml version="1.0"?>
<xs:schema
xmlns:cell="urn:ietf:params:xml:ns:geopriv:lm:cell"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:cell"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:cell">
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a set of cellular location measurements.
</xs:documentation>
</xs:annotation>
<xs:element name="cellular" type="cell:cellularType"/>
<xs:complexType name="cellularType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:choice>
<xs:element name="servingCell" type="cell:cellType"/>
<xs:element name="observedCell" type="cell:cellType"/>
</xs:choice>
<xs:element name="observedCell" type="cell:cellType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="cellType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:sequence>
<xs:element name="mcc" type="cell:mccType"/>
<xs:element name="mnc" type="cell:mncType"/>
<xs:choice>
<xs: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:element name="eucid" type="cell:cellIdType"/>
</xs:choice>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:sequence>
<xs:element name="sid" type="cell:cellIdType"/>
<xs:element name="nid" 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="268435456"/> <!-- 2^28 (eucid) -->
</xs:restriction>
</xs:simpleType>
<!-- Measurement Request elements -->
<xs:element name="type" type="cell:typeType"/>
<xs:simpleType name="typeType">
<xs:restriction base="xs:token">
<xs:enumeration value="gsm"/>
<xs:enumeration value="umts"/>
<xs:enumeration value="lte"/>
<xs:enumeration value="cdma"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="network" type="cell:networkType"/>
<xs:complexType name="networkType">
<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:sequence>
<xs:element name="nid" type="cell:cellIdType"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
<?xml version="1.0"?>
<xs:schema
xmlns:gnss="urn:ietf:params:xml:ns:geopriv:lm:gnss"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:gnss"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:gnss">
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This schema defines a set of GNSS location measurements
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<!-- 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="bt:doubleWithRMSError"/>
<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>
<?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>
This section creates a registry for GNSS types [gnss] and registers the namespaces and schema defined in Section 8.
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 [RFC5226], this registry operates under "Specification Required" rules. The IESG will appoint an Expert Reviewer who will advise IANA promptly on each request for a new or updated GNSS type.
Each entry in the registry requires the following information:
The registry initially includes two registrations:
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 Source for PIDF-LO</title>
</head>
<body>
<h1>Namespace for Location Measurement Source</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc</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
This section registers a new XML namespace, urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc, as per the guidelines in [RFC3688].
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
This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm, as per the guidelines in [RFC3688].
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
This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:basetypes, as per the guidelines in [RFC3688].
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
This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:lldp, as per the guidelines in [RFC3688].
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
This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:dhcp, as per the guidelines in [RFC3688].
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
This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:wifi, as per the guidelines in [RFC3688].
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
This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:cell, as per the guidelines in [RFC3688].
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
This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:gnss, as per the guidelines in [RFC3688].
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
This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:dsl, as per the guidelines in [RFC3688].
This section registers an XML schema as per the guidelines in [RFC3688].
This section registers an XML schema as per the guidelines in [RFC3688].
This section registers an XML schema as per the guidelines in [RFC3688].
This section registers an XML schema as per the guidelines in [RFC3688].
This section registers an XML schema as per the guidelines in [RFC3688].
This section registers an XML schema as per the guidelines in [RFC3688].
This section registers an XML schema as per the guidelines in [RFC3688].
This section registers an XML schema as per the guidelines in [RFC3688].
This section registers an XML schema as per the guidelines in [RFC3688].
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, Gabor Bajko, Russell Priebe, and Khalid Al-Mufti for their significant input to and suggestions for improving the 802.11 measurements. Thanks to Cullen Jennings for feedback and suggestions. Bernard Aboba provided review and feedback on a range of measurement data definitions. Mary Barnes and Geoff Thompson provided a review and corrections. David Waitzman and John Bressler both noted shortcomings with 802.11 measurements. Keith Drage, Darren Pawson provided expert LTE knowledge.