diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7105.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7105.txt')
| -rw-r--r-- | doc/rfc/rfc7105.txt | 4147 |
1 files changed, 4147 insertions, 0 deletions
diff --git a/doc/rfc/rfc7105.txt b/doc/rfc/rfc7105.txt new file mode 100644 index 0000000..72cf2a5 --- /dev/null +++ b/doc/rfc/rfc7105.txt @@ -0,0 +1,4147 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Thomson +Request for Comments: 7105 Mozilla +Category: Standards Track J. Winterbottom +ISSN: 2070-1721 Unaffiliated + January 2014 + + + Using Device-Provided Location-Related Measurements + in Location Configuration Protocols + +Abstract + + This document describes a protocol for a Device to provide location- + related measurement data to a Location Information Server (LIS) + within a request for location information. Location-related + measurement information provides observations concerning properties + related to the position of a Device; this information could be data + about network attachment or about the physical environment. A LIS is + able to use the location-related measurement data to improve the + accuracy of the location estimate it provides to the Device. 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. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7105. + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 1] + +RFC 7105 Location Measurements January 2014 + + +Copyright Notice + + Copyright (c) 2014 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. + +Table of Contents + + 1. Introduction ....................................................4 + 2. Conventions Used in This Document ...............................5 + 3. Location-Related Measurements in LCPs ...........................6 + 4. Location-Related Measurement Data Types .........................7 + 4.1. Measurement Container ......................................7 + 4.1.1. Time of Measurement .................................8 + 4.1.2. Expiry Time on Location-Related Measurement Data ....8 + 4.2. RMS Error and Number of Samples ............................9 + 4.2.1. Time RMS Error ......................................9 + 4.3. Measurement Request .......................................10 + 4.4. Identifying Location Provenance ...........................11 + 5. Location-Related Measurement Data Types ........................13 + 5.1. LLDP Measurements .........................................13 + 5.2. DHCP Relay Agent Information Measurements .................14 + 5.3. 802.11 WLAN Measurements ..................................15 + 5.3.1. WiFi Measurement Requests ..........................18 + 5.4. Cellular Measurements .....................................18 + 5.4.1. Cellular Measurement Requests ......................22 + 5.5. GNSS Measurements .........................................22 + 5.5.1. GNSS: System Type and Signal .......................23 + 5.5.2. Time ...............................................24 + 5.5.3. Per-Satellite Measurement Data .....................24 + 5.5.4. GNSS Measurement Requests ..........................25 + 5.6. DSL Measurements ..........................................25 + 5.6.1. L2TP Measurements ..................................26 + 5.6.2. RADIUS Measurements ................................26 + 5.6.3. Ethernet VLAN Tag Measurements .....................27 + 5.6.4. ATM Virtual Circuit Measurements ...................28 + + + + + + +Thomson & Winterbottom Standards Track [Page 2] + +RFC 7105 Location Measurements January 2014 + + + 6. Privacy Considerations .........................................28 + 6.1. Measurement Data Privacy Model ............................28 + 6.2. LIS Privacy Requirements ..................................29 + 6.3. Measurement Data and Location URIs ........................29 + 6.4. Measurement Data Provided by a Third Party ................30 + 7. Security Considerations ........................................30 + 7.1. Threat Model ..............................................30 + 7.1.1. Acquiring Location Information without + Authorization ......................................31 + 7.1.2. Extracting Network Topology Data ...................32 + 7.1.3. Exposing Network Topology Data .....................32 + 7.1.4. Lying by Proxy .....................................33 + 7.1.5. Measurement Replay .................................33 + 7.1.6. Environment Spoofing ...............................34 + 7.2. Mitigation ................................................35 + 7.2.1. Measurement Validation .............................36 + 7.2.1.1. Effectiveness .............................36 + 7.2.1.2. Limitations (Unique Observer) .............37 + 7.2.2. Location Validation ................................38 + 7.2.2.1. Effectiveness .............................38 + 7.2.2.2. Limitations ...............................39 + 7.2.3. Supporting Observations ............................39 + 7.2.3.1. Effectiveness .............................40 + 7.2.3.2. Limitations ...............................40 + 7.2.4. Attribution ........................................40 + 7.2.5. Stateful Correlation of Location Requests ..........42 + 7.3. An Unauthorized or Compromised LIS ........................42 + 8. Measurement Schemas ............................................42 + 8.1. Measurement Container Schema ..............................43 + 8.2. Measurement Source Schema .................................45 + 8.3. Base Types Schema .........................................46 + 8.4. LLDP Measurement Schema ...................................49 + 8.5. DHCP Measurement Schema ...................................50 + 8.6. WiFi Measurement Schema ...................................51 + 8.7. Cellular Measurement Schema ...............................55 + 8.8. GNSS Measurement Schema ...................................57 + 8.9. DSL Measurement Schema ....................................59 + 9. IANA Considerations ............................................61 + 9.1. IANA Registry for GNSS Types ..............................61 + 9.2. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc ...............62 + 9.3. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm .........................63 + 9.4. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:basetypes ...............63 + 9.5. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:lldp ....................64 + + + + +Thomson & Winterbottom Standards Track [Page 3] + +RFC 7105 Location Measurements January 2014 + + + 9.6. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:dhcp ....................65 + 9.7. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:wifi ....................65 + 9.8. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:cell ....................66 + 9.9. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:gnss ....................67 + 9.10. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:dsl ....................67 + 9.11. XML Schema Registration for Measurement Source Schema ....68 + 9.12. XML Schema Registration for Measurement Container + Schema ...................................................68 + 9.13. XML Schema Registration for Base Types Schema ............69 + 9.14. XML Schema Registration for LLDP Schema ..................69 + 9.15. XML Schema Registration for DHCP Schema ..................69 + 9.16. XML Schema Registration for WiFi Schema ..................69 + 9.17. XML Schema Registration for Cellular Schema ..............70 + 9.18. XML Schema Registration for GNSS Schema ..................70 + 9.19. XML Schema Registration for DSL Schema ...................70 + 10. Acknowledgements ..............................................70 + 11. References ....................................................71 + 11.1. Normative References .....................................71 + 11.2. Informative References ...................................73 + +1. Introduction + + 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 that is available due to the knowledge + it has about the network and physical environment. + + As a part of the access network, the LIS is able to acquire + measurement results related to Device location from network elements. + The LIS also has access to information about the network topology + that can be used to turn measurement data into location information. + This information can be further 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 terms of time or some + other metric. Providing measurement data gives the LIS more options + in determining location; this could in turn improve the quality of + + + + + +Thomson & Winterbottom Standards Track [Page 4] + +RFC 7105 Location Measurements January 2014 + + + 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 + HTTP-Enabled Location Delivery (HELD) [RFC5985] location + configuration protocol are provided. + +2. Conventions Used in This Document + + 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: + + Location Measurement: An observation about the physical properties + of a particular Device's position in time and space. 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 directly identify a Device, though it + could do so indirectly. Measurement data can change with time if + the location of the Device also changes. + + Location-related measurement data does not necessarily contain + location information directly, but it can be used in combination + with contextual knowledge and/or algorithms to derive location + information. Examples of location-related measurement data are + radio signal strength or timing measurements, Ethernet switch + identifiers, and port identifiers. + + Location-related measurement data can be considered sighting + information, based on the definition in [RFC3693]. + + Location Estimate: An approximation of where the Device is located. + Location estimates are derived from location measurements. + Location estimates are subject to uncertainty, which arises from + errors in measurement results. + + GNSS: Global Navigation Satellite System. A satellite-based system + that provides positioning and time information -- for example, the + US Global Positioning System (GPS) or the European Galileo system. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + +Thomson & Winterbottom Standards Track [Page 5] + +RFC 7105 Location Measurements January 2014 + + +3. Location-Related Measurements in LCPs + + 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. + + A simple 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 the + Link-Layer Discovery Protocol (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> + + Figure 1: HELD Location Request with Measurement Data + + This LIS can ignore measurement data that it does not support or + understand. 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. + + A LIS can choose to use or ignore location-related measurement data + in determining location, as long as rules regarding use and retention + (Section 6) are respected. The "method" parameter in the Presence + Information Data Format - Location Object (PIDF-LO) [RFC4119] SHOULD + be adjusted to reflect the method used. A correct "method" can + assist location recipients in assessing the quality (both accuracy + and integrity) of location information, though there could be reasons + to withhold information about the source of data. + + + + + + +Thomson & Winterbottom Standards Track [Page 6] + +RFC 7105 Location Measurements January 2014 + + + Measurement data is typically only used to serve the request in which + it is included. There may be exceptions, particularly with respect + to location URIs. Section 6 provides more information on usage + rules. + + Location-related measurement data need not be provided exclusively by + Devices. A third-party location requester (for example, see + [RFC6155]) can request location information using measurement data, + if the requester is able to acquire measurement data and authorized + to distribute it. There are specific 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 present a number of + privacy and security challenges. These are described in more detail + in Sections 6 and 7. + +4. Location-Related Measurement Data Types + + 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> + + Figure 2: Measurement Example + +4.1. Measurement Container + + The "measurements" 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 it + permits the inclusion of arbitrary measurement data. The elements + that are included within the "measurements" element are generically + referred to as "measurement elements". + + + + +Thomson & Winterbottom Standards Track [Page 7] + +RFC 7105 Location Measurements January 2014 + + + This container can be added to a request for location information in + any protocol capable of carrying XML, such as a HELD location request + [RFC5985]. + +4.1.1. Time of Measurement + + The "time" attribute records the time that the measurement or + observation was made. This time can be different from 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 SHOULD be provided whenever possible. This + allows a LIS to avoid selecting an arbitrary timestamp. Exceptions + to this, where omitting time might make sense, include relatively + static types of measurement (for instance, the DSL measurements in + Section 5.6) or for legacy Devices that don't record time information + (such as the Home Location Register/Home Subscriber Server for + cellular). + + The "time" attribute is attached to the root "measurement" element. + Multiple measurements can often be given the same timestamp, even + when the measurements were not actually taken at the same time + (consider a set of measurements taken sequentially, where the + difference in time between observations is not significant). + Measurements cannot be grouped if they have different types or if + there is a need for independent time values on each measurement. In + these instances, multiple measurement sets are necessary. + +4.1.2. Expiry Time on Location-Related Measurement Data + + 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, but it can + also indicate a time limit on the retention and use of the + measurement data. A Device can use this attribute to request that + the LIS not retain measurement data beyond the indicated time. + + Note: Movement of the Device might result in the measurement data + being invalidated before the expiry time. + + A Device is advised to set the "expires" attribute to the earlier of + the time that measurements are likely to be unusable and the time + that it desires to have measurements discarded by the LIS. A Device + that does not desire measurement data to be retained can omit the + "expires" attribute. Section 6 describes more specific rules + regarding measurement data retention. + + + + +Thomson & Winterbottom Standards Track [Page 8] + +RFC 7105 Location Measurements January 2014 + + +4.2. RMS Error and Number of Samples + + Often a measurement is taken more than once. 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 attributes are provided for use on some measurement values: + + rmsError: The root-mean-squared (RMS) error of the set of + measurement values used in calculating the result. RMS error is + expressed in the same units as the measurement, unless otherwise + stated. If an accurate value for the RMS error is not known, this + value can be used to indicate an upper bound or estimate for the + RMS error. + + samples: The number of samples that were taken in determining the + measurement value. If omitted, this value can be assumed to be + large enough that the RMS error is an indication of the standard + deviation of the sample set. + + 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 the RMS error does not need to + be actively measured. A fixed value MAY be provided for the RMS + error where appropriate. + + The "rmsError" and "samples" elements are added as attributes of + specific measurement data types. + +4.2.1. Time RMS Error + + 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 synchronization can result in + small, but significant, time errors. Including an indication of the + quality of time measurements can be helpful. + + + + +Thomson & Winterbottom Standards Track [Page 9] + +RFC 7105 Location Measurements January 2014 + + + A "timeError" attribute MAY 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 are taken over time. If multiple samples are taken, each + SHOULD be included in a different "measurement" element. + +4.3. Measurement Request + + 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. A "samples" attribute MAY be used to indicate 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 non-mandatory 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 an + error response with a code of "locationUnknown" indicates that + providing measurements would increase the likelihood of a subsequent + request being successful. + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 10] + +RFC 7105 Location Measurements January 2014 + + + 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> + + Figure 3: HELD Error Requesting Measurement Data + + 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. + +4.4. Identifying Location Provenance + + 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 measurement source. + + The following values are defined for the "source" element: + + lis: Location information is based on measurement data that the LIS + or sources that it trusts have acquired. This label MAY be used + if measurement data provided by the Device has been completely + validated by the LIS. + + device: A LIS MUST include this value if the location information is + based (in whole or in part) on measurement data provided by the + Device and if the measurement data isn't completely validated. + + + + + +Thomson & Winterbottom Standards Track [Page 11] + +RFC 7105 Location Measurements January 2014 + + + other: Location information is based on measurement data that a + third party has provided. This might be an authorized third party + that uses identity parameters [RFC6155] or any other entity. The + LIS MUST include this, unless the third party is trusted by the + LIS to provide measurement data. + + 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 multiple types of 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> + + + +Thomson & Winterbottom Standards Track [Page 12] + +RFC 7105 Location Measurements January 2014 + + + </gp:location-info> + <gp:usage-rules/> + <gp:method>Cell</gp:method> + <lmsrc:source>lis</lmsrc:source> + </gp:geopriv> + </status> + </tuple> + </presence> + + PIDF-LO Document with Source Labels + +5. Location-Related Measurement Data Types + + 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. New parameters that are + applicable to location determination are added as new XML elements in + a unique namespace, not by adding elements to an existing namespace. + +5.1. LLDP Measurements + + 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; the identification information 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. + + Note: The LLDP extensions defined in LLDP Media Endpoint Discovery + (LLDP-MED) [ANSI-TIA-1057] provide the ability to acquire location + information directly from an LLDP endpoint. Where this + information is available, it might be unnecessary to use any other + form of location configuration. + + 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. + + + + + +Thomson & Winterbottom Standards Track [Page 13] + +RFC 7105 Location Measurements January 2014 + + + An example of an LLDP measurement is shown in Figure 4. 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> + + Figure 4: LLDP Measurement Example + + 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. + +5.2. DHCP Relay Agent Information Measurements + + 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 MAY be + omitted if unknown: circuit identifier ("circuit", circuit [RFC3046], + or Interface-Id [RFC3315]), remote identifier ("remote", Remote ID + [RFC3046], or remote-id [RFC4649]), and subscriber identifier + ("subscriber", subscriber-id [RFC3993], or Subscriber-ID [RFC4580]). + The DHCPv6 remote-id 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>192.0.2.158</giaddr> + <circuit>108b</circuit> + </dhcp-rai> + </measurements> + + Figure 5: DHCP Relay Agent Information Measurement Example + + + + + + + + +Thomson & Winterbottom Standards Track [Page 14] + +RFC 7105 Location Measurements January 2014 + + + The "giaddr" element is specified as a dotted quad IPv4 address or an + RFC 4291 [RFC4291] IPv6 address, using the forms defined in + [RFC3986]; IPv6 addresses SHOULD use the form described in [RFC5952]. + The enterprise number is specified as a decimal integer. All other + information is included verbatim from the DHCP request in hexadecimal + format. + + The "subscriber" element could be considered sensitive. This + information MUST NOT be provided to a LIS that is not authorized to + receive information about the access network. See Section 7.1.3 for + more details. + +5.3. 802.11 WLAN Measurements + + In WiFi, or 802.11 [IEEE.80211], networks, a Device might be able to + provide information about the access point (AP) to which it is + attached, or other WiFi points it is able to see. This is provided + using the "wifi" element, as shown in Figure 6, 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> + + + +Thomson & Winterbottom Standards Track [Page 15] + +RFC 7105 Location Measurements January 2014 + + + <rsni rmsError="6" samples="1">7.5</rsni> + </deviceSignal> + </ap> + </wifi> + </measurements> + + Figure 6: 802.11 WLAN Measurement Example + + A "wifi" element is made up of one or more access points, and a + "nicType" element, which MAY be omitted. Each access point is + described using the "ap" element, which is comprised of the following + fields: + + bssid: The Basic Service Set (BSS) identifier. In an Infrastructure + BSS network, the bssid is the 48-bit MAC address of the access + point. + + The "verified" attribute of this element describes whether the + Device has verified the MAC address or it authenticated the access + point or the network operating the access point (for example, a + captive portal accessed through the access point has been + authenticated). This attribute defaults to a value of "false" + when omitted. + + ssid: The service set identifier (SSID) for the wireless network + served by the access point. + + The SSID is a 32-octet identifier that is commonly represented as + an ASCII [ASCII] or UTF-8 [RFC3629] encoded string. To represent + octets that cannot be directly included in an XML element, + escaping is used. Sequences of octets that do not represent a + valid UTF-8 encoding can be escaped using a backslash ('\') + followed by two case-insensitive hexadecimal digits representing + the value of a single octet. + + The canonical or value-space form of an SSID is a sequence of up + to 32 octets that is produced from the concatenation of UTF-8 + encoded sequences of unescaped characters and octets derived from + escaped components. + + channel: The channel number (frequency) on which the access point + operates. + + location: The location of the access point, as reported by the + access point. This element contains any valid location, using the + rules for a "location-info" element, as described in [RFC5491]. + + + + + +Thomson & Winterbottom Standards Track [Page 16] + +RFC 7105 Location Measurements January 2014 + + + type: The network type for the network access. This element + includes the alphabetic suffix of the 802.11 specification that + introduced the radio interface, or PHY, e.g., "a", "b", "g", + or "n". + + band: The frequency band for the radio, in gigahertz (GHz). 802.11 + [IEEE.80211] specifies PHY layers that use 2.4, 3.7, and 5 + gigahertz frequency bands. + + regclass: The operating class (regulatory domain and class in older + versions of 802.11); see Annex E of [IEEE.80211]. The "country" + attribute optionally includes the applicable two-character country + identifier (dot11CountryString), which can be followed by an 'O', + 'I', or 'X'. The element text content includes the value of the + regulatory class: an 8-bit integer in decimal form. + + antenna: The antenna identifier for the antenna that the access + point is using to transmit the measured signals. + + flightTime: Flight time is the difference between the time of + departure (TOD) of signal from a transmitting station and time of + arrival (TOA) of signal at a receiving station, as defined in + [IEEE.80211]. Measurement of this value requires that stations + synchronize their clocks. This value can be measured by an access + point or Device; because the flight time is assumed to be the same + in either direction -- aside from measurement errors -- only a + single element is provided. This element permits the use of the + "rmsError" and "samples" attributes. RMS error might be derived + from the reported RMS error in TOD and TOA. + + apSignal: Measurement information for the signal transmitted by the + access point, as observed by the Device. Some of these values are + derived from 802.11v [IEEE.80211] messages exchanged between the + Device and access point. The contents of this element include: + + transmit: The transmit power reported by the access point, + in dBm. + + gain: The gain of the access point antenna reported by the access + point, in dB. + + rcpi: The received channel power indicator for the access point + signal, as measured by the Device. This value SHOULD be in + units of dBm (with RMS error in dB). If power is measured in a + different fashion, the "dBm" attribute MUST be set to "false". + Signal strength reporting on current hardware uses a range of + different mechanisms; therefore, the value of the "nicType" + element SHOULD be included if the units are not known to be in + + + +Thomson & Winterbottom Standards Track [Page 17] + +RFC 7105 Location Measurements January 2014 + + + dBm, and the value reported by the hardware should be included + without modification. This element permits the use of the + "rmsError" and "samples" attributes. + + rsni: The received signal-to-noise indicator in dB. This element + permits the use of the "rmsError" and "samples" attributes. + + deviceSignal: Measurement information for the signal transmitted by + the Device, as reported by the access point. This element + contains the same child elements as the "ap" element, with the + access point and Device roles reversed. + + The only mandatory element in this structure is "bssid". + + 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. This field is + unlikely to be useful, except under tightly controlled circumstances. + +5.3.1. WiFi Measurement Requests + + Two elements are defined for requesting WiFi measurements in a + measurement request: + + type: The "type" element identifies the desired type (or types that + are requested). + + parameter: The "parameter" element identifies measurements that are + requested for each measured access point. An element is + identified by its qualified name. The "context" parameter can be + used to specify if an element is included as a child of the "ap" + or "device" elements; omission indicates that it applies to both. + + Multiple types or parameters can be requested by repeating either + element. + +5.4. Cellular Measurements + + Cellular Devices are common throughout the world, and base station + identifiers can provide a good source of coarse location information. + Cellular measurements can be provided to a LIS run by the cellular + operator, or may be provided to an alternative LIS operator that has + access to one of several global cell-id to location mapping + databases. + + + + +Thomson & Winterbottom Standards Track [Page 18] + +RFC 7105 Location Measurements January 2014 + + + 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 7), UMTS (Figure 8), GSM (Figure 9), or CDMA (Figure 10) + cells that it is able to observe. Cells are reported using their + global identifiers. All Third Generation Partnership Project (3GPP) + cells are identified by a public land mobile network (PLMN), which + comprises a 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 decimal 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). + + Figure 7: Example LTE Cellular Measurement + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 19] + +RFC 7105 Location Measurements January 2014 + + + <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 a + 12- or 16-bit radio network controller (rnc) id and a 16-bit cell id + (cid). + + Figure 8: Example UMTS Cellular Measurement + + + <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" + time="2008-04-29T14:33:58"> + <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell"> + <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 a 16-bit cell id (cid). + + Figure 9: Example GSM Cellular Measurement + + + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 20] + +RFC 7105 Location Measurements January 2014 + + + <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 a + PLMN; instead, these use a 15-bit system id (sid), a 16-bit network + id (nid), and a 16-bit base station id (baseid). + + Figure 10: Example CDMA Cellular Measurement + + In general, a cellular Device will be attached to the cellular + network, so the notion of a serving cell exists. Cellular networks + also provide overlap between neighboring 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 could 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 could + report cells it can hear without identifying any particular cell as a + serving cell. An example of this is shown in Figure 11. + + <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> + + Figure 11: Example Observed Cellular Measurement + + + + + + + +Thomson & Winterbottom Standards Track [Page 21] + +RFC 7105 Location Measurements January 2014 + + +5.4.1. Cellular Measurement Requests + + Two elements can be used in measurement requests for cellular + measurements: + + type: A label indicating the type of identifier to provide: one of + "gsm", "umts", "lte", or "cdma". + + network: The network portion of the cell identifier. For 3GPP + networks, this is the combination of MCC and MNC; for CDMA, this + is the network identifier. + + Multiple identifier types or networks can be identified by repeating + either element. + +5.5. GNSS Measurements + + A Global Navigation Satellite System (GNSS) uses orbiting satellites + to transmit signals. A Device with a GNSS receiver is able to take + measurements from the satellite signals. The results of these + measurements can be used to determine time and the location of the + Device. + + Determining location and time in autonomous GNSS receivers follows + three steps: + + Signal acquisition: During the signal acquisition stage, the + receiver searches for the repeating code that is sent by each GNSS + satellite. Successful operation typically requires measurement + data for a minimum of 5 satellites. At this stage, measurement + data is available to the Device. + + Navigation message decode: Once the signal has been acquired, the + receiver then receives information about the configuration of the + satellite constellation. This information is broadcast by each + satellite and is modulated with the base signal at a low rate; for + instance, GPS sends this information at about 50 bits per second. + + Calculation: The measurement data is combined with the data on the + satellite constellation to determine the location of the receiver + and the current time. + + A Device that uses a GNSS receiver is able to report measurements + after the first stage of this process. A LIS can use the results of + these measurements to determine a location. In the case where there + are fewer results available than the optimal minimum, the LIS might + be able to use other sources of measurement information and combine + these with the available measurement data to determine a position. + + + +Thomson & Winterbottom Standards Track [Page 22] + +RFC 7105 Location Measurements January 2014 + + + Note: The use of different sets of GNSS assistance data can reduce + the amount of time required for the signal acquisition stage and + obviate the need for the receiver to extract data on the satellite + constellation. Provision of assistance data is outside the scope + of this document. + + Figure 12 shows an example of GNSS measurement data. The measurement + shown is for the GPS satellite 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> + + Figure 12: Example GNSS Measurement + + Each "gnss" element represents a single set of GNSS measurement data, + taken at a single point in time. Measurements taken at different + times can be included in different "gnss" elements to enable + iterative refinement of results. + + GNSS measurement parameters are described in more detail in the + following sections. + +5.5.1. GNSS: System Type and Signal + + The GNSS measurement structure is designed to be generic and to apply + to different GNSS types. Different signals within those systems are + also accounted for and can be measured separately. + + + + +Thomson & Winterbottom Standards Track [Page 23] + +RFC 7105 Location Measurements January 2014 + + + 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. + +5.5.2. Time + + Each set of GNSS measurements is taken at a specific point in time. + The "time" attribute is used to indicate the time that the + measurement was acquired, if the receiver knows how the time system + used by the GNSS relates to UTC time. + + Alternative to (or in addition to) the measurement time, the + "gnssTime" element MAY be included. The "gnssTime" element includes + a relative time in milliseconds using the time system native to the + satellite system. For the GPS satellite system, the "gnssTime" + element includes the time of week in milliseconds. For the Galileo + system, the "gnssTime" element includes the time of day in + milliseconds. + + The 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. + +5.5.3. Per-Satellite Measurement Data + + Multiple satellites are included in each set of GNSS measurements + using the "sat" element. Each satellite is identified by a number in + the "num" attribute. The satellite number is consistent with the + identifier used in the given GNSS. + + Both the GPS and Galileo systems use satellite numbers between 1 + and 64. + + The GNSS receiver measures the following parameters for each + satellite: + + doppler: The observed Doppler shift of the satellite signal, + measured in meters per second. This is converted from a value in + Hertz by the receiver to allow the measurement to be used without + + + +Thomson & Winterbottom Standards Track [Page 24] + +RFC 7105 Location Measurements January 2014 + + + knowledge of the carrier frequency of the satellite system. This + value permits the use of RMS error attributes, also measured in + meters per second. + + codephase: The observed code phase for the satellite signal, + measured in milliseconds. This is converted from the system- + specific value of chips or wavelengths into a system-independent + value. Larger values indicate larger distances from satellite to + receiver. This value permits the use of RMS error attributes, + also measured in milliseconds. + + cn0: The signal-to-noise ratio for the satellite signal, measured in + decibel-Hertz (dB-Hz). The expected range is between 20 and + 50 dB-Hz. + + mp: An estimation of the amount of error that multipath signals + contribute in meters. This parameter MAY be omitted. + + cq: An indication of the carrier quality. Two attributes are + included: "continuous" (which can be either "true" or "false") and + "direct" (which can be either "direct" or "inverted"). This + parameter MAY be omitted. + + adr: The accumulated Doppler range, measured in meters. This + parameter MAY be omitted and is not useful unless multiple sets of + GNSS measurements are provided or differential positioning is + being performed. + + 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. + +5.5.4. GNSS Measurement Requests + + Measurement requests can include a "gnss" element, which includes the + "system" and "signal" attributes. Multiple elements can be included + to indicate requests for GNSS measurements from multiple systems or + signals. + +5.6. DSL Measurements + + 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 + + + +Thomson & Winterbottom Standards Track [Page 25] + +RFC 7105 Location Measurements January 2014 + + + 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. + +5.6.1. L2TP Measurements + + The Layer 2 Tunneling Protocol (L2TP) [RFC2661] 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 13 + 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> + + Figure 13: Example DSL L2TP Measurement + +5.6.2. RADIUS 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 to which + the Device is attached. These data can be provided as a measurement + that allows the infrastructure provider LIS to generate location + information. + + + + + + + +Thomson & Winterbottom Standards Track [Page 26] + +RFC 7105 Location Measurements January 2014 + + + The format of the AN, slot, and port identifiers is not defined in + the RADIUS protocol. The slot and port together identify a circuit + on the AN, analogous to the circuit identifier in [RFC3046]. These + items are provided directly, as they would be in the RADIUS message. + An example is shown in Figure 14. + + <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> + + Figure 14: Example DSL RADIUS Measurement + +5.6.3. Ethernet VLAN Tag Measurements + + For Ethernet-based DSL access networks, the DSLAM or AN provides 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 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"> + <stag>613</stag> + <ctag>1097</ctag> + </dsl> + </measurements> + + Figure 15: Example DSL VLAN Tag Measurement + + Alternatively, the C-TAG can be replaced by data on the slot and port + to which the Device is attached. This information might be included + in RADIUS requests that are proxied from the infrastructure provider + to the ISP RADIUS server. + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 27] + +RFC 7105 Location Measurements January 2014 + + +5.6.4. ATM Virtual Circuit Measurements + + An ATM virtual circuit can be employed between the ISP and + infrastructure provider. Providing the virtual port ID (VPI) and + virtual circuit ID (VCI) for the virtual circuit gives the + infrastructure provider LIS the ability to identify a single data + stream. A sample measurement is shown in Figure 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"> + <vpi>55</vpi> + <vci>6323</vci> + </dsl> + </measurements> + + Figure 16: Example DSL ATM Measurement + +6. Privacy Considerations + + Location-related measurement data can be as privacy sensitive as + location information [RFC6280]. + + 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, measurement data MUST be protected with the same + degree of protection as location information. The confidentiality + and authentication provided by Transport Layer Security (TLS) MUST be + used in order to convey measurement data over HELD [RFC5985]. Other + protocols MUST provide comparable guarantees. + +6.1. Measurement Data Privacy Model + + It is not necessary to distribute measurement data in the same + fashion as location information. Measurement data is less useful to + location recipients than location information. A simple distribution + model is described in this document. + + + + + + + + +Thomson & Winterbottom Standards Track [Page 28] + +RFC 7105 Location Measurements January 2014 + + + 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 act in the + role of both Rule Maker and Location Server. + + A Device that provides location-related measurement data MUST only do + so as explicitly authorized by a Rule Maker. This depends on having + an interface that allows Rule Makers (for instance, users or + administrators) to control where and how measurement data is + provided. + + No entity is permitted to redistribute measurement data. The Device + directs other entities regarding how measurement data is used and + retained. + + The GEOPRIV model [RFC6280] protects the location of a Target using + direction provided by a Rule Maker. For the purposes of measurement + data distribution, this model relies on the assumptions made in + Section 3 of HELD [RFC5985]. These assumptions effectively declare + the Device to be a proxy for both Target and Rule Maker. + +6.2. LIS Privacy Requirements + + A LIS MUST NOT reveal location-related measurement data to any other + entity. A LIS MUST NOT reveal 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. + +6.3. Measurement Data and Location URIs + + 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 + explicitly requests a location URI. By requesting a location URI, + + + + + +Thomson & Winterbottom Standards Track [Page 29] + +RFC 7105 Location Measurements January 2014 + + + the Device grants permission for the LIS to use the measurement data + in serving requests to that location URI. The LIS cannot provide + location recipients with measurement data, as defined in Section 6.1. + + Note: In HELD, the "any" type is not an explicit request for a + location URI, though a location URI might be provided. + + 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. A + LIS MUST NOT retain location-related measurement data in memory, + storage, or logs beyond the time indicated in the "expires" attribute + (Section 4.1.2). A LIS MUST NOT retain measurement data if the + "expires" attribute is absent. + +6.4. Measurement Data Provided by a Third Party + + An authorized third-party request for the location of a Device (see + [RFC6155]) 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. Either a + third party MUST 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. + +7. Security Considerations + + The use of location-related measurement data has privacy + considerations that are discussed in Section 6. + +7.1. Threat Model + + The threat model for location-related measurement data concentrates + on the Device providing falsified, stolen, or incorrect measurement + data. + + + + + +Thomson & Winterbottom Standards Track [Page 30] + +RFC 7105 Location Measurements January 2014 + + + A Device that provides location-related measurement data might use + data to: + + o acquire the location of another Device, without authorization; + + o extract information about network topology; or + + o coerce the LIS into providing falsified location information based + on the measurement data. + + 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. + +7.1.1. Acquiring Location Information without Authorization + + 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 + [RFC6155] allow 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 unverified 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 (Section 5.1) are + + + +Thomson & Winterbottom Standards Track [Page 31] + +RFC 7105 Location Measurements January 2014 + + + 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 (Section 5.5) share this trait with + many wireless location determination methods. + +7.1.2. Extracting Network Topology Data + + Allowing requests with measurements might be used to collect + information about network topology. + + 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. + +7.1.3. Exposing Network Topology Data + + A Device could reveal information about a network to entities outside + of that network if it provides location measurement data to a LIS + that is outside of that network. With the exception of GNSS + measurements, the measurements in this document provide information + about an access network that could reveal topology information to an + unauthorized recipient. + + A Device MUST NOT provide information about network topology without + a clear signal that the recipient is authorized. A LIS that is + discovered using DHCP as described in LIS discovery [RFC5986] can be + considered to be authorized to receive information about the access + network. + + + + +Thomson & Winterbottom Standards Track [Page 32] + +RFC 7105 Location Measurements January 2014 + + +7.1.4. Lying by Proxy + + Location information, which includes measurement data, is a function + of its inputs. 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 causes 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 recipient 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. 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. + + 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. + +7.1.5. Measurement Replay + + The values of some measured properties do not change over time for a + single location. The time invariance of network properties is often + a direct 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. + + + +Thomson & Winterbottom Standards Track [Page 33] + +RFC 7105 Location Measurements January 2014 + + + However, time-invariant properties allow 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 a 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. + +7.1.6. Environment Spoofing + + Some types of measurement data can be altered or influenced by a + third party so that a Device unwittingly provides falsified data. 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 a Device or LIS. Measurement that is passive + -- where the Device observes a signal or other phenomenon without + direct interaction -- is 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 increase 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 communications 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 + + + + +Thomson & Winterbottom Standards Track [Page 34] + +RFC 7105 Location Measurements January 2014 + + + 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. + + Note: This particular "attack" is more often completely + legitimate. Radio repeaters are a commonplace mechanism used to + increase radio coverage. + + 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, or 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. + + Where a Device is the sole 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 SHOULD + 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. GNSS measurements and radio signal strength + measurements can be affected relatively cheaply, though almost all + other measurement types can be affected with varying costs to an + attacker, with the largest cost often being a requirement for + physical access. To the extent that it is feasible, measurement data + SHOULD be subjected to the same validation as for other types of + attacks that rely on measurement falsification. + + Note: Altered measurement data might be provided by a Device that + has no knowledge of the alteration. Thus, an otherwise trusted + Device might still be an unreliable source of measurement data. + +7.2. Mitigation + + 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. + + + + + + + +Thomson & Winterbottom Standards Track [Page 35] + +RFC 7105 Location Measurements January 2014 + + + Two general approaches are identified for dealing with untrusted + measurement data: + + 1. Require independent validation of measurement data or the + location information that is produced. + + 2. Identify the types of sources that provided the measurement data + from which that location information was derived. + + This section goes into more detail on the different forms of + validation in Sections 7.2.1, 7.2.2, and 7.2.3. The impact of + attributing location information to sources is discussed in more + detail in Section 7.2.4. + + Any costs in validation are balanced against the degree of integrity + desired from the resulting location information. + +7.2.1. Measurement Validation + + Recognizing 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. When it's possible to gather the same measurement data from + a trusted and independent source without undue expense, the LIS can + use the trusted data in place of what the untrusted Device has sent. + In cases where that is impractical, the untrusted data can provide + hints that allow corroboration of the data (see Section 7.2.1.1). + + Measurement information might not contain any inherent indication + that it is falsified. In addition, 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. + +7.2.1.1. Effectiveness + + 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 + + + +Thomson & Winterbottom Standards Track [Page 36] + +RFC 7105 Location Measurements January 2014 + + + 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 + (Section 7.1.4), including attacks involving replay of measurement + data (Section 7.1.5). Validation also limits the amount of network + topology information (Section 7.1.2) made available to Devices to + that portion of the network topology to which they are directly + attached. + + Measurement validation has no effect if the underlying environment is + being altered (Section 7.1.6). + +7.2.1.2. Limitations (Unique Observer) + + 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 easy 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. + + + + + + + + +Thomson & Winterbottom Standards Track [Page 37] + +RFC 7105 Location Measurements January 2014 + + + 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 (Section 7.1.1) are largely + ineffectual against a unique observer. + +7.2.2. Location Validation + + 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. + +7.2.2.1. Effectiveness + + 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 (Section 7.2.1.2). + + 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. + + + + + + +Thomson & Winterbottom Standards Track [Page 38] + +RFC 7105 Location Measurements January 2014 + + +7.2.2.2. Limitations + + 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 an uncertainty region + with a radius of five kilometers. 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 be a boolean operation with + only two possible outcomes: untrusted location information might be + used entirely or not at all. Alternatively, untrusted location + information could be combined with trusted location information using + different weightings, based on a value set in local policy. + +7.2.3. Supporting Observations + + 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 measurement data from 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. + + + +Thomson & Winterbottom Standards Track [Page 39] + +RFC 7105 Location Measurements January 2014 + + +7.2.3.1. Effectiveness + + 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. + + The 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. The applicability + of each method is similar. + + The use of supporting observations can be used to limit or prevent + all of the attacks identified in this document. + +7.2.3.2. Limitations + + The effectiveness of the validation method depends on the quality of + the supporting observation: how hard it is for the entity performing + the validation to obtain the data 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 + measurement imposes an acquisition cost. Supporting observations + contribute little or nothing toward the primary goal of determining + the location of the Device. + +7.2.4. Attribution + + Lying by proxy (Section 7.1.4) 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. + + + +Thomson & Winterbottom Standards Track [Page 40] + +RFC 7105 Location Measurements January 2014 + + + 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 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 of 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 + labeled 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 entity or to + both entities. 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 + (Section 7.1.6). + + + + + + +Thomson & Winterbottom Standards Track [Page 41] + +RFC 7105 Location Measurements January 2014 + + +7.2.5. Stateful Correlation of Location Requests + + 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. A + LIS could also make observations about the movements of a Device. A + Device that is attempting to gather topology information is likely to + be assigned a location that changes significantly between subsequent + requests, possibly violating physical laws (or lower limits that + might still be unlikely) with respect to speed and acceleration. + +7.3. An Unauthorized or Compromised LIS + + A compromised LIS, or a compromise in LIS discovery [RFC5986], could + lead to an unauthorized entity obtaining measurement data. This + information could then be used or redistributed. A Device MUST + ensure that it authenticates a LIS, as described in Section 9 of + [RFC5985]. + + An entity that is able to acquire measurement data can, in addition + to using those measurements to learn the location of a Device, also + use that information for other purposes. This information can be + used to provide insight into network topology (Section 7.1.2). + + Measurement data might also be exploited in other ways. For example, + revealing the type of 802.11 transceiver that a Device uses could + allow an attacker to use specific vulnerabilities to attack a Device. + Similarly, revealing information about network elements could enable + targeted attacks on that infrastructure. + +8. Measurement Schemas + + The schemas are broken up into their respective functions. A base + container schema into which all measurements are placed is defined, + including the definition of a measurement request (Section 8.1). A + PIDF-LO extension is defined in a separate schema (Section 8.2). A + basic Types Schema contains common definitions, including the + "rmsError" and "samples" attributes, plus types for IPv4, IPv6, and + MAC addresses (Section 8.3). Each of the specific measurement types + is defined in a separate schema. + + + + + + + + +Thomson & Winterbottom Standards Track [Page 42] + +RFC 7105 Location Measurements January 2014 + + +8.1. Measurement Container 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.rfc-editor.org/rfc/rfc7105.txt"> + 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"/> + + + +Thomson & Winterbottom Standards Track [Page 43] + +RFC 7105 Location Measurements January 2014 + + + <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> + + Measurement Container Schema + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 44] + +RFC 7105 Location Measurements January 2014 + + +8.2. Measurement Source 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.rfc-editor.org/rfc/rfc7105.txt"> + This schema defines an extension to PIDF-LO that indicates + the type of measurement 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> + + Measurement Source PIDF-LO Extension Schema + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 45] + +RFC 7105 Location Measurements January 2014 + + +8.3. Base Types 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.rfc-editor.org/rfc/rfc7105.txt"> + 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> + + + + + +Thomson & Winterbottom Standards Track [Page 46] + +RFC 7105 Location Measurements January 2014 + + + <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}:"/> + + + + +Thomson & Winterbottom Standards Track [Page 47] + +RFC 7105 Location Measurements January 2014 + + + <!-- 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> + + Base Types Schema + + + + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 48] + +RFC 7105 Location Measurements January 2014 + + +8.4. LLDP Measurement Schema + + <?xml version="1.0"?> + <xs:schema + xmlns:lldp="urn:ietf:params:xml:ns:geopriv:lm:lldp" + xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:lldp" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:annotation> + <xs:appinfo + source="urn:ietf:params:xml:schema:geopriv:lm:lldp"> + </xs:appinfo> + <xs:documentation + source="http://www.rfc-editor.org/rfc/rfc7105.txt"> + 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> + + + + + +Thomson & Winterbottom Standards Track [Page 49] + +RFC 7105 Location Measurements January 2014 + + + <xs:simpleType name="lldpOctetStringType"> + <xs:restriction base="xs:hexBinary"> + <xs:minLength value="1"/> + <xs:maxLength value="255"/> + </xs:restriction> + </xs:simpleType> + </xs:schema> + + LLDP Measurement Schema + +8.5. DHCP Measurement Schema + + <?xml version="1.0"?> + <xs:schema + xmlns:dhcp="urn:ietf:params:xml:ns:geopriv:lm:dhcp" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" + targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dhcp" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:annotation> + <xs:appinfo + source="urn:ietf:params:xml:schema:geopriv:lm:dhcp"> + </xs:appinfo> + <xs:documentation + source="http://www.rfc-editor.org/rfc/rfc7105.txt"> + 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"/> + + + + + +Thomson & Winterbottom Standards Track [Page 50] + +RFC 7105 Location Measurements January 2014 + + + <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> + + DHCP Measurement Schema + +8.6. WiFi Measurement Schema + + <?xml version="1.0"?> + <xs:schema + xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi" + xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" + xmlns: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.rfc-editor.org/rfc/rfc7105.txt"> + This schema defines a basic set of 802.11 location + measurements. + </xs:documentation> + </xs:annotation> + + + + + + + + +Thomson & Winterbottom Standards Track [Page 51] + +RFC 7105 Location Measurements January 2014 + + + <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"/> + + + +Thomson & Winterbottom Standards Track [Page 52] + +RFC 7105 Location Measurements January 2014 + + + </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 an 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> + + + + + +Thomson & Winterbottom Standards Track [Page 53] + +RFC 7105 Location Measurements January 2014 + + + <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> + + WiFi Measurement Schema + + + + +Thomson & Winterbottom Standards Track [Page 54] + +RFC 7105 Location Measurements January 2014 + + +8.7. Cellular Measurement Schema + + <?xml version="1.0"?> + <xs:schema + xmlns:cell="urn:ietf:params:xml:ns:geopriv:lm:cell" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:cell" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:annotation> + <xs:appinfo + source="urn:ietf:params:xml:schema:geopriv:lm:cell"> + </xs:appinfo> + <xs:documentation + source="http://www.rfc-editor.org/rfc/rfc7105.txt"> + 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> + + + +Thomson & Winterbottom Standards Track [Page 55] + +RFC 7105 Location Measurements January 2014 + + + <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="268435455"/> <!-- 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"/> + + + +Thomson & Winterbottom Standards Track [Page 56] + +RFC 7105 Location Measurements January 2014 + + + <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> + + Cellular Measurement Schema + +8.8. GNSS Measurement Schema + + <?xml version="1.0"?> + <xs:schema + xmlns:gnss="urn:ietf:params:xml:ns:geopriv:lm:gnss" + xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:gnss" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:annotation> + <xs:appinfo + source="urn:ietf:params:xml:schema:geopriv:lm:gnss"> + </xs:appinfo> + <xs:documentation + source="http://www.rfc-editor.org/rfc/rfc7105.txt"> + This schema defines a set of GNSS location measurements. + </xs:documentation> + </xs:annotation> + + + + + + + + +Thomson & Winterbottom Standards Track [Page 57] + +RFC 7105 Location Measurements January 2014 + + + <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> + + + + +Thomson & Winterbottom Standards Track [Page 58] + +RFC 7105 Location Measurements January 2014 + + + <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> + + GNSS Measurement Schema + +8.9. DSL Measurement Schema + + <?xml version="1.0"?> + <xs:schema + xmlns:dsl="urn:ietf:params:xml:ns:geopriv:lm:dsl" + xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" + xmlns:xs="http://www.w3.org/2001/XMLSchema" + targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dsl" + elementFormDefault="qualified" + attributeFormDefault="unqualified"> + + <xs:annotation> + <xs:appinfo + source="urn:ietf:params:xml:schema:geopriv:lm:dsl"> + DSL measurement definitions + </xs:appinfo> + <xs:documentation + source="http://www.rfc-editor.org/rfc/rfc7105.txt"> + This schema defines a basic set of DSL location measurements. + </xs:documentation> + </xs:annotation> + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 59] + +RFC 7105 Location Measurements January 2014 + + + <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> + + + + + +Thomson & Winterbottom Standards Track [Page 60] + +RFC 7105 Location Measurements January 2014 + + + <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> + + DSL Measurement Schema + +9. IANA Considerations + + This section creates a registry for GNSS types (Section 5.5) and + registers the namespaces and schemas defined in Section 8. + +9.1. IANA Registry for GNSS Types + + This document establishes a new IANA registry for "Global Navigation + Satellite System (GNSS)" types. The registry includes tokens for the + GNSS type and for each of the signals within that type. Referring to + [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: + + GNSS Name: the name of the GNSS + + Brief Description: a brief description of the GNSS + + GNSS Token: a token that can be used to identify the GNSS + + Signals: a set of tokens that represent each of the signals that the + system provides + + Documentation Reference: a reference to one or more stable, public + specifications that outline usage of the GNSS, including (but not + limited to) signal specifications and time systems + + The registry initially includes two registrations: + + GNSS Name: Global Positioning System (GPS) + + + + +Thomson & Winterbottom Standards Track [Page 61] + +RFC 7105 Location Measurements January 2014 + + + Brief Description: a system of satellites that use spread-spectrum + transmission, operated by the US military for commercial and + military applications + + GNSS Token: gps + + Signals: L1, L2, L1C, L2C, L5 + + Documentation Reference: Navstar GPS Space Segment/Navigation User + Interface [GPS.ICD] + + GNSS Name: Galileo + + Brief Description: a system of satellites that operate in the same + spectrum as GPS, operated by the European Union for commercial + applications + + GNSS Token: galileo + + Signals: L1, E5A, E5B, E5A+B, E6 + + Documentation Reference: Galileo Open Service Signal In Space + Interface Control Document (SIS ICD) [Galileo.ICD] + +9.2. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines + in [RFC3688]. + + URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc + + Registrant Contact: IETF, GEOPRIV working group + (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com). + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> + <head> + <title>Measurement Source for PIDF-LO</title> + </head> + + + + + +Thomson & Winterbottom Standards Track [Page 62] + +RFC 7105 Location Measurements January 2014 + + + <body> + <h1>Namespace for Location Measurement Source</h1> + <h2>urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt"> + RFC 7105</a>.</p> + </body> + </html> + END + +9.3. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:geopriv:lm + + Registrant Contact: IETF, GEOPRIV working group + (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com). + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> + <head> + <title>Measurement Container</title> + </head> + <body> + <h1>Namespace for Location Measurement Container</h1> + <h2>urn:ietf:params:xml:ns:geopriv:lm</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt"> + RFC 7105</a>.</p> + </body> + </html> + END + +9.4. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:basetypes + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines + in [RFC3688]. + + URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes + + + +Thomson & Winterbottom Standards Track [Page 63] + +RFC 7105 Location Measurements January 2014 + + + Registrant Contact: IETF, GEOPRIV working group + (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com). + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> + <head> + <title>Base Device Types</title> + </head> + <body> + <h1>Namespace for Base Types</h1> + <h2>urn:ietf:params:xml:ns:geopriv:lm:basetypes</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt"> + RFC 7105</a>.</p> + </body> + </html> + END + +9.5. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:lldp + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:geopriv:lm:lldp + + Registrant Contact: IETF, GEOPRIV working group + (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com). + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> + <head> + <title>LLDP Measurement Set</title> + </head> + + + + + + + +Thomson & Winterbottom Standards Track [Page 64] + +RFC 7105 Location Measurements January 2014 + + + <body> + <h1>Namespace for LLDP Measurement Set</h1> + <h2>urn:ietf:params:xml:ns:geopriv:lm:lldp</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt"> + RFC 7105</a>.</p> + </body> + </html> + END + +9.6. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:dhcp + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp + + Registrant Contact: IETF, GEOPRIV working group + (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com). + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> + <head> + <title>DHCP Measurement Set</title> + </head> + <body> + <h1>Namespace for DHCP Measurement Set</h1> + <h2>urn:ietf:params:xml:ns:geopriv:lm:dhcp</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt"> + RFC 7105</a>.</p> + </body> + </html> + END + +9.7. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:wifi + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:geopriv:lm:wifi + + + +Thomson & Winterbottom Standards Track [Page 65] + +RFC 7105 Location Measurements January 2014 + + + Registrant Contact: IETF, GEOPRIV working group + (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com). + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> + <head> + <title>WiFi Measurement Set</title> + </head> + <body> + <h1>Namespace for WiFi Measurement Set</h1> + <h2>urn:ietf:params:xml:ns:geopriv:lm:wifi</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt"> + RFC 7105</a>.</p> + </body> + </html> + END + +9.8. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:cell + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:geopriv:lm:cell + + Registrant Contact: IETF, GEOPRIV working group + (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com). + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> + <head> + <title>Cellular Measurement Set</title> + </head> + + + + + + + +Thomson & Winterbottom Standards Track [Page 66] + +RFC 7105 Location Measurements January 2014 + + + <body> + <h1>Namespace for Cellular Measurement Set</h1> + <h2>urn:ietf:params:xml:ns:geopriv:lm:cell</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt"> + RFC 7105</a>.</p> + </body> + </html> + END + +9.9. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:gnss + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:geopriv:lm:gnss + + Registrant Contact: IETF, GEOPRIV working group + (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com). + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> + <head> + <title>GNSS Measurement Set</title> + </head> + <body> + <h1>Namespace for GNSS Measurement Set</h1> + <h2>urn:ietf:params:xml:ns:geopriv:lm:gnss</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt"> + RFC 7105</a>.</p> + </body> + </html> + END + +9.10. URN Sub-Namespace Registration for + urn:ietf:params:xml:ns:geopriv:lm:dsl + + This section registers a new XML namespace, + "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:ns:geopriv:lm:dsl + + + +Thomson & Winterbottom Standards Track [Page 67] + +RFC 7105 Location Measurements January 2014 + + + Registrant Contact: IETF, GEOPRIV working group + (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com). + + XML: + + BEGIN + <?xml version="1.0"?> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> + <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> + <head> + <title>DSL Measurement Set</title> + </head> + <body> + <h1>Namespace for DSL Measurement Set</h1> + <h2>urn:ietf:params:xml:ns:geopriv:lm:dsl</h2> + <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt"> + RFC 7105</a>.</p> + </body> + </html> + END + +9.11. XML Schema Registration for Measurement Source Schema + + This section registers an XML schema as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc + + Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), + Martin Thomson (martin.thomson@gmail.com). + + Schema: The XML for this schema can be found in Section 8.2 of this + document. + +9.12. XML Schema Registration for Measurement Container Schema + + This section registers an XML schema as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:geopriv:lm + + Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), + Martin Thomson (martin.thomson@gmail.com). + + Schema: The XML for this schema can be found in Section 8.1 of this + document. + + + + +Thomson & Winterbottom Standards Track [Page 68] + +RFC 7105 Location Measurements January 2014 + + +9.13. XML Schema Registration for Base Types Schema + + This section registers an XML schema as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:geopriv:lm:basetypes + + Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), + Martin Thomson (martin.thomson@gmail.com). + + Schema: The XML for this schema can be found in Section 8.3 of this + document. + +9.14. XML Schema Registration for LLDP Schema + + This section registers an XML schema as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:geopriv:lm:lldp + + Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), + Martin Thomson (martin.thomson@gmail.com). + + Schema: The XML for this schema can be found in Section 8.4 of this + document. + +9.15. XML Schema Registration for DHCP Schema + + This section registers an XML schema as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:geopriv:lm:dhcp + + Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), + Martin Thomson (martin.thomson@gmail.com). + + Schema: The XML for this schema can be found in Section 8.5 of this + document. + +9.16. XML Schema Registration for WiFi Schema + + This section registers an XML schema as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:geopriv:lm:wifi + + Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), + Martin Thomson (martin.thomson@gmail.com). + + + +Thomson & Winterbottom Standards Track [Page 69] + +RFC 7105 Location Measurements January 2014 + + + Schema: The XML for this schema can be found in Section 8.6 of this + document. + +9.17. XML Schema Registration for Cellular Schema + + This section registers an XML schema as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:geopriv:lm:cell + + Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), + Martin Thomson (martin.thomson@gmail.com). + + Schema: The XML for this schema can be found in Section 8.7 of this + document. + +9.18. XML Schema Registration for GNSS Schema + + This section registers an XML schema as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:geopriv:lm:gnss + + Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), + Martin Thomson (martin.thomson@gmail.com). + + Schema: The XML for this schema can be found in Section 8.8 of this + document. + +9.19. XML Schema Registration for DSL Schema + + This section registers an XML schema as per the guidelines in + [RFC3688]. + + URI: urn:ietf:params:xml:schema:geopriv:lm:dsl + + Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), + Martin Thomson (martin.thomson@gmail.com). + + Schema: The XML for this schema can be found in Section 8.9 of this + document. + +10. Acknowledgements + + Thanks go to Simon Cox for his comments relating to terminology; his + comments have helped ensure that this document is aligned with + ongoing work in the Open Geospatial Consortium (OGC). Thanks to Neil + Harper for his review and comments on the GNSS sections of this + + + +Thomson & Winterbottom Standards Track [Page 70] + +RFC 7105 Location Measurements January 2014 + + + 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 and Darren Pawson provided expert LTE knowledge. + +11. References + +11.1. Normative References + + [ASCII] ANSI, "US-ASCII. Coded Character Set - 7-Bit American + Standard Code for Information Interchange. Standard ANSI + X3.4-1986", 1986. + + [GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface", ICD + GPS-200, April 2000. + + [Galileo.ICD] + GJU, "Galileo Open Service Signal In Space Interface + Control Document (SIS ICD)", May 2006. + + [IANA.enterprise] + IANA, "Private Enterprise Numbers", 2014, + <http://www.iana.org/assignments/enterprise-numbers>. + + [IEEE.80211] + IEEE, "Wireless LAN Medium Access Control (MAC) and + Physical Layer (PHY) Specifications", IEEE + Std 802.11-2012, March 2012. + + [IEEE.8021AB] + IEEE, "IEEE Standard for Local and Metropolitan Area + Networks, Station and Media Access Control Connectivity + Discovery", IEEE Std 802.1AB-2009, September 2009. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", + RFC 3046, January 2001. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + + + +Thomson & Winterbottom Standards Track [Page 71] + +RFC 7105 Location Measurements January 2014 + + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of + ISO 10646", STD 63, RFC 3629, November 2003. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID + Suboption for the Dynamic Host Configuration Protocol + (DHCP) Relay Agent Option", RFC 3993, March 2005. + + [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object + Format", RFC 4119, December 2005. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, + June 2006. + + [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, + August 2006. + + [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV + Presence Information Data Format Location Object (PIDF-LO) + Usage Clarification, Considerations, and Recommendations", + RFC 5491, March 2009. + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, August 2010. + + [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", + RFC 5985, September 2010. + + [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local + Location Information Server (LIS)", RFC 5986, + September 2010. + + [TIA-2000.5] + TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for + cdma2000(R) Spread Spectrum Systems", TR-45.5 / TSG-C + TIA-2000.5-E / C.S0005-E v1.0, September 2009. + + + + + + + +Thomson & Winterbottom Standards Track [Page 72] + +RFC 7105 Location Measurements January 2014 + + + [TS.3GPP.23.003] + 3GPP, "Numbering, addressing and identification", 3GPP TS + 23.003 12.0.0, September 2013, + <http://www.3gpp.org/ftp/Specs/html-info/23003.htm>. + +11.2. Informative References + + [ANSI-TIA-1057] + ANSI/TIA, "Link Layer Discovery Protocol for Media + Endpoint Devices", TIA 1057, April 2006. + + [DSL.TR025] + Wang, R., "Core Network Architecture Recommendations for + Access to Legacy Data Networks over ADSL", September 1999. + + [DSL.TR101] + Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL + Aggregation", April 2006. + + [GPS.SPOOF] + Scott, L., "Anti-Spoofing and Authenticated Signal + Architectures for Civil Navigation Signals", ION-GNSS + Portland, Oregon, 2003. + + [HARPER] Harper, N., "Server-side GPS and Assisted-GPS in Java", + December 2009. + + [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, + G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", + RFC 2661, August 1999. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + January 2004. + + [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and + J. Polk, "Geopriv Requirements", RFC 3693, February 2004. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. + Barnes, "Use of Device Identity in HTTP-Enabled Location + Delivery (HELD)", RFC 6155, March 2011. + + + +Thomson & Winterbottom Standards Track [Page 73] + +RFC 7105 Location Measurements January 2014 + + + [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., + Tschofenig, H., and H. Schulzrinne, "An Architecture for + Location and Location Privacy in Internet Applications", + BCP 160, RFC 6280, July 2011. + +Authors' Addresses + + Martin Thomson + Mozilla + Suite 300 + 650 Castro Street + Mountain View, CA 94041 + US + + EMail: martin.thomson@gmail.com + + + James Winterbottom + Unaffiliated + AU + + EMail: a.james.winterbottom@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson & Winterbottom Standards Track [Page 74] + |