draft-ietf-geopriv-held-measurements-09.txt   rfc7105.txt 
GEOPRIV M. Thomson Internet Engineering Task Force (IETF) M. Thomson
Internet-Draft Microsoft Request for Comments: 7105 Mozilla
Intended status: Standards Track J. Winterbottom Category: Standards Track J. Winterbottom
Expires: March 10, 2014 Unaffiliated ISSN: 2070-1721 Unaffiliated
September 06, 2013 January 2014
Using Device-provided Location-Related Measurements in Location Using Device-Provided Location-Related Measurements
Configuration Protocols in Location Configuration Protocols
draft-ietf-geopriv-held-measurements-09
Abstract Abstract
This document describes a protocol for a Device to provide location- This document describes a protocol for a Device to provide location-
related measurement data to a Location Information Server (LIS) related measurement data to a Location Information Server (LIS)
within a request for location information. Location-related within a request for location information. Location-related
measurement information are observations concerning properties measurement information provides observations concerning properties
related to the position of a Device, which could be data about related to the position of a Device; this information could be data
network attachment or about the physical environment. A LIS is able about network attachment or about the physical environment. A LIS is
to use the location-related measurement data to improve the accuracy able to use the location-related measurement data to improve the
of the location estimate it provides to the Device. A basic set of accuracy of the location estimate it provides to the Device. A basic
location-related measurements are defined, including common modes of set of location-related measurements are defined, including common
network attachment as well as assisted Global Navigation Satellite modes of network attachment as well as assisted Global Navigation
System (GNSS) parameters. Satellite System (GNSS) parameters.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 10, 2014. 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.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document ...............................5
3. Location-Related Measurements in LCPs . . . . . . . . . . . . 5 3. Location-Related Measurements in LCPs ...........................6
4. Location-Related Measurement Data Types . . . . . . . . . . . 7 4. Location-Related Measurement Data Types .........................7
4.1. Measurement Container . . . . . . . . . . . . . . . . . . 7 4.1. Measurement Container ......................................7
4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 8 4.1.1. Time of Measurement .................................8
4.1.2. Expiry Time on Location-Related Measurement Data . . 8 4.1.2. Expiry Time on Location-Related Measurement Data ....8
4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 8 4.2. RMS Error and Number of Samples ............................9
4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . 9 4.2.1. Time RMS Error ......................................9
4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 10 4.3. Measurement Request .......................................10
4.4. Identifying Location Provenance . . . . . . . . . . . . . 11 4.4. Identifying Location Provenance ...........................11
5. Location-Related Measurement Data Types . . . . . . . . . . . 13 5. Location-Related Measurement Data Types ........................13
5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 14 5.1. LLDP Measurements .........................................13
5.2. DHCP Relay Agent Information Measurements . . . . . . . . 15 5.2. DHCP Relay Agent Information Measurements .................14
5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . 15 5.3. 802.11 WLAN Measurements ..................................15
5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 19 5.3.1. WiFi Measurement Requests ..........................18
5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 19 5.4. Cellular Measurements .....................................18
5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 22 5.4.1. Cellular Measurement Requests ......................22
5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 22 5.5. GNSS Measurements .........................................22
5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . 24 5.5.1. GNSS: System Type and Signal .......................23
5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . 24 5.5.2. Time ...............................................24
5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . 24 5.5.3. Per-Satellite Measurement Data .....................24
5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 25 5.5.4. GNSS Measurement Requests ..........................25
5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . 25 5.6. DSL Measurements ..........................................25
5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 26 5.6.1. L2TP Measurements ..................................26
5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 26 5.6.2. RADIUS Measurements ................................26
5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . 27 5.6.3. Ethernet VLAN Tag Measurements .....................27
5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . 28 5.6.4. ATM Virtual Circuit Measurements ...................28
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. Third-Party-Provided Measurement Data . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 32
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 . . . . . . . . . . . . . . . . . . . 38
7.2.3. Supporting Observations . . . . . . . . . . . . . . . 39
7.2.3.1. Effectiveness . . . . . . . . . . . . . . . . . . 39
7.2.3.2. Limitations . . . . . . . . . . . . . . . . . . . 40
7.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 40
7.2.5. Stateful Correlation of Location Requests . . . . . . 41
7.3. An Unauthorized or Compromised LIS . . . . . . . . . . . 42
8. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 42
8.1. Measurement Container Schema . . . . . . . . . . . . . . 42
8.2. Measurement Source Schema . . . . . . . . . . . . . . . . 44
8.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . 45
8.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 48
8.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 49
8.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 50
8.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 54
8.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 56
8.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . 58
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . 60
9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 61
9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 62
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 . . . . . . . . . 63
9.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . 64
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 . . . . . . . . . 65
9.9. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . 66
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 . . 67 6. Privacy Considerations .........................................28
9.12. XML Schema Registration for Measurement Container Schema 68 6.1. Measurement Data Privacy Model ............................28
9.13. XML Schema Registration for Base Types Schema . . . . . . 68 6.2. LIS Privacy Requirements ..................................29
9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 68 6.3. Measurement Data and Location URIs ........................29
9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 68 6.4. Measurement Data Provided by a Third Party ................30
9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 69 7. Security Considerations ........................................30
9.17. XML Schema Registration for Cellular Schema . . . . . . . 69 7.1. Threat Model ..............................................30
9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 69 7.1.1. Acquiring Location Information without
9.19. XML Schema Registration for DSL Schema . . . . . . . . . 69 Authorization ......................................31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 7.1.2. Extracting Network Topology Data ...................32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.1.3. Exposing Network Topology Data .....................32
11.1. Normative References . . . . . . . . . . . . . . . . . . 70 7.1.4. Lying by Proxy .....................................33
11.2. Informative References . . . . . . . . . . . . . . . . . 72 7.1.5. Measurement Replay .................................33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 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
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 1. Introduction
A Location Configuration Protocol (LCP) provides a means for a Device A Location Configuration Protocol (LCP) provides a means for a Device
to request information about its physical location from an access to request information about its physical location from an access
network. A location information server (LIS) is the server that network. A Location Information Server (LIS) is the server that
provides location information that is available due to the knowledge provides location information that is available due to the knowledge
it has about the network and physical environment. it has about the network and physical environment.
As a part of the access network, the LIS is able to acquire As a part of the access network, the LIS is able to acquire
measurement results related to Device location from network elements. measurement results related to Device location from network elements.
The LIS also has access to information about the network topology The LIS also has access to information about the network topology
that can be used to turn measurement data into location information. that can be used to turn measurement data into location information.
This information can be further enhanced with information acquired This information can be further enhanced with information acquired
from the Device itself. from the Device itself.
A Device is able to make observations about its network attachment, A Device is able to make observations about its network attachment,
or its physical environment. The location-related measurement data or its physical environment. The location-related measurement data
might be unavailable to the LIS; alternatively, the LIS might be able might be unavailable to the LIS; alternatively, the LIS might be able
to acquire the data, but at a higher cost, in time or an other to acquire the data, but at a higher cost in terms of time or some
metric. Providing measurement data gives the LIS more options in other metric. Providing measurement data gives the LIS more options
determining location, which could improve the quality of the service in determining location; this could in turn improve the quality of
provided by the LIS. Improvements in accuracy are one potential the service provided by the LIS. Improvements in accuracy are one
gain, but improved response times and lower error rates are possible. potential gain, but improved response times and lower error rates are
also possible.
This document describes a means for a Device to report location- This document describes a means for a Device to report location-
related measurement data to the LIS. Examples based on the HELD related measurement data to the LIS. Examples based on the
[RFC5985] location configuration protocol are provided. HTTP-Enabled Location Delivery (HELD) [RFC5985] location
configuration protocol are provided.
2. Conventions used in this document 2. Conventions Used in This Document
The terms LIS and Device are used in this document in a manner The terms "LIS" and "Device" are used in this document in a manner
consistent with the usage in [RFC5985]. consistent with the usage in [RFC5985].
This document also uses the following definitions: This document also uses the following definitions:
Location Measurement: An observation about the physical properties Location Measurement: An observation about the physical properties
of a particular Device's position in time and space. The result of a particular Device's position in time and space. The result
of a location measurement - "location-related measurement data", of a location measurement -- "location-related measurement data",
or simply "measurement data" given sufficient context - can be or simply "measurement data" given sufficient context -- can be
used to determine the location of a Device. Location-related used to determine the location of a Device. Location-related
measurement data does not directly identify a Device, though it measurement data does not directly identify a Device, though it
could do indirectly. Measurement data can change with time if the could do so indirectly. Measurement data can change with time if
location of the Device also changes. the location of the Device also changes.
Location-related measurement data does not necessarily contain Location-related measurement data does not necessarily contain
location information directly, but it can be used in combination location information directly, but it can be used in combination
with contextual knowledge and/or algorithms to derive location with contextual knowledge and/or algorithms to derive location
information. Examples of location-related measurement data are: information. Examples of location-related measurement data are
radio signal strength or timing measurements, Ethernet switch and radio signal strength or timing measurements, Ethernet switch
port identifiers. identifiers, and port identifiers.
Location-related measurement data can be considered sighting Location-related measurement data can be considered sighting
information, based on the definition in [RFC3693]. information, based on the definition in [RFC3693].
Location Estimate: A location estimate is an approximation of where Location Estimate: An approximation of where the Device is located.
the Device is located. Location estimates are derived from Location estimates are derived from location measurements.
location measurements. Location estimates are subject to Location estimates are subject to uncertainty, which arises from
uncertainty, which arise from errors in measurement results. errors in measurement results.
GNSS: Global Navigation Satellite System. A satellite-based system GNSS: Global Navigation Satellite System. A satellite-based system
that provides positioning and time information. For example, the that provides positioning and time information -- for example, the
US Global Positioning System (GPS) or the European Galileo system. US Global Positioning System (GPS) or the European Galileo system.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Location-Related Measurements in LCPs 3. Location-Related Measurements in LCPs
This document defines a standard container for the conveyance of This document defines a standard container for the conveyance of
location-related measurement parameters in location configuration location-related measurement parameters in location configuration
protocols. This is an XML container that identifies parameters by protocols. This is an XML container that identifies parameters by
type and allows the Device to provide the results of any measurement 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 it is able to perform. A set of measurement schemas are also defined
that can be carried in the generic container. that can be carried in the generic container.
A simple example of measurement data conveyance is illustrated by the A simple example of measurement data conveyance is illustrated by the
example message in Figure 1. This shows a HELD location request example message in Figure 1. This shows a HELD location request
message with an Ethernet switch and port measurement taken using LLDP message with an Ethernet switch and port measurement taken using the
[IEEE.8021AB]. Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB].
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">civic</locationType> <locationType exact="true">civic</locationType>
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp"> <lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
<chassis type="4">0a01003c</chassis> <chassis type="4">0a01003c</chassis>
<port type="6">c2</port> <port type="6">c2</port>
</lldp> </lldp>
</measurements> </measurements>
</locationRequest> </locationRequest>
Figure 1: HELD Location Request with Measurement Data Figure 1: HELD Location Request with Measurement Data
This LIS can ignore measurement data that it does not support or This LIS can ignore measurement data that it does not support or
understand. The measurements defined in this document follow this understand. The measurements defined in this document follow this
rule: extensions that could result in backward incompatibility MUST rule: extensions that could result in backward incompatibility MUST
be added as new measurement definitions rather than extensions to be added as new measurement definitions rather than extensions to
existing types. existing types.
Multiple sets of measurement data, either of the same type or from Multiple sets of measurement data, either of the same type or from
skipping to change at page 6, line 42 skipping to change at page 7, line 5
A LIS can choose to use or ignore location-related measurement data A LIS can choose to use or ignore location-related measurement data
in determining location, as long as rules regarding use and retention in determining location, as long as rules regarding use and retention
(Section 6) are respected. The "method" parameter in the Presence (Section 6) are respected. The "method" parameter in the Presence
Information Data Format - Location Object (PIDF-LO) [RFC4119] SHOULD Information Data Format - Location Object (PIDF-LO) [RFC4119] SHOULD
be adjusted to reflect the method used. A correct "method" can be adjusted to reflect the method used. A correct "method" can
assist location recipients in assessing the quality (both accuracy assist location recipients in assessing the quality (both accuracy
and integrity) of location information, though there could be reasons and integrity) of location information, though there could be reasons
to withhold information about the source of data. to withhold information about the source of data.
Measurement data is typically only used to serve the request that it Measurement data is typically only used to serve the request in which
is included in. There may be exceptions, particularly with respect it is included. There may be exceptions, particularly with respect
to location URIs. Section 6 provides more information on usage to location URIs. Section 6 provides more information on usage
rules. rules.
Location-related measurement data need not be provided exclusively by Location-related measurement data need not be provided exclusively by
Devices. A third party location requester (for example, see Devices. A third-party location requester (for example, see
[RFC6155]) can request location information using measurement data, [RFC6155]) can request location information using measurement data,
if the requester is able to acquire measurement data and authorized if the requester is able to acquire measurement data and authorized
to distribute it. There are specific privacy considerations relating to distribute it. There are specific privacy considerations relating
to the use of measurements by third parties, which are discussed in to the use of measurements by third parties, which are discussed in
Section 6.4. Section 6.4.
Location-related measurement data and its use presents a number of Location-related measurement data and its use present a number of
privacy and security challenges. These are described in more detail privacy and security challenges. These are described in more detail
in Section 6 and Section 7. in Sections 6 and 7.
4. Location-Related Measurement Data Types 4. Location-Related Measurement Data Types
A common container is defined for the expression of location A common container is defined for the expression of location
measurement data, as well as a simple means of identifying specific measurement data, as well as a simple means of identifying specific
types of measurement data for the purposes of requesting them. types of measurement data for the purposes of requesting them.
The following example shows a measurement container with measurement The following example shows a measurement container with measurement
time and expiration time included. A WiFi measurement is enclosed. time and expiration time included. A WiFi measurement is enclosed.
<lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm" <lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58" time="2008-04-29T14:33:58"
expires="2008-04-29T17:33:58"> expires="2008-04-29T17:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi"> <wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<ap serving="true"> <ap serving="true">
<bssid>00-12-F0-A0-80-EF</bssid> <bssid>00-12-F0-A0-80-EF</bssid>
<ssid>wlan-home</ssid> <ssid>wlan-home</ssid>
</ap> </ap>
</wifi> </wifi>
</lm:measurements> </lm:measurements>
Figure 2: Measurement Example Figure 2: Measurement Example
4.1. Measurement Container 4.1. Measurement Container
The "measurements" element is used to encapsulate measurement data The "measurements" element is used to encapsulate measurement data
that is collected at a certain point in time. It contains time-based that is collected at a certain point in time. It contains time-based
attributes that are common to all forms of measurement data, and attributes that are common to all forms of measurement data, and it
permits the inclusion of arbitrary measurement data. The elements permits the inclusion of arbitrary measurement data. The elements
that are included within the "measurements" element are generically that are included within the "measurements" element are generically
referred to as "measurement elements". referred to as "measurement elements".
This container can be added to a request for location information in This container can be added to a request for location information in
any protocol capable of carrying XML, such as a HELD location request any protocol capable of carrying XML, such as a HELD location request
[RFC5985]. [RFC5985].
4.1.1. Time of Measurement 4.1.1. Time of Measurement
The "time" attribute records the time that the measurement or The "time" attribute records the time that the measurement or
observation was made. This time can be different to the time that observation was made. This time can be different from the time that
the measurement information was reported. Time information can be the measurement information was reported. Time information can be
used to populate a timestamp on the location result, or to determine used to populate a timestamp on the location result or to determine
if the measurement information is used. if the measurement information is used.
The "time" attribute SHOULD be provided whenever possible. This The "time" attribute SHOULD be provided whenever possible. This
allows a LIS to avoid selecting an arbitrary timestamp. Exceptions allows a LIS to avoid selecting an arbitrary timestamp. Exceptions
to this, where omitting time might make sense, include relatively to this, where omitting time might make sense, include relatively
static types of measurement (for instance, the DSL measurements in static types of measurement (for instance, the DSL measurements in
Section 5.6) or for legacy Devices that don't record time information Section 5.6) or for legacy Devices that don't record time information
(such as the Home Location Register/Home Subscriber Server for (such as the Home Location Register/Home Subscriber Server for
cellular). cellular).
The "time" attribute is attached to the root "measurement" element. The "time" attribute is attached to the root "measurement" element.
Multiple measurements can often be given the same timestamp, even Multiple measurements can often be given the same timestamp, even
when the measurements were not actually taken at the same time when the measurements were not actually taken at the same time
(consider a set of measurements taken sequentially, where the (consider a set of measurements taken sequentially, where the
difference in time between observations is not significant). difference in time between observations is not significant).
Measurements cannot be grouped if they have different types, or there Measurements cannot be grouped if they have different types or if
is a need for independent time values on each measurement. In these there is a need for independent time values on each measurement. In
instances, multiple measurement sets are necessary. these instances, multiple measurement sets are necessary.
4.1.2. Expiry Time on Location-Related Measurement Data 4.1.2. Expiry Time on Location-Related Measurement Data
A Device is able to indicate an expiry time in the location A Device is able to indicate an expiry time in the location
measurement using the "expires" attribute. Nominally, this attribute measurement using the "expires" attribute. Nominally, this attribute
indicates how long information is expected to be valid, but it can indicates how long information is expected to be valid, but it can
also indicate a time limit on the retention and use of the also indicate a time limit on the retention and use of the
measurement data. A Device can use this attribute to request that measurement data. A Device can use this attribute to request that
the LIS not retain measurement data beyond the indicated time. the LIS not retain measurement data beyond the indicated time.
Note: Movement of the Device might result in the measurement data Note: Movement of the Device might result in the measurement data
being invalidated before the expiry time. being invalidated before the expiry time.
A Device is advised to set the "expires" attribute to earlier of: the A Device is advised to set the "expires" attribute to the earlier of
time that measurements are likely to be unusable, and the time that the time that measurements are likely to be unusable and the time
it desires to have measurements discarded by the LIS. A Device that that it desires to have measurements discarded by the LIS. A Device
does not desire measurement data to be retained can omit the that does not desire measurement data to be retained can omit the
"expires" attribute. Section 6 describes more specific rules "expires" attribute. Section 6 describes more specific rules
regarding measurement data retention. regarding measurement data retention.
4.2. RMS Error and Number of Samples 4.2. RMS Error and Number of Samples
Often a measurement is taken more than once. Reporting the average Often a measurement is taken more than once. Reporting the average
of a number of measurement results mitigates the effects of random of a number of measurement results mitigates the effects of random
errors that occur in the measurement process. errors that occur in the measurement process.
Reporting each measurement individually can be the most effective Reporting each measurement individually can be the most effective
method of reporting multiple measurements. This is achieved by method of reporting multiple measurements. This is achieved by
providing multiple measurement elements for different times. providing multiple measurement elements for different times.
The alternative is to aggregate multiple measurements and report a The alternative is to aggregate multiple measurements and report a
mean value across the set of measurements. Additional information mean value across the set of measurements. Additional information
skipping to change at page 9, line 22 skipping to change at page 9, line 25
The alternative is to aggregate multiple measurements and report a The alternative is to aggregate multiple measurements and report a
mean value across the set of measurements. Additional information mean value across the set of measurements. Additional information
about the distribution of the results can be useful in determining about the distribution of the results can be useful in determining
location uncertainty. location uncertainty.
Two attributes are provided for use on some measurement values: Two attributes are provided for use on some measurement values:
rmsError: The root-mean-squared (RMS) error of the set of rmsError: The root-mean-squared (RMS) error of the set of
measurement values used in calculating the result. RMS error is measurement values used in calculating the result. RMS error is
expressed in the same units as the measurement, unless otherwise expressed in the same units as the measurement, unless otherwise
stated. If an accurate value for RMS error is not known, this 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 value can be used to indicate an upper bound or estimate for the
RMS error. RMS error.
samples: The number of samples that were taken in determining the samples: The number of samples that were taken in determining the
measurement value. If omitted, this value can be assumed to be measurement value. If omitted, this value can be assumed to be
large enough that the RMS error is an indication of the standard large enough that the RMS error is an indication of the standard
deviation of the sample set. deviation of the sample set.
For some measurement techniques, measurement error is largely For some measurement techniques, measurement error is largely
dependent on the measurement technique employed. In these cases, dependent on the measurement technique employed. In these cases,
measurement error is largely a product of the measurement technique measurement error is largely a product of the measurement technique
and not the specific circumstances, so RMS error does not need to be and not the specific circumstances, so the RMS error does not need to
actively measured. A fixed value MAY be provided for RMS error where be actively measured. A fixed value MAY be provided for the RMS
appropriate. error where appropriate.
The "rmsError" and "samples" elements are added as attributes of The "rmsError" and "samples" elements are added as attributes of
specific measurement data types. specific measurement data types.
4.2.1. Time RMS Error 4.2.1. Time RMS Error
Measurement of time can be significant in certain circumstances. The Measurement of time can be significant in certain circumstances. The
GNSS measurements included in this document are one such case where a 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 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 such as clock drift and errors in time synchronization can result in
skipping to change at page 10, line 27 skipping to change at page 10, line 27
defined that can be included in a protocol exchange. defined that can be included in a protocol exchange.
For instance, a LIS can use a measurement request in HELD responses. For instance, a LIS can use a measurement request in HELD responses.
If the LIS is unable to provide location information, but it believes If the LIS is unable to provide location information, but it believes
that a particular measurement type would enable it to provide a that a particular measurement type would enable it to provide a
location, it can include a measurement request in an error response. location, it can include a measurement request in an error response.
The "measurement" element of the measurement request identifies the The "measurement" element of the measurement request identifies the
type of measurement that is requested. The "type" attribute of this type of measurement that is requested. The "type" attribute of this
element indicates the type of measurement, as identified by an XML element indicates the type of measurement, as identified by an XML
qualified name. An "samples" attribute MAY be used to indicate how qualified name. A "samples" attribute MAY be used to indicate how
many samples of the identified measurement are requested. many samples of the identified measurement are requested.
The "measurement" element can be repeated to request multiple (or The "measurement" element can be repeated to request multiple (or
alternative) measurement types. alternative) measurement types.
Additional XML content might be defined for a particular measurement Additional XML content might be defined for a particular measurement
type that is used to further refine a request. These elements either type that is used to further refine a request. These elements either
constrain what is requested or specify non-mandatory components of constrain what is requested or specify non-mandatory components of
the measurement data that are needed. These are defined along with the measurement data that are needed. These are defined along with
the specific measurement type. the specific measurement type.
skipping to change at page 11, line 5 skipping to change at page 11, line 10
In the HELD protocol, the inclusion of a measurement request in an In the HELD protocol, the inclusion of a measurement request in an
error response with a code of "locationUnknown" indicates that error response with a code of "locationUnknown" indicates that
providing measurements would increase the likelihood of a subsequent providing measurements would increase the likelihood of a subsequent
request being successful. request being successful.
The following example shows a HELD error response that indicates that The following example shows a HELD error response that indicates that
WiFi measurement data would be useful if a later request were made. WiFi measurement data would be useful if a later request were made.
Additional elements indicate that received signal strength for an Additional elements indicate that received signal strength for an
802.11n access point is requested. 802.11n access point is requested.
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown"> code="locationUnknown">
<message xml:lang="en">Insufficient measurement data</message> <message xml:lang="en">Insufficient measurement data</message>
<measurementRequest <measurementRequest
xmlns="urn:ietf:params:xml:ns:geopriv:lm" xmlns="urn:ietf:params:xml:ns:geopriv:lm"
xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi"> xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<measurement type="wifi:wifi"> <measurement type="wifi:wifi">
<wifi:type>n</wifi:type> <wifi:type>n</wifi:type>
<wifi:parameter context="ap">wifi:rcpi</wifi:parameter> <wifi:parameter context="ap">wifi:rcpi</wifi:parameter>
</measurement> </measurement>
</measurementRequest> </measurementRequest>
</error> </error>
Figure 3: HELD Error Requesting Measurement Data Figure 3: HELD Error Requesting Measurement Data
A measurement request that is included in other HELD messages has A measurement request that is included in other HELD messages has
undefined semantics and can be safely ignored. Other specifications undefined semantics and can be safely ignored. Other specifications
might define semantics for measurement requests under other might define semantics for measurement requests under other
conditions. conditions.
4.4. Identifying Location Provenance 4.4. Identifying Location Provenance
An extension is made to the PIDF-LO [RFC4119] that allows a location An extension is made to the PIDF-LO [RFC4119] that allows a location
recipient to identify the source (or sources) of location information recipient to identify the source (or sources) of location information
and the measurement data that was used to determine that location and the measurement data that was used to determine that location
information. information.
The "source" element is added to the "geopriv" element of the PIDF- The "source" element is added to the "geopriv" element of the
LO. This element does not identify specific entities. Instead, it PIDF-LO. This element does not identify specific entities. Instead,
identifies the type of source. it identifies the type of measurement source.
The following types of measurement source are identified: The following values are defined for the "source" element:
lis: Location information is based on measurement data that the LIS lis: Location information is based on measurement data that the LIS
or sources that it trusts have acquired. This label MAY be used or sources that it trusts have acquired. This label MAY be used
if measurement data provided by the Device has been completely if measurement data provided by the Device has been completely
validated by the LIS. validated by the LIS.
device: A LIS MUST include this value if the location information is device: A LIS MUST include this value if the location information is
based (in whole or part) on measurement data provided by the based (in whole or in part) on measurement data provided by the
Device and if the measurement data isn't completely validated. Device and if the measurement data isn't completely validated.
other: Location information is based on measurement data that a other: Location information is based on measurement data that a
third party has provided. This might be an authorized third party third party has provided. This might be an authorized third party
that uses identity parameters [RFC6155] or any other entity. The that uses identity parameters [RFC6155] or any other entity. The
LIS MUST include this, unless the third party is trusted by the LIS MUST include this, unless the third party is trusted by the
LIS to provide measurement data. LIS to provide measurement data.
No assertion is made about the veracity of the measurement data from 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 sources other than the LIS. A combination of tags MAY be included to
indicate that measurement data from multiple types of sources was indicate that measurement data from multiple types of sources was
used. used.
For example, the first tuple of the following PIDF-LO indicates that 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 measurement data from a LIS and a Device was combined to produce the
result, the second tuple was produced by the LIS alone. result; the second tuple was produced by the LIS alone.
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc" xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
entity="pres:lm@example.com"> entity="pres:lm@example.com">
<tuple id="deviceLoc"> <tuple id="deviceLoc">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>7.34324 134.47162</gml:pos> <gml:pos>7.34324 134.47162</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24 850.24
</gs:radius> </gs:radius>
</gs:Circle> </gs:Circle>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<gp:method>OTDOA</gp:method> <gp:method>OTDOA</gp:method>
<lmsrc:source>lis device</lmsrc:source> <lmsrc:source>lis device</lmsrc:source>
</gp:geopriv> </gp:geopriv>
</status> </status>
</tuple> </tuple>
<tuple id="lisLoc"> <tuple id="lisLoc">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>7.34379 134.46484</gml:pos> <gml:pos>7.34379 134.46484</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
9000 9000
</gs:radius> </gs:radius>
</gs:Circle> </gs:Circle>
</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 </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 5. Location-Related Measurement Data Types
This document defines location-related measurement data types for a This document defines location-related measurement data types for a
range of common network types. range of common network types.
All included measurement data definitions allow for arbitrary All included measurement data definitions allow for arbitrary
extension in the corresponding schema. New parameters that are extension in the corresponding schema. New parameters that are
applicable to location determination are added as new XML elements in applicable to location determination are added as new XML elements in
a unique namespace, not by adding elements to an existing namespace. a unique namespace, not by adding elements to an existing namespace.
5.1. LLDP Measurements 5.1. LLDP Measurements
Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent
between adjacent nodes in an IEEE 802 network (e.g. wired Ethernet, between adjacent nodes in an IEEE 802 network (e.g., wired Ethernet,
WiFi, 802.16). These messages all contain identification information WiFi, 802.16). These messages all contain identification information
for the sending node, which can be used to determine location for the sending node; the identification information can be used to
information. A Device that receives LLDP messages can report this determine location information. A Device that receives LLDP messages
information as a location-related measurement to the LIS, which is can report this information as a location-related measurement to the
then able to use the measurement data in determining the location of LIS, which is then able to use the measurement data in determining
the Device. the location of the Device.
Note: The LLDP extensions defined in LLDP Media Endpoint Discovery Note: The LLDP extensions defined in LLDP Media Endpoint Discovery
(LLDP-MED) [ANSI-TIA-1057] provide the ability to acquire location (LLDP-MED) [ANSI-TIA-1057] provide the ability to acquire location
information directly from an LLDP endpoint. Where this information directly from an LLDP endpoint. Where this
information is available, it might be unnecessary to use any other information is available, it might be unnecessary to use any other
form of location configuration. form of location configuration.
Values are provided as hexadecimal sequences. The Device MUST report Values are provided as hexadecimal sequences. The Device MUST report
the values directly as they were provided by the adjacent node. the values directly as they were provided by the adjacent node.
Attempting to adjust or translate the type of identifier is likely to Attempting to adjust or translate the type of identifier is likely to
cause the measurement data to be useless. cause the measurement data to be useless.
Where a Device has received LLDP messages from multiple adjacent Where a Device has received LLDP messages from multiple adjacent
nodes, it should provide information extracted from those messages by nodes, it should provide information extracted from those messages by
repeating the "lldp" element. repeating the "lldp" element.
An example of an LLDP measurement is shown in Figure 4. This shows An example of an LLDP measurement is shown in Figure 4. This shows
an adjacent node (chassis) that is identified by the IP address an adjacent node (chassis) that is identified by the IP address
192.0.2.45 (hexadecimal c000022d) and the port on that node is 192.0.2.45 (hexadecimal c000022d), and the port on that node is
numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2). numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp"> <lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
<chassis type="4">c000022d</chassis> <chassis type="4">c000022d</chassis>
<port type="6">a2</port> <port type="6">a2</port>
</lldp> </lldp>
</measurements> </measurements>
Figure 4: LLDP Measurement Example Figure 4: LLDP Measurement Example
IEEE 802 Devices that are able to obtain information about adjacent IEEE 802 Devices that are able to obtain information about adjacent
network switches and their attachment to them by other means MAY use network switches and their attachment to them by other means MAY use
this data type to convey this information. this data type to convey this information.
5.2. DHCP Relay Agent Information Measurements 5.2. DHCP Relay Agent Information Measurements
The DHCP Relay Agent Information option [RFC3046] provides The DHCP Relay Agent Information option [RFC3046] provides
measurement data about the network attachment of a Device. This measurement data about the network attachment of a Device. This
measurement data can be included in the "dhcp-rai" element. measurement data can be included in the "dhcp-rai" element.
The elements in the DHCP relay agent information options are opaque The elements in the DHCP relay agent information options are opaque
data types assigned by the DHCP relay agent. The three items MAY be data types assigned by the DHCP relay agent. The three items MAY be
omitted if unknown: circuit identifier ("circuit", circuit [RFC3046], omitted if unknown: circuit identifier ("circuit", circuit [RFC3046],
Interface-Id [RFC3315]), remote identifier ("remote", Remote ID or Interface-Id [RFC3315]), remote identifier ("remote", Remote ID
[RFC3046], or remote-id [RFC4649]) and subscriber identifier [RFC3046], or remote-id [RFC4649]), and subscriber identifier
("subscriber", subscriber-id [RFC3993], Subscriber-ID [RFC4580]). ("subscriber", subscriber-id [RFC3993], or Subscriber-ID [RFC4580]).
The DHCPv6 remote-id has an associated enterprise number The DHCPv6 remote-id has an associated enterprise number
[IANA.enterprise] as an XML attribute. [IANA.enterprise] as an XML attribute.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<dhcp-rai xmlns="urn:ietf:params:xml:ns:geopriv:lm:dhcp"> <dhcp-rai xmlns="urn:ietf:params:xml:ns:geopriv:lm:dhcp">
<giaddr>192.0.2.158</giaddr> <giaddr>192.0.2.158</giaddr>
<circuit>108b</circuit> <circuit>108b</circuit>
</dhcp-rai> </dhcp-rai>
</measurements> </measurements>
Figure 5: DHCP Relay Agent Information Measurement Example Figure 5: DHCP Relay Agent Information Measurement Example
The "giaddr" is specified as a dotted quad IPv4 address or an RFC The "giaddr" element is specified as a dotted quad IPv4 address or an
4291 [RFC4291] IPv6 address, using the forms defined in [RFC3986]; RFC 4291 [RFC4291] IPv6 address, using the forms defined in
IPv6 addresses SHOULD use the form described in [RFC5952]. The [RFC3986]; IPv6 addresses SHOULD use the form described in [RFC5952].
enterprise number is specified as a decimal integer. All other The enterprise number is specified as a decimal integer. All other
information is included verbatim from the DHCP request in hexadecimal information is included verbatim from the DHCP request in hexadecimal
format. format.
The "subscriber" element could be considered sensitive. This The "subscriber" element could be considered sensitive. This
information MUST NOT be provided to a LIS that is not authorized to 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 receive information about the access network. See Section 7.1.3 for
more details. more details.
5.3. 802.11 WLAN Measurements 5.3. 802.11 WLAN Measurements
In WiFi, or 802.11 [IEEE.80211], networks a Device might be able to In WiFi, or 802.11 [IEEE.80211], networks, a Device might be able to
provide information about the access point (AP) that it is attached provide information about the access point (AP) to which it is
to, or other WiFi points it is able to see. This is provided using attached, or other WiFi points it is able to see. This is provided
the "wifi" element, as shown in Figure 6, which shows a single using the "wifi" element, as shown in Figure 6, which shows a single
complete measurement for a single access point. complete measurement for a single access point.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2011-04-29T14:33:58"> time="2011-04-29T14:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi"> <wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<nicType>Intel(r)PRO/Wireless 2200BG</nicType> <nicType>Intel(r)PRO/Wireless 2200BG</nicType>
<ap serving="true"> <ap serving="true">
<bssid>AB-CD-EF-AB-CD-EF</bssid> <bssid>AB-CD-EF-AB-CD-EF</bssid>
<ssid>example</ssid> <ssid>example</ssid>
<channel>5</channel> <channel>5</channel>
<location> <location>
<gml:Point xmlns:gml="http://opengis.net/gml"> <gml:Point xmlns:gml="http://opengis.net/gml">
<gml:pos>-34.4 150.8</gml:pos> <gml:pos>-34.4 150.8</gml:pos>
</gml:Point> </gml:Point>
</location> </location>
<type>a</type> <type>a</type>
<band>5</band> <band>5</band>
<regclass country="AU">2</regclass> <regclass country="AU">2</regclass>
<antenna>2</antenna> <antenna>2</antenna>
<flightTime rmsError="4e-9" samples="1">2.56e-9</flightTime> <flightTime rmsError="4e-9" samples="1">2.56e-9</flightTime>
<apSignal> <apSignal>
<transmit>23</transmit> <transmit>23</transmit>
<gain>5</gain> <gain>5</gain>
<rcpi dBm="true" rmsError="12" samples="1">-59</rcpi> <rcpi dBm="true" rmsError="12" samples="1">-59</rcpi>
<rsni rmsError="15" samples="1">23</rsni> <rsni rmsError="15" samples="1">23</rsni>
</apSignal> </apSignal>
<deviceSignal> <deviceSignal>
<transmit>10</transmit> <transmit>10</transmit>
<gain>9</gain> <gain>9</gain>
<rcpi dBm="true" rmsError="9.5" samples="1">-98.5</rcpi> <rcpi dBm="true" rmsError="9.5" samples="1">-98.5</rcpi>
<rsni rmsError="6" samples="1">7.5</rsni> <rsni rmsError="6" samples="1">7.5</rsni>
</deviceSignal> </deviceSignal>
</ap> </ap>
</wifi> </wifi>
</measurements> </measurements>
Figure 6: 802.11 WLAN Measurement Example Figure 6: 802.11 WLAN Measurement Example
A wifi element is made up of one or more access points, and a A "wifi" element is made up of one or more access points, and a
"nicType" element, which MAY be omitted. Each access point is "nicType" element, which MAY be omitted. Each access point is
described using the "ap" element, which is comprised of the following described using the "ap" element, which is comprised of the following
fields: fields:
bssid: The basic service set identifier. In an Infrastructure BSS bssid: The Basic Service Set (BSS) identifier. In an Infrastructure
network, the bssid is the 48 bit MAC address of the access point. BSS network, the bssid is the 48-bit MAC address of the access
point.
The "verified" attribute of this element describes whether the The "verified" attribute of this element describes whether the
device has verified the MAC address or it authenticated the access Device has verified the MAC address or it authenticated the access
point or the network operating the access point (for example, a point or the network operating the access point (for example, a
captive portal accessed through the access point has been captive portal accessed through the access point has been
authenticated). This attributes defaults to a value of "false" authenticated). This attribute defaults to a value of "false"
when omitted. when omitted.
ssid: The service set identifier (SSID) for the wireless network ssid: The service set identifier (SSID) for the wireless network
served by the access point. served by the access point.
The SSID is a 32-octet identifier that is commonly represented as The SSID is a 32-octet identifier that is commonly represented as
a ASCII [ASCII] or UTF-8 [RFC3629] encoded string. To represent an ASCII [ASCII] or UTF-8 [RFC3629] encoded string. To represent
octets that cannot be directly included in an XML element, octets that cannot be directly included in an XML element,
escaping is used. Sequences of octets that do not represent a escaping is used. Sequences of octets that do not represent a
valid UTF-8 encoding can be escaped using a backslash ('\') valid UTF-8 encoding can be escaped using a backslash ('\')
followed by two case-insensitive hexadecimal digits representing followed by two case-insensitive hexadecimal digits representing
the value of a single octet. the value of a single octet.
The canonical or value-space form of an SSID is a sequence of up 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 to 32 octets that is produced from the concatenation of UTF-8
encoded sequences of unescaped characters and octets derived from encoded sequences of unescaped characters and octets derived from
escaped components. escaped components.
channel: The channel number (frequency) that the access point channel: The channel number (frequency) on which the access point
operates on. operates.
location: The location of the access point, as reported by the location: The location of the access point, as reported by the
access point. This element contains any valid location, using the access point. This element contains any valid location, using the
rules for a "location-info" element, as described in [RFC5491]. rules for a "location-info" element, as described in [RFC5491].
type: The network type for the network access. This element type: The network type for the network access. This element
includes the alphabetic suffix of the 802.11 specification that includes the alphabetic suffix of the 802.11 specification that
introduced the radio interface, or PHY; e.g. "a", "b", "g", or introduced the radio interface, or PHY, e.g., "a", "b", "g",
"n". or "n".
band: The frequency band for the radio, in gigahertz (GHz). 802.11 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 [IEEE.80211] specifies PHY layers that use 2.4, 3.7, and 5
gigahertz frequency bands. gigahertz frequency bands.
regclass: The operating class (regulatory domain and class in older regclass: The operating class (regulatory domain and class in older
versions in 802.11), see Annex E of [IEEE.80211]. The "country" versions of 802.11); see Annex E of [IEEE.80211]. The "country"
attribute optionally includes the applicable two character country attribute optionally includes the applicable two-character country
identifier (dot11CountryString), which can be followed by an 'O', identifier (dot11CountryString), which can be followed by an 'O',
'I' or 'X'. The element text content includes the value of the 'I', or 'X'. The element text content includes the value of the
regulatory class: an 8-bit integer in decimal form. regulatory class: an 8-bit integer in decimal form.
antenna: The antenna identifier for the antenna that the access antenna: The antenna identifier for the antenna that the access
point is using to transmit the measured signals. point is using to transmit the measured signals.
flightTime: Flight time is the difference between the time of flightTime: Flight time is the difference between the time of
departure (TOD) of signal from a transmitting station and time of departure (TOD) of signal from a transmitting station and time of
arrival (TOA) of signal at a receiving station, as defined in arrival (TOA) of signal at a receiving station, as defined in
[IEEE.80211]. Measurement of this value requires that stations [IEEE.80211]. Measurement of this value requires that stations
synchronize their clocks. This value can be measured by access synchronize their clocks. This value can be measured by an access
point or Device; because the flight time is assumed to be the same point or Device; because the flight time is assumed to be the same
in either direction - aside from measurement errors - only a in either direction -- aside from measurement errors -- only a
single element is provided. This element permits the use of the single element is provided. This element permits the use of the
"rmsError" and "samples" attributes. RMS error might be derived "rmsError" and "samples" attributes. RMS error might be derived
from the reported RMS error in TOD and TOA. from the reported RMS error in TOD and TOA.
apSignal: Measurement information for the signal transmitted by the apSignal: Measurement information for the signal transmitted by the
access point, as observed by the Device. Some of these values are access point, as observed by the Device. Some of these values are
derived from 802.11v [IEEE.80211] messages exchanged between derived from 802.11v [IEEE.80211] messages exchanged between the
Device and access point. The contents of this element include: Device and access point. The contents of this element include:
transmit: The transmit power reported by the access point, in transmit: The transmit power reported by the access point,
dBm. in dBm.
gain: The gain of the access point antenna reported by the access gain: The gain of the access point antenna reported by the access
point, in dB. point, in dB.
rcpi: The received channel power indicator for the access point rcpi: The received channel power indicator for the access point
signal, as measured by the Device. This value SHOULD be in signal, as measured by the Device. This value SHOULD be in
units of dBm (with RMS error in dB). If power is measured units of dBm (with RMS error in dB). If power is measured in a
in a different fashion, the "dBm" attribute MUST be set to different fashion, the "dBm" attribute MUST be set to "false".
"false". Signal strength reporting on current hardware uses Signal strength reporting on current hardware uses a range of
a range of different mechanisms; therefore, the value of the different mechanisms; therefore, the value of the "nicType"
"nicType" element SHOULD be included if the units are not element SHOULD be included if the units are not known to be in
known to be in dBm and the value reported by the hardware dBm, and the value reported by the hardware should be included
should be included without modification. This element without modification. This element permits the use of the
permits the use of the "rmsError" and "samples" attributes. "rmsError" and "samples" attributes.
rsni: The received signal to noise indicator in dB. This element rsni: The received signal-to-noise indicator in dB. This element
permits the use of the "rmsError" and "samples" attributes. permits the use of the "rmsError" and "samples" attributes.
deviceSignal: Measurement information for the signal transmitted by deviceSignal: Measurement information for the signal transmitted by
the device, as reported by the access point. This element the Device, as reported by the access point. This element
contains the same child elements as the "ap" element, with the contains the same child elements as the "ap" element, with the
access point and Device roles reversed. access point and Device roles reversed.
The only mandatory element in this structure is "bssid". The only mandatory element in this structure is "bssid".
The "nicType" element is used to specify the make and model of the The "nicType" element is used to specify the make and model of the
wireless network interface in the Device. Different 802.11 chipsets wireless network interface in the Device. Different 802.11 chipsets
report measurements in different ways, so knowing the network report measurements in different ways, so knowing the network
interface type aids the LIS in determining how to use the provided interface type aids the LIS in determining how to use the provided
measurement data. The content of this field is unconstrained and no measurement data. The content of this field is unconstrained, and no
mechanisms are specified to ensure uniqueness. This field is mechanisms are specified to ensure uniqueness. This field is
unlikely to be useful, except under tightly controlled circumstances. unlikely to be useful, except under tightly controlled circumstances.
5.3.1. Wifi Measurement Requests 5.3.1. WiFi Measurement Requests
Two elements are defined for requesting WiFi measurements in a Two elements are defined for requesting WiFi measurements in a
measurement request: measurement request:
type: The "type" element identifies the desired type (or types that type: The "type" element identifies the desired type (or types that
are requested). are requested).
parameter: The "parameter" element identifies measurements that are parameter: The "parameter" element identifies measurements that are
requested for each measured access point. An element is requested for each measured access point. An element is
identified by its qualified name. The "context" parameter can be identified by its qualified name. The "context" parameter can be
used to specify if an element is included as a child of the "ap" used to specify if an element is included as a child of the "ap"
or "device" elements; omission indicates that it applies to both. or "device" elements; omission indicates that it applies to both.
Multiple types or parameters can be requested by repeating either Multiple types or parameters can be requested by repeating either
element. element.
5.4. Cellular Measurements 5.4. Cellular Measurements
Cellular Devices are common throughout the world and base station Cellular Devices are common throughout the world, and base station
identifiers can provide a good source of coarse location information. identifiers can provide a good source of coarse location information.
Cellular measurements can be provided to a LIS run by the cellular Cellular measurements can be provided to a LIS run by the cellular
operator, or may be provided to an alternative LIS operator that has operator, or may be provided to an alternative LIS operator that has
access to one of several global cell-id to location mapping access to one of several global cell-id to location mapping
databases. databases.
A number of advanced location determination methods have been A number of advanced location determination methods have been
developed for cellular networks. For these methods a range of developed for cellular networks. For these methods, a range of
measurement parameters can be collected by the network, Device, or measurement parameters can be collected by the network, Device, or
both in cooperation. This document includes a basic identifier for both in cooperation. This document includes a basic identifier for
the wireless transmitter only; future efforts might define additional the wireless transmitter only; future efforts might define additional
parameters that enable more accurate methods of location parameters that enable more accurate methods of location
determination. determination.
The cellular measurement set allows a Device to report to a LIS any 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) 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 cells that it is able to observe. Cells are reported using their
global identifiers. All 3GPP cells are identified by public land global identifiers. All Third Generation Partnership Project (3GPP)
mobile network (PLMN), which is formed of mobile country code (MCC) cells are identified by a public land mobile network (PLMN), which
and mobile network code (MNC); specific fields are added for each comprises a mobile country code (MCC) and mobile network code (MNC);
network type. specific fields are added for each network type.
Formats for 3GPP cell identifiers are described in [TS.3GPP.23.003]. Formats for 3GPP cell identifiers are described in [TS.3GPP.23.003].
Bit-level formats for CDMA cell identifiers are described in Bit-level formats for CDMA cell identifiers are described in
[TIA-2000.5]; decimal representations are used. [TIA-2000.5]; decimal representations are used.
MCC and MNC are provided as decimal digit sequences; a leading zero MCC and MNC are provided as decimal digit sequences; a leading zero
in an MCC or MNC is significant. All other values are decimal in an MCC or MNC is significant. All other values are decimal
integers. integers.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell"> <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell> <servingCell>
<mcc>465</mcc><mnc>20</mnc><eucid>80936424</eucid> <mcc>465</mcc><mnc>20</mnc><eucid>80936424</eucid>
</servingCell> </servingCell>
<observedCell> <observedCell>
<mcc>465</mcc><mnc>06</mnc><eucid>10736789</eucid> <mcc>465</mcc><mnc>06</mnc><eucid>10736789</eucid>
</observedCell> </observedCell>
</cellular> </cellular>
</measurements> </measurements>
Long term evolution (LTE) cells are identified by a 28-bit cell Long term evolution (LTE) cells are identified by a 28-bit cell
identifier (eucid). identifier (eucid).
Figure 7: Example LTE Cellular Measurement Figure 7: Example LTE Cellular Measurement
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell"> <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell> <servingCell>
<mcc>465</mcc><mnc>20</mnc> <mcc>465</mcc><mnc>20</mnc>
<rnc>2000</rnc><cid>65000</cid> <rnc>2000</rnc><cid>65000</cid>
</servingCell> </servingCell>
<observedCell> <observedCell>
<mcc>465</mcc><mnc>06</mnc> <mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid> <lac>16383</lac><cid>32767</cid>
</observedCell> </observedCell>
</cellular> </cellular>
</measurements> </measurements>
Universal mobile telephony service (UMTS) cells are identified by 12- Universal mobile telephony service (UMTS) cells are identified by a
or 16-bit radio network controller (rnc) id and a 16-bit cell id 12- or 16-bit radio network controller (rnc) id and a 16-bit cell id
(cid). (cid).
Figure 8: Example UMTS Cellular Measurement Figure 8: Example UMTS Cellular Measurement
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell"> <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell> <servingCell>
<mcc>465</mcc><mnc>06</mnc> <mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid> <lac>16383</lac><cid>32767</cid>
</servingCell> </servingCell>
</cellular>
</cellular> </measurements>
</measurements>
Global System for Mobile communication (GSM) cells are identified by Global System for Mobile communication (GSM) cells are identified by
a 16-bit location area code (lac) and 16-bit cell id (cid). a 16-bit location area code (lac) and a 16-bit cell id (cid).
Figure 9: Example GSM Cellular Measurement Figure 9: Example GSM Cellular Measurement
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell"> <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell> <servingCell>
<sid>15892</sid><nid>4723</nid><baseid>12</baseid> <sid>15892</sid><nid>4723</nid><baseid>12</baseid>
</servingCell> </servingCell>
<observedCell> <observedCell>
<sid>15892</sid><nid>4723</nid><baseid>13</baseid> <sid>15892</sid><nid>4723</nid><baseid>13</baseid>
</observedCell> </observedCell>
</cellular> </cellular>
</measurements> </measurements>
Code division multiple access (CDMA) cells are not identified by 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 PLMN; instead, these use a 15-bit system id (sid), a 16-bit network
(nid) and a 16-bit base station id (baseid). id (nid), and a 16-bit base station id (baseid).
Figure 10: Example CDMA Cellular Measurement Figure 10: Example CDMA Cellular Measurement
In general, a cellular Device will be attached to the cellular In general, a cellular Device will be attached to the cellular
network and so the notion of a serving cell exists. Cellular network network, so the notion of a serving cell exists. Cellular networks
also provide overlap between neighbouring sites, so a mobile Device also provide overlap between neighboring sites, so a mobile Device
can hear more than one cell. The measurement schema supports sending can hear more than one cell. The measurement schema supports sending
both the serving cell and any other cells that the mobile might be 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 able to hear. In some cases, the Device could simply be listening to
cell information without actually attaching to the network, mobiles cell information without actually attaching to the network; mobiles
without a SIM are an example of this. In this case the Device could 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 report cells it can hear without identifying any particular cell as a
serving cell. An example of this is shown in Figure 11. serving cell. An example of this is shown in Figure 11.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell"> <cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<observedCell> <observedCell>
<mcc>465</mcc><mnc>20</mnc> <mcc>465</mcc><mnc>20</mnc>
<rnc>2000</rnc><cid>65000</cid> <rnc>2000</rnc><cid>65000</cid>
</observedCell> </observedCell>
<observedCell> <observedCell>
<mcc>465</mcc><mnc>06</mnc> <mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid> <lac>16383</lac><cid>32767</cid>
</observedCell> </observedCell>
</cellular>
</cellular> </measurements>
</measurements>
Figure 11: Example Observed Cellular Measurement Figure 11: Example Observed Cellular Measurement
5.4.1. Cellular Measurement Requests 5.4.1. Cellular Measurement Requests
Two elements can be used in measurement requests for cellular Two elements can be used in measurement requests for cellular
measurements: measurements:
type: A label indicating the type of identifier to provide: one of type: A label indicating the type of identifier to provide: one of
"gsm", "umts", "lte", or "cdma". "gsm", "umts", "lte", or "cdma".
skipping to change at page 23, line 12 skipping to change at page 23, line 5
satellite constellation to determine the location of the receiver satellite constellation to determine the location of the receiver
and the current time. and the current time.
A Device that uses a GNSS receiver is able to report measurements 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 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 these measurements to determine a location. In the case where there
are fewer results available than the optimal minimum, the LIS might are fewer results available than the optimal minimum, the LIS might
be able to use other sources of measurement information and combine be able to use other sources of measurement information and combine
these with the available measurement data to determine a position. these with the available measurement data to determine a position.
Note: The use of different sets of GNSS _assistance data_ can Note: The use of different sets of GNSS assistance data can reduce
reduce the amount of time required for the signal acquisition the amount of time required for the signal acquisition stage and
stage and obviate the need for the receiver to extract data on the obviate the need for the receiver to extract data on the satellite
satellite constellation. Provision of assistance data is outside constellation. Provision of assistance data is outside the scope
the scope of this document. of this document.
Figure 12 shows an example of GNSS measurement data. The measurement Figure 12 shows an example of GNSS measurement data. The measurement
shown is for the GPS system and includes measurement data for three shown is for the GPS satellite system and includes measurement data
satellites only. for three satellites only.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58" timeError="2e-5"> time="2008-04-29T14:33:58" timeError="2e-5">
<gnss xmlns="urn:ietf:params:xml:ns:geopriv:lm:gnss" <gnss xmlns="urn:ietf:params:xml:ns:geopriv:lm:gnss"
system="gps" signal="L1"> system="gps" signal="L1">
<sat num="19"> <sat num="19">
<doppler>499.9395</doppler> <doppler>499.9395</doppler>
<codephase rmsError="1.6e-9">0.87595747</codephase> <codephase rmsError="1.6e-9">0.87595747</codephase>
<cn0>45</cn0> <cn0>45</cn0>
</sat> </sat>
<sat num="27"> <sat num="27">
<doppler>378.2657</doppler> <doppler>378.2657</doppler>
<codephase rmsError="1.6e-9">0.56639479</codephase> <codephase rmsError="1.6e-9">0.56639479</codephase>
<cn0>52</cn0> <cn0>52</cn0>
</sat> </sat>
<sat num="20"> <sat num="20">
<doppler>-633.0309</doppler> <doppler>-633.0309</doppler>
<codephase rmsError="1.6e-9">0.57016835</codephase> <codephase rmsError="1.6e-9">0.57016835</codephase>
<cn0>48</cn0> <cn0>48</cn0>
</sat> </sat>
</gnss> </gnss>
</measurements> </measurements>
Figure 12: Example GNSS Measurement Figure 12: Example GNSS Measurement
Each "gnss" element represents a single set of GNSS measurement data, Each "gnss" element represents a single set of GNSS measurement data,
taken at a single point in time. Measurements taken at different taken at a single point in time. Measurements taken at different
times can be included in different "gnss" elements to enable times can be included in different "gnss" elements to enable
iterative refinement of results. iterative refinement of results.
GNSS measurement parameters are described in more detail in the GNSS measurement parameters are described in more detail in the
following sections. following sections.
5.5.1. GNSS System and Signal 5.5.1. GNSS: System Type and Signal
The GNSS measurement structure is designed to be generic and to apply The GNSS measurement structure is designed to be generic and to apply
to different GNSS types. Different signals within those systems are to different GNSS types. Different signals within those systems are
also accounted for and can be measured separately. also accounted for and can be measured separately.
The GNSS type determines the time system that is used. An indication 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 of the type of system and signal can ensure that the LIS is able to
correctly use measurements. correctly use measurements.
Measurements for multiple GNSS types and signals can be included by Measurements for multiple GNSS types and signals can be included by
skipping to change at page 24, line 50 skipping to change at page 24, line 44
error for any time that is provided. An RMS error can be included error for any time that is provided. An RMS error can be included
for the "gnssTime" element, with a value in milliseconds. for the "gnssTime" element, with a value in milliseconds.
5.5.3. Per-Satellite Measurement Data 5.5.3. Per-Satellite Measurement Data
Multiple satellites are included in each set of GNSS measurements Multiple satellites are included in each set of GNSS measurements
using the "sat" element. Each satellite is identified by a number in using the "sat" element. Each satellite is identified by a number in
the "num" attribute. The satellite number is consistent with the the "num" attribute. The satellite number is consistent with the
identifier used in the given GNSS. identifier used in the given GNSS.
Both the GPS and Galileo systems use satellite numbers between 1 and Both the GPS and Galileo systems use satellite numbers between 1
64. and 64.
The GNSS receiver measures the following parameters for each The GNSS receiver measures the following parameters for each
satellite: satellite:
doppler: The observed Doppler shift of the satellite signal, doppler: The observed Doppler shift of the satellite signal,
measured in meters per second. This is converted from a value in measured in meters per second. This is converted from a value in
Hertz by the receiver to allow the measurement to be used without Hertz by the receiver to allow the measurement to be used without
knowledge of the carrier frequency of the satellite system. This knowledge of the carrier frequency of the satellite system. This
value permits the use of RMS error attributes, also measured in value permits the use of RMS error attributes, also measured in
meters per second. meters per second.
codephase: The observed code phase for the satellite signal, codephase: The observed code phase for the satellite signal,
measured in milliseconds. This is converted from the system- measured in milliseconds. This is converted from the system-
specific value of chips or wavelengths into a system independent specific value of chips or wavelengths into a system-independent
value. Larger values indicate larger distances from satellite to value. Larger values indicate larger distances from satellite to
receiver. This value permits the use of RMS error attributes, receiver. This value permits the use of RMS error attributes,
also measured in milliseconds. also measured in milliseconds.
cn0: The signal to noise ratio for the satellite signal, measured in cn0: The signal-to-noise ratio for the satellite signal, measured in
decibel-Hertz (dB-Hz). The expected range is between 20 and 50 decibel-Hertz (dB-Hz). The expected range is between 20 and
dB-Hz. 50 dB-Hz.
mp: An estimation of the amount of error that multipath signals mp: An estimation of the amount of error that multipath signals
contribute in meters. This parameter MAY be omitted. contribute in meters. This parameter MAY be omitted.
cq: An indication of the carrier quality. Two attributes are cq: An indication of the carrier quality. Two attributes are
included: "continuous" can be either "true" or "false"; direct can included: "continuous" (which can be either "true" or "false") and
be either "direct" or "inverted". This parameter MAY be omitted. "direct" (which can be either "direct" or "inverted"). This
parameter MAY be omitted.
adr: The accumulated Doppler range, measured in meters. This adr: The accumulated Doppler range, measured in meters. This
parameter MAY be omitted and is not useful unless multiple sets of parameter MAY be omitted and is not useful unless multiple sets of
GNSS measurements are provided or differential positioning is GNSS measurements are provided or differential positioning is
being performed. being performed.
All values are converted from measures native to the satellite system All values are converted from measures native to the satellite system
to generic measures to ensure consistency of interpretation. Unless to generic measures to ensure consistency of interpretation. Unless
necessary, the schema does not constrain these values. necessary, the schema does not constrain these values.
5.5.4. GNSS Measurement Requests 5.5.4. GNSS Measurement Requests
Measurement requests can include a "gnss" element, which includes the Measurement requests can include a "gnss" element, which includes the
"system" and "signal" attributes. Multiple elements can be included "system" and "signal" attributes. Multiple elements can be included
to indicate a requests for GNSS measurements from multiple systems or to indicate requests for GNSS measurements from multiple systems or
signals. signals.
5.6. DSL Measurements 5.6. DSL Measurements
Digital Subscriber Line (DSL) networks rely on a range of network Digital Subscriber Line (DSL) networks rely on a range of network
technologies. DSL deployments regularly require cooperation between technologies. DSL deployments regularly require cooperation between
multiple organizations. These fall into two broad categories: multiple organizations. These fall into two broad categories:
infrastructure providers and Internet service providers (ISPs). For infrastructure providers and Internet service providers (ISPs). For
the same end user, an infrastructure and Internet service can be the same end user, an infrastructure and Internet service can be
provided by different entities. Infrastructure providers manage the provided by different entities. Infrastructure providers manage the
bulk of the physical infrastructure including cabling. End users bulk of the physical infrastructure, including cabling. End users
obtain their service from an ISP, which manages all aspects visible obtain their service from an ISP, which manages all aspects visible
to the end user including IP address allocation and operation of a to the end user, including IP address allocation and operation of a
LIS. See [DSL.TR025] and [DSL.TR101] for further information on DSL LIS. See [DSL.TR025] and [DSL.TR101] for further information on DSL
network deployments and the parameters that are available. network deployments and the parameters that are available.
Exchange of measurement information between these organizations is Exchange of measurement information between these organizations is
necessary for location information to be correctly generated. The necessary for location information to be correctly generated. The
ISP LIS needs to acquire location information from the infrastructure ISP LIS needs to acquire location information from the infrastructure
provider. However, since the infrastructure provider could have no provider. However, since the infrastructure provider could have no
knowledge of Device identifiers, it can only identify a stream of knowledge of Device identifiers, it can only identify a stream of
data that is sent to the ISP. This is resolved by passing data that is sent to the ISP. This is resolved by passing
measurement data relating to the Device to a LIS operated by the measurement data relating to the Device to a LIS operated by the
infrastructure provider. infrastructure provider.
5.6.1. L2TP Measurements 5.6.1. L2TP Measurements
Layer 2 Tunneling Protocol (L2TP) [RFC2661] is a common means of The Layer 2 Tunneling Protocol (L2TP) [RFC2661] is a common means of
linking the infrastructure provider and the ISP. The infrastructure linking the infrastructure provider and the ISP. The infrastructure
provider LIS requires measurement data that identifies a single L2TP provider LIS requires measurement data that identifies a single L2TP
tunnel, from which it can generate location information. Figure 13 tunnel, from which it can generate location information. Figure 13
shows an example L2TP measurement. shows an example L2TP measurement.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl"> <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<l2tp> <l2tp>
<src>192.0.2.10</src> <src>192.0.2.10</src>
<dest>192.0.2.61</dest> <dest>192.0.2.61</dest>
<session>528</session> <session>528</session>
</l2tp> </l2tp>
</dsl> </dsl>
</measurements> </measurements>
Figure 13: Example DSL L2TP Measurement Figure 13: Example DSL L2TP Measurement
5.6.2. RADIUS Measurements 5.6.2. RADIUS Measurements
When authenticating network access, the infrastructure provider might When authenticating network access, the infrastructure provider might
employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or
Access Node (AN). These messages provide the ISP RADIUS server with Access Node (AN). These messages provide the ISP RADIUS server with
an identifier for the DSLAM or AN, plus the slot and port that the an identifier for the DSLAM or AN, plus the slot and port to which
Device is attached to. These data can be provided as a measurement, the Device is attached. These data can be provided as a measurement
which allows the infrastructure provider LIS to generate location that allows the infrastructure provider LIS to generate location
information. information.
The format of the AN, slot and port identifiers are not defined in The format of the AN, slot, and port identifiers is not defined in
the RADIUS protocol. Slot and port together identify a circuit on the RADIUS protocol. The slot and port together identify a circuit
the AN, analogous to the circuit identifier in [RFC3046]. These on the AN, analogous to the circuit identifier in [RFC3046]. These
items are provided directly, as they were in the RADIUS message. An items are provided directly, as they would be in the RADIUS message.
example is shown in Figure 14. An example is shown in Figure 14.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl"> <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<an>AN-7692</an> <an>AN-7692</an>
<slot>3</slot> <slot>3</slot>
<port>06</port> <port>06</port>
</dsl> </dsl>
</measurements> </measurements>
Figure 14: Example DSL RADIUS Measurement Figure 14: Example DSL RADIUS Measurement
5.6.3. Ethernet VLAN Tag Measurements 5.6.3. Ethernet VLAN Tag Measurements
For Ethernet-based DSL access networks, the DSL Access Module (DSLAM) For Ethernet-based DSL access networks, the DSLAM or AN provides two
or Access Node (AN) provide two VLAN tags on packets. A C-TAG is VLAN tags on packets. A C-TAG is used to identify the incoming
used to identify the incoming residential circuit, while the S-TAG is residential circuit, while the S-TAG is used to identify the DSLAM or
used to identify the DSLAM or AN. The C-TAG and S-TAG together can AN. The C-TAG and S-TAG together can be used to identify a single
be used to identify a single point of network attachment. An example point of network attachment. An example is shown in Figure 15.
is shown in Figure 15.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl"> <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<stag>613</stag> <stag>613</stag>
<ctag>1097</ctag> <ctag>1097</ctag>
</dsl> </dsl>
</measurements> </measurements>
Figure 15: Example DSL VLAN Tag Measurement Figure 15: Example DSL VLAN Tag Measurement
Alternatively, the C-TAG can be replaced by data on the slot and port Alternatively, the C-TAG can be replaced by data on the slot and port
that the Device is attached to. This information might be included to which the Device is attached. This information might be included
in RADIUS requests that are proxied from the infrastructure provider in RADIUS requests that are proxied from the infrastructure provider
to the ISP RADIUS server. to the ISP RADIUS server.
5.6.4. ATM Virtual Circuit Measurements 5.6.4. ATM Virtual Circuit Measurements
An ATM virtual circuit can be employed between the ISP and An ATM virtual circuit can be employed between the ISP and
infrastructure provider. Providing the virtual port ID (VPI) and infrastructure provider. Providing the virtual port ID (VPI) and
virtual circuit ID (VCI) for the virtual circuit gives the virtual circuit ID (VCI) for the virtual circuit gives the
infrastructure provider LIS the ability to identify a single data infrastructure provider LIS the ability to identify a single data
stream. A sample measurement is shown in Figure 16. stream. A sample measurement is shown in Figure 16.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm" <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"> time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl"> <dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<vpi>55</vpi> <vpi>55</vpi>
<vci>6323</vci> <vci>6323</vci>
</dsl> </dsl>
</measurements> </measurements>
Figure 16: Example DSL ATM Measurement Figure 16: Example DSL ATM Measurement
6. Privacy Considerations 6. Privacy Considerations
Location-related measurement data can be as privacy sensitive as Location-related measurement data can be as privacy sensitive as
location information [RFC6280]. location information [RFC6280].
Measurement data is effectively equivalent to location information if Measurement data is effectively equivalent to location information if
the contextual knowledge necessary to generate one from the other is the contextual knowledge necessary to generate one from the other is
readily accessible. Even where contextual knowledge is difficult to readily accessible. Even where contextual knowledge is difficult to
acquire, there can be no assurance that an authorized recipient of acquire, there can be no assurance that an authorized recipient of
the contextual knowledge is also authorized to receive location the contextual knowledge is also authorized to receive location
information. information.
In order to protect the privacy of the subject of location-related In order to protect the privacy of the subject of location-related
measurement data, measurement data MUST be protected with the same measurement data, measurement data MUST be protected with the same
degree of protection as location information. The confidentiality degree of protection as location information. The confidentiality
and authentication provided by TLS MUST be used in order to convey and authentication provided by Transport Layer Security (TLS) MUST be
measurement data over HELD [RFC5985]. Other protocols MUST provide used in order to convey measurement data over HELD [RFC5985]. Other
comparable guarantees. protocols MUST provide comparable guarantees.
6.1. Measurement Data Privacy Model 6.1. Measurement Data Privacy Model
It is not necessary to distribute measurement data in the same It is not necessary to distribute measurement data in the same
fashion as location information. Measurement data is less useful to fashion as location information. Measurement data is less useful to
location recipients than location information. A simple distribution location recipients than location information. A simple distribution
model is described in this document. model is described in this document.
In this simple model, the Device is the only entity that is able to In this simple model, the Device is the only entity that is able to
distribute measurement data. To use an analogy from the GEOPRIV distribute measurement data. To use an analogy from the GEOPRIV
architecture, the Device - as the Location Generator, or the architecture, the Device -- as the Location Generator or the
Measurement Data Generator - is the sole entity that can act for the Measurement Data Generator -- is the sole entity that can act in the
role of both Rule Maker and Location Server. role of both Rule Maker and Location Server.
A Device that provides location-related measurement data, MUST only A Device that provides location-related measurement data MUST only do
do so as explicitly authorized by a Rule Maker. This depends on so as explicitly authorized by a Rule Maker. This depends on having
having an interface that allows Rule Makers (for instance, users or an interface that allows Rule Makers (for instance, users or
administrators) to control where and how measurement data is administrators) to control where and how measurement data is
provided. provided.
No entity is permitted to redistribute measurement data. The Device No entity is permitted to redistribute measurement data. The Device
directs other entities in how measurement data is used and retained. directs other entities regarding how measurement data is used and
retained.
The GEOPRIV model [RFC6280] protects the location of a Target using The GEOPRIV model [RFC6280] protects the location of a Target using
direction provided by a Rule Maker. For the purposes of measurement direction provided by a Rule Maker. For the purposes of measurement
data distribution, this model relies on the assumptions made in data distribution, this model relies on the assumptions made in
Section 3 of HELD [RFC5985]. These assumptions effectively declare Section 3 of HELD [RFC5985]. These assumptions effectively declare
the Device to be a proxy for both Target and Rule Maker. the Device to be a proxy for both Target and Rule Maker.
6.2. LIS Privacy Requirements 6.2. LIS Privacy Requirements
A LIS MUST NOT reveal location-related measurement data to any other A LIS MUST NOT reveal location-related measurement data to any other
skipping to change at page 30, line 5 skipping to change at page 30, line 8
6.3. Measurement Data and Location URIs 6.3. Measurement Data and Location URIs
A LIS MAY use measurement data provided by the Device to serve A LIS MAY use measurement data provided by the Device to serve
requests to location URIs, if the Device permits it. A Device requests to location URIs, if the Device permits it. A Device
permits this by including measurement data in a request that permits this by including measurement data in a request that
explicitly requests a location URI. By requesting a location URI, explicitly requests a location URI. By requesting a location URI,
the Device grants permission for the LIS to use the measurement data the Device grants permission for the LIS to use the measurement data
in serving requests to that location URI. The LIS cannot provide in serving requests to that location URI. The LIS cannot provide
location recipients with measurement data, as defined in Section 6.1. location recipients with measurement data, as defined in Section 6.1.
Note: In HELD, the "any" type is not an explicit request for a Note: In HELD, the "any" type is not an explicit request for a
location URI, though a location URI might be provided. location URI, though a location URI might be provided.
The usefulness of measurement data that is provided in this fashion The usefulness of measurement data that is provided in this fashion
is limited. The measurement data is only valid at the time that it 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 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 location URI, the Device might have moved, rendering the measurement
data incorrect. data incorrect.
A Device is able to explicitly limit the time that a LIS retains 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 measurement data by adding an expiry time to the measurement data. A
LIS MUST NOT retain location-related measurement data in memory, LIS MUST NOT retain location-related measurement data in memory,
storage or logs beyond the time indicated in the "expires" attribute storage, or logs beyond the time indicated in the "expires" attribute
(Section 4.1.2). A LIS MUST NOT retain measurement data if the (Section 4.1.2). A LIS MUST NOT retain measurement data if the
"expires" attribute is absent. "expires" attribute is absent.
6.4. Third-Party-Provided Measurement Data 6.4. Measurement Data Provided by a Third Party
An authorized third-party request for the location of a Device (see An authorized third-party request for the location of a Device (see
[RFC6155]) can include location-related measurement data. This is [RFC6155]) can include location-related measurement data. This is
possible where the third-party is able to make observations about the possible where the third party is able to make observations about the
Device. Device.
A third-party that provides measurement data MUST be authorized to A third party that provides measurement data MUST be authorized to
provide the specific measurement for the identified device. A third- provide the specific measurement for the identified Device. Either a
party MUST either be trusted by the LIS for the purposes of providing third party MUST be trusted by the LIS for the purposes of providing
measurement data of the provided type, or the measurement data MUST measurement data of the provided type, or the measurement data MUST
be validated (see Section 7.2.1) before being used. be validated (see Section 7.2.1) before being used.
How a third-party authenticates its identity or gains authorization How a third party authenticates its identity or gains authorization
to use measurement data is not covered by this document. to use measurement data is not covered by this document.
7. Security Considerations 7. Security Considerations
Use of location-related measurement data has privacy considerations The use of location-related measurement data has privacy
that are discussed in Section 6. considerations that are discussed in Section 6.
7.1. Threat Model 7.1. Threat Model
The threat model for location-related measurement data concentrates The threat model for location-related measurement data concentrates
on the Device providing falsified, stolen or incorrect measurement on the Device providing falsified, stolen, or incorrect measurement
data. data.
A Device that provides location-related measurement data might use A Device that provides location-related measurement data might use
data to: data to:
o acquire the location of another Device, without authorization; o acquire the location of another Device, without authorization;
o extract information about network topology; or o extract information about network topology; or
o coerce the LIS into providing falsified location information based o coerce the LIS into providing falsified location information based
on the measurement data. on the measurement data.
Location-related measurement data describes the physical environment Location-related measurement data describes the physical environment
or network attachment of a Device. A third party adversary in the or network attachment of a Device. A third-party adversary in the
proximity of the Device might be able to alter the physical proximity of the Device might be able to alter the physical
environment such that the Device provides measurement data that is environment such that the Device provides measurement data that is
controlled by the third party. This might be used to indirectly controlled by the third party. This might be used to indirectly
control the location information that is derived from measurement control the location information that is derived from measurement
data. data.
7.1.1. Acquiring Location Information Without Authorization 7.1.1. Acquiring Location Information without Authorization
Requiring authorization for location requests is an important part of Requiring authorization for location requests is an important part of
privacy protections of a location protocol. A location configuration privacy protections of a location protocol. A location configuration
protocol usually operates under a restricted policy that allows a protocol usually operates under a restricted policy that allows a
requester to obtain their own location. HELD identity extensions requester to obtain their own location. HELD identity extensions
[RFC6155] allows other entities to be authorized, conditional on a [RFC6155] allow other entities to be authorized, conditional on a
Rule Maker providing sufficient authorization. Rule Maker providing sufficient authorization.
The intent of these protections is to ensure that a location The intent of these protections is to ensure that a location
recipient is authorized to acquire location information. Location- recipient is authorized to acquire location information. Location-
related measurement data could be used by an attacker to circumvent related measurement data could be used by an attacker to circumvent
such authorization checks if the association between measurement data such authorization checks if the association between measurement data
and Target Device is not validated by a LIS. and Target Device is not validated by a LIS.
A LIS can be coerced into providing location information for a Device A LIS can be coerced into providing location information for a Device
that a location recipient is not authorized to receive. A request that a location recipient is not authorized to receive. A request
skipping to change at page 31, line 45 skipping to change at page 31, line 51
data is provided for another Device. If the LIS does not check that data is provided for another Device. If the LIS does not check that
the measurement data is for the identified Device, it could the measurement data is for the identified Device, it could
incorrectly authorize the request. incorrectly authorize the request.
By using unverified measurement data to generate a response, the LIS By using unverified measurement data to generate a response, the LIS
provides information about a Device without appropriate provides information about a Device without appropriate
authorization. authorization.
The feasibility of this attack depends on the availability of The feasibility of this attack depends on the availability of
information that links a Device with measurement data. In some information that links a Device with measurement data. In some
cases, measurement data that is correlated with a target is readily cases, measurement data that is correlated with a Target is readily
available. For instance, LLDP measurements (Section 5.1) are available. For instance, LLDP measurements (Section 5.1) are
broadcast to all nodes on the same network segment. An attacker on broadcast to all nodes on the same network segment. An attacker on
that network segment can easily gain measurement data that relates a that network segment can easily gain measurement data that relates a
Device with measurements. Device with measurements.
For some types of measurement data, it's necessary for an attacker to For some types of measurement data, it's necessary for an attacker to
know the location of the target in order to determine what know the location of the Target in order to determine what
measurements to use. This attack is meaningless for types of measurements to use. This attack is meaningless for types of
measurement data that require that the attacker first know the measurement data that require that the attacker first know the
location of the target before measurement data can be acquired or location of the Target before measurement data can be acquired or
fabricated. GNSS measurements (Section 5.5) share this trait with fabricated. GNSS measurements (Section 5.5) share this trait with
many wireless location determination methods. many wireless location determination methods.
7.1.2. Extracting Network Topology Data 7.1.2. Extracting Network Topology Data
Allowing requests with measurements might be used to collect Allowing requests with measurements might be used to collect
information about network topology. information about network topology.
Network topology can be considered sensitive information by a network Network topology can be considered sensitive information by a network
operator for commercial or security reasons. While it is impossible operator for commercial or security reasons. While it is impossible
skipping to change at page 32, line 49 skipping to change at page 33, line 5
measurements, the measurements in this document provide information measurements, the measurements in this document provide information
about an access network that could reveal topology information to an about an access network that could reveal topology information to an
unauthorized recipient. unauthorized recipient.
A Device MUST NOT provide information about network topology without A Device MUST NOT provide information about network topology without
a clear signal that the recipient is authorized. A LIS that is a clear signal that the recipient is authorized. A LIS that is
discovered using DHCP as described in LIS discovery [RFC5986] can be discovered using DHCP as described in LIS discovery [RFC5986] can be
considered to be authorized to receive information about the access considered to be authorized to receive information about the access
network. network.
7.1.4. Lying By Proxy 7.1.4. Lying by Proxy
Location information is a function of its inputs, which includes
measurement data. Thus, falsified measurement data can be used to Location information, which includes measurement data, is a function
alter the location information that is provided by a LIS. 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 Some types of measurement data are relatively easy to falsify in a
way that causes the resulting location information to be selected way that causes the resulting location information to be selected
with little or no error. For instance, GNSS measurements are easy to with little or no error. For instance, GNSS measurements are easy to
use for this purpose because all the contextual information necessary use for this purpose because all the contextual information necessary
to calculate a position using measurements is broadcast by the to calculate a position using measurements is broadcast by the
satellites [HARPER]. satellites [HARPER].
An attacker that falsifies measurement data gains little if they are An attacker that falsifies measurement data gains little if they are
the only recipients of the result. The attacker knows that the the only recipient of the result. The attacker knows that the
location information is bad. The attacker only gains if the location information is bad. The attacker only gains if the
information can somehow be attributed to the LIS by another location information can somehow be attributed to the LIS by another location
recipient. By coercing the LIS into providing falsified location recipient. By coercing the LIS into providing falsified location
information, any credibility that the LIS might have - that the information, any credibility that the LIS might have -- that the
attacker does not - is gained by the attacker. attacker does not -- is gained by the attacker.
A third-party that is reliant on the integrity of the location A third party that is reliant on the integrity of the location
information might base an evaluation of the credibility of the information might base an evaluation of the credibility of the
information on the source of the information. If that third party is information on the source of the information. If that third party is
able to attribute location information to the LIS, then an attacker able to attribute location information to the LIS, then an attacker
might gain. might gain.
Location information that is provided to the Device without any means 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 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 Device is identified as the source of the data when it distributes
the location information to location recipients. the location information to location recipients.
Location information is attributed to the LIS either through the use Location information is attributed to the LIS either through the use
of digital signatures or by having the location recipient directly of digital signatures or by having the location recipient directly
interact with the LIS. A LIS that digitally signs location interact with the LIS. A LIS that digitally signs location
information becomes identifiable as the source of the data. information becomes identifiable as the source of the data.
Similarly, the LIS is identified as a source of data if a location Similarly, the LIS is identified as a source of data if a location
recipient acquires information directly from a LIS using a location recipient acquires information directly from a LIS using a
URI. location URI.
7.1.5. Measurement Replay 7.1.5. Measurement Replay
The value of some measured properties do not change over time for a
single location. For properties of a network, time-invariance is
often directly as a result of the practicalities of operating the
network. Limiting the changes to a network ensures greater
consistency of service. A largely static network also greatly
simplifies the data management tasks involved with providing a
location service. 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 an time-invariant 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.
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 property of the environment at the subject location. For
measurements of this nature, nothing in the measurement itself is measurements of this nature, nothing in the measurement itself is
sufficient proof that the Device is present at the resulting sufficient proof that the Device is present at the resulting
location. Measurement data might have been previously acquired and location. Measurement data might have been previously acquired and
reused. reused.
For instance, the identity of a radio transmitter, if broadcast by For instance, the identity of a radio transmitter, if broadcast by
that transmitter, can be collected and stored. An attacker that that transmitter, can be collected and stored. An attacker that
wishes it known that they exist at a particular location, can claim wishes it known that they exist at a particular location can claim to
to observe this transmitter at any time. Nothing inherent in the observe this transmitter at any time. Nothing inherent in the claim
claim reveals it to be false. reveals it to be false.
7.1.6. Environment Spoofing 7.1.6. Environment Spoofing
Some types of measurement data can be altered or influenced by a Some types of measurement data can be altered or influenced by a
third party so that a Device unwittingly provides falsified data. If third party so that a Device unwittingly provides falsified data. If
it is possible for a third party to alter the measured phenomenon, it is possible for a third party to alter the measured phenomenon,
then any location information that is derived from this data can be then any location information that is derived from this data can be
indirectly influenced. indirectly influenced.
Altering the environment in this fashion might not require Altering the environment in this fashion might not require
involvement with either Device or LIS. Measurement that is passive - involvement with either a Device or LIS. Measurement that is passive
where the Device observes a signal or other phenomenon without direct -- where the Device observes a signal or other phenomenon without
interaction - are most susceptible to alteration by third parties. direct interaction -- is most susceptible to alteration by third
parties.
Measurement of radio signal characteristics is especially vulnerable Measurement of radio signal characteristics is especially vulnerable,
since an adversary need only be in the general vicinity of the Device 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 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 able to produce fake signals that claim to be transmitted by any
satellite or set of satellites (see [GPS.SPOOF]). satellite or set of satellites (see [GPS.SPOOF]).
Measurements that require direct interaction increases the complexity Measurements that require direct interaction increase the complexity
of the attack. For measurements relating to the communication of the attack. For measurements relating to the communication
medium, a third party cannot avoid direct interaction, they need only medium, a third party cannot avoid direct interaction; they need only
be on the communications path (that is, man in the middle). be on the communications path (that is, man in the middle).
Even if the entity that is interacted with is authenticated, this Even if the entity that is interacted with is authenticated, this
does not provide any assurance about the integrity of measurement does not provide any assurance about the integrity of measurement
data. For instance, the Device might authenticate the identity of a data. For instance, the Device might authenticate the identity of a
radio transmitter through the use of cryptographic means and obtain radio transmitter through the use of cryptographic means and obtain
signal strength measurements for that transmitter. Radio signal signal strength measurements for that transmitter. Radio signal
strength is trivial for an attacker to increase simply by receiving strength is trivial for an attacker to increase simply by receiving
and amplifying the raw signal; it is not necessary for the attacker and amplifying the raw signal; it is not necessary for the attacker
to be able to understand the signal content. to be able to understand the signal content.
Note: This particular "attack" is more often completely legitimate. Note: This particular "attack" is more often completely
Radio repeaters are commonplace mechanism used to increase radio legitimate. Radio repeaters are a commonplace mechanism used to
coverage. increase radio coverage.
Attacks that rely on altering the observed environment of a Device Attacks that rely on altering the observed environment of a Device
require countermeasures that affect the measurement process. For require countermeasures that affect the measurement process. For
radio signals, countermeasures could include the use of authenticated radio signals, countermeasures could include the use of authenticated
signals, or altered receiver design. In general, countermeasures are signals, or altered receiver design. In general, countermeasures are
highly specific to the individual measurement process. An exhaustive highly specific to the individual measurement process. An exhaustive
discussion of these issues is left to the relevant literature for discussion of these issues is left to the relevant literature for
each measurement technology. each measurement technology.
A Device that provides measurement data is assumed to be responsible A Device that provides measurement data is assumed to be responsible
skipping to change at page 35, line 45 skipping to change at page 35, line 39
be treated as though it were produced by an untrusted Device for be treated as though it were produced by an untrusted Device for
those cases where a location recipient might attribute the location those cases where a location recipient might attribute the location
information to the LIS. GNSS measurements and radio signal strength information to the LIS. GNSS measurements and radio signal strength
measurements can be affected relatively cheaply, though almost all measurements can be affected relatively cheaply, though almost all
other measurement types can be affected with varying costs to an other measurement types can be affected with varying costs to an
attacker, with the largest cost often being a requirement for attacker, with the largest cost often being a requirement for
physical access. To the extent that it is feasible, measurement data physical access. To the extent that it is feasible, measurement data
SHOULD be subjected to the same validation as for other types of SHOULD be subjected to the same validation as for other types of
attacks that rely on measurement falsification. attacks that rely on measurement falsification.
Note: Altered measurement data might be provided by a Device that Note: Altered measurement data might be provided by a Device that
has no knowledge of the alteration. Thus, an otherwise trusted has no knowledge of the alteration. Thus, an otherwise trusted
Device might still be an unreliable source of measurement data. Device might still be an unreliable source of measurement data.
7.2. Mitigation 7.2. Mitigation
The following measures can be applied to limit or prevent attacks. The following measures can be applied to limit or prevent attacks.
The effectiveness of each depends on the type of measurement data and The effectiveness of each depends on the type of measurement data and
how that measurement data is acquired. how that measurement data is acquired.
Two general approaches are identified for dealing with untrusted Two general approaches are identified for dealing with untrusted
measurement data: measurement data:
1. Require independent validation of measurement data or the 1. Require independent validation of measurement data or the
location information that is produced. location information that is produced.
skipping to change at page 36, line 15 skipping to change at page 36, line 12
The effectiveness of each depends on the type of measurement data and The effectiveness of each depends on the type of measurement data and
how that measurement data is acquired. how that measurement data is acquired.
Two general approaches are identified for dealing with untrusted Two general approaches are identified for dealing with untrusted
measurement data: measurement data:
1. Require independent validation of measurement data or the 1. Require independent validation of measurement data or the
location information that is produced. location information that is produced.
2. Identify the types of sources that provided the measurement data 2. Identify the types of sources that provided the measurement data
that location information was derived from. from which that location information was derived.
This section goes into more detail on the different forms of This section goes into more detail on the different forms of
validation in Section 7.2.1, Section 7.2.2, and Section 7.2.3. The validation in Sections 7.2.1, 7.2.2, and 7.2.3. The impact of
impact of attributing location information to sources is discussed in attributing location information to sources is discussed in more
more detail in Section 7.2.4. detail in Section 7.2.4.
Any costs in validation are balanced against the degree of integrity Any costs in validation are balanced against the degree of integrity
desired from the resulting location information. desired from the resulting location information.
7.2.1. Measurement Validation 7.2.1. Measurement Validation
Detecting that measurement data has been falsified is difficult in Recognizing that measurement data has been falsified is difficult in
the absence of integrity mechanisms. the absence of integrity mechanisms.
Independent confirmation of the veracity of measurement data ensures Independent confirmation of the veracity of measurement data ensures
that the measurement is accurate and that it applies to the correct that the measurement is accurate and that it applies to the correct
Device. When it's possible to gather the same measurement data from Device. When it's possible to gather the same measurement data from
a trusted and independent source without undue expense, the LIS can a trusted and independent source without undue expense, the LIS can
use the trusted data in place of what the untrusted Device has sent. use the trusted data in place of what the untrusted Device has sent.
In cases where that is impractical, the untrusted data can provide In cases where that is impractical, the untrusted data can provide
hints that allow corroboration of the data (see Section 7.2.1.1). hints that allow corroboration of the data (see Section 7.2.1.1).
Measurement information might contain no inherent indication that it Measurement information might not contain any inherent indication
is falsified. On the contrary, it can be difficult to obtain that it is falsified. In addition, it can be difficult to obtain
information that would provide any degree of assurance that the information that would provide any degree of assurance that the
measurement device is physically at any particular location. measurement device is physically at any particular location.
Measurements that are difficult to verify require other forms of Measurements that are difficult to verify require other forms of
assurance before they can be used. assurance before they can be used.
7.2.1.1. Effectiveness 7.2.1.1. Effectiveness
Measurement validation MUST be used if measurement data for a Measurement validation MUST be used if measurement data for a
particular Device can be easily acquired by unauthorized location particular Device can be easily acquired by unauthorized location
recipients, as described in Section 7.1.1. This prevents recipients, as described in Section 7.1.1. This prevents
skipping to change at page 37, line 17 skipping to change at page 37, line 12
a large Ethernet network could provide a measurement indicating its a large Ethernet network could provide a measurement indicating its
point of attachment using LLDP measurements. For a LIS, acquiring point of attachment using LLDP measurements. For a LIS, acquiring
the same measurement data might require a request to all switches in the same measurement data might require a request to all switches in
that network. With the measurement data, validation can target the that network. With the measurement data, validation can target the
identified switch with a specific query. identified switch with a specific query.
Validation is effective in identifying falsified measurement data Validation is effective in identifying falsified measurement data
(Section 7.1.4), including attacks involving replay of measurement (Section 7.1.4), including attacks involving replay of measurement
data (Section 7.1.5). Validation also limits the amount of network data (Section 7.1.5). Validation also limits the amount of network
topology information (Section 7.1.2) made available to Devices to topology information (Section 7.1.2) made available to Devices to
that portion of the network topology that they are directly attached. that portion of the network topology to which they are directly
attached.
Measurement validation has no effect if the underlying effect is Measurement validation has no effect if the underlying environment is
being spoofed (Section 7.1.6). being altered (Section 7.1.6).
7.2.1.2. Limitations (Unique Observer) 7.2.1.2. Limitations (Unique Observer)
A Device is often in a unique position to make a measurement. It A Device is often in a unique position to make a measurement. It
alone occupies the point in space-time that the location alone occupies the point in space-time that the location
determination process seeks to determine. The Device becomes a determination process seeks to determine. The Device becomes a
unique observer for a particular property. unique observer for a particular property.
The ability of the Device to become a unique observer makes the The ability of the Device to become a unique observer makes the
Device invaluable to the location determination process. As a unique Device invaluable to the location determination process. As a unique
observer, it also makes the claims of a Device difficult to validate observer, it also makes the claims of a Device difficult to validate
and easily to spoof. and easy to spoof.
As long as no other entity is capable of making the same As long as no other entity is capable of making the same
measurements, there is also no other entity that can independently measurements, there is also no other entity that can independently
check that the measurements are correct and applicable to the Device. 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 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 it receives from a unique observer. For instance, a signal strength
measurement of the signal from a radio tower cannot be validated measurement of the signal from a radio tower cannot be validated
directly. directly.
Some portion of the measurement data might still be independently Some portion of the measurement data might still be independently
skipping to change at page 38, line 40 skipping to change at page 38, line 40
There is little point in using a less accurate, less trusted There is little point in using a less accurate, less trusted
location. Untrusted location information that has worse accuracy location. Untrusted location information that has worse accuracy
than trusted information can be immediately discarded. There are than trusted information can be immediately discarded. There are
multiple factors that affect accuracy, uncertainty and currency being multiple factors that affect accuracy, uncertainty and currency being
the most important. How location information is compared for the most important. How location information is compared for
accuracy is not defined in this document. accuracy is not defined in this document.
7.2.2.1. Effectiveness 7.2.2.1. Effectiveness
Location validation limits the extent to which falsified - or Location validation limits the extent to which falsified -- or
erroneous - measurement data can cause an incorrect location to be erroneous -- measurement data can cause an incorrect location to be
reported. reported.
Location validation can be more efficient than validation of inputs, Location validation can be more efficient than validation of inputs,
particularly for a unique observer (Section 7.2.1.2). particularly for a unique observer (Section 7.2.1.2).
Validating location ensures that the Device is at or near the Validating location ensures that the Device is at or near the
resulting location. Location validation can be used to limit or resulting location. Location validation can be used to limit or
prevent all of the attacks identified in this document. prevent all of the attacks identified in this document.
7.2.2.2. Limitations 7.2.2.2. Limitations
skipping to change at page 39, line 4 skipping to change at page 39, line 6
reported. reported.
Location validation can be more efficient than validation of inputs, Location validation can be more efficient than validation of inputs,
particularly for a unique observer (Section 7.2.1.2). particularly for a unique observer (Section 7.2.1.2).
Validating location ensures that the Device is at or near the Validating location ensures that the Device is at or near the
resulting location. Location validation can be used to limit or resulting location. Location validation can be used to limit or
prevent all of the attacks identified in this document. prevent all of the attacks identified in this document.
7.2.2.2. Limitations 7.2.2.2. Limitations
The trusted location that is used for validation is always less The trusted location that is used for validation is always less
accurate than the location that is being checked. The amount by accurate than the location that is being checked. The amount by
which the untrusted location is more accurate, is the same amount which the untrusted location is more accurate, is the same amount
that an attacker can exploit. that an attacker can exploit.
For example, a trusted location might indicate a five kilometer For example, a trusted location might indicate an uncertainty region
radius uncertainty region. An untrusted location that describes a with a radius of five kilometers. An untrusted location that
100 meter uncertainty within the larger region might be accepted as describes a 100-meter uncertainty within the larger region might be
more accurate. An attacker might still falsify measurement data to accepted as more accurate. An attacker might still falsify
select any location within the larger uncertainty region. While the measurement data to select any location within the larger uncertainty
100 meter uncertainty that is reported seems more accurate, a region. While the 100-meter uncertainty that is reported seems more
falsified location could be anywhere in the five kilometer region. accurate, a falsified location could be anywhere in the
five-kilometer region.
Where measurement data might have been falsified, the actual Where measurement data might have been falsified, the actual
uncertainty is effectively much higher. Local policy might allow uncertainty is effectively much higher. Local policy might allow
differing degrees of trust to location information derived from differing degrees of trust to location information derived from
untrusted measurement data. This might be a boolean operation with untrusted measurement data. This might be a boolean operation with
only two possible outcomes: untrusted location information might be only two possible outcomes: untrusted location information might be
used entirely or not at all. Alternatively, untrusted location could used entirely or not at all. Alternatively, untrusted location
be combined with trusted location information using different information could be combined with trusted location information using
weightings, based on a value set in local policy. different weightings, based on a value set in local policy.
7.2.3. Supporting Observations 7.2.3. Supporting Observations
Replay attacks using previously acquired measurement data are Replay attacks using previously acquired measurement data are
particularly hard to detect without independent validation. Rather particularly hard to detect without independent validation. Rather
than validate the measurement data directly, supplementary data might than validate the measurement data directly, supplementary data might
be used to validate measurements or the location information derived be used to validate measurements or the location information derived
from those measurements. from those measurements.
These supporting observations could be used to convey information These supporting observations could be used to convey information
that provides additional assurance that the Device was acquired at a that provides additional assurance that measurement data from the
specific time and place. In effect, the Device is requested to Device was acquired at a specific time and place. In effect, the
provide proof of its presence at the resulting location. Device is requested to provide proof of its presence at the resulting
location.
For instance, a Device that measures attributes of a radio signal For instance, a Device that measures attributes of a radio signal
could also be asked to provide a sample of the measured 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 If the LIS is able to observe the same signal, the two observations
could be compared. Providing that the signal cannot be predicted in could be compared. Providing that the signal cannot be predicted in
advance by the Device, this could be used to support the claim that 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 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 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 use this to attribute a higher level of trust in the associated
measurement data or resulting location. measurement data or resulting location.
skipping to change at page 40, line 4 skipping to change at page 40, line 6
could also be asked to provide a sample of the measured 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 If the LIS is able to observe the same signal, the two observations
could be compared. Providing that the signal cannot be predicted in could be compared. Providing that the signal cannot be predicted in
advance by the Device, this could be used to support the claim that 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 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 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 use this to attribute a higher level of trust in the associated
measurement data or resulting location. measurement data or resulting location.
7.2.3.1. Effectiveness 7.2.3.1. Effectiveness
The use of supporting observations is limited by the ability of the The use of supporting observations is limited by the ability of the
LIS to acquire and validate these observations. The advantage of LIS to acquire and validate these observations. The advantage of
selecting observations independent of measurement data is that selecting observations independent of measurement data is that
observations can be selected based on how readily available the data 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 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. be selected based on the degree of assurance that is desired.
Use of supporting observations is similar to both measurement The use of supporting observations is similar to both measurement
validation and location validation. All three methods rely on validation and location validation. All three methods rely on
independent validation of one or more properties. Applicability of independent validation of one or more properties. The applicability
each method is similar. of each method is similar.
Use of supporting observations can be used to limit or prevent all of The use of supporting observations can be used to limit or prevent
the attacks identified in this document. all of the attacks identified in this document.
7.2.3.2. Limitations 7.2.3.2. Limitations
The effectiveness of the validation method depends on the quality of The effectiveness of the validation method depends on the quality of
the supporting observation: how hard it is to obtain at a different the supporting observation: how hard it is for the entity performing
time or place, how difficult it is to guess, and what other costs the validation to obtain the data at a different time or place, how
might be involved in acquiring this data. 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 In the example of an observed radio signal, requesting a sample of
the signal only provides an assurance that the Device is able to the signal only provides an assurance that the Device is able to
receive the signal transmitted by the measured radio transmitter. receive the signal transmitted by the measured radio transmitter.
This only provides some assurance that the Device is within range of This only provides some assurance that the Device is within range of
the transmitter. the transmitter.
As with location validation, a Device might still be able to provide As with location validation, a Device might still be able to provide
falsified measurements that could alter the value of the location falsified measurements that could alter the value of the location
information as long as the result is within this region. information as long as the result is within this region.
skipping to change at page 41, line 20 skipping to change at page 41, line 20
information is accurate, this approach instead provides a location information is accurate, this approach instead provides a location
recipient with the information necessary to reach their own recipient with the information necessary to reach their own
conclusion about the trustworthiness of the location information. conclusion about the trustworthiness of the location information.
Including an authenticated identity for all sources of measurement Including an authenticated identity for all sources of measurement
data presents a number of technical and operational challenges. It data presents a number of technical and operational challenges. It
is possible that the LIS has a transient relationship with a Device. is possible that the LIS has a transient relationship with a Device.
A Device is not expected to share authentication information with a A Device is not expected to share authentication information with a
LIS. There is no assurance that Device identification is usable by a LIS. There is no assurance that Device identification is usable by a
potential location recipient. Privacy concerns might also prevent potential location recipient. Privacy concerns might also prevent
the sharing identification information, even if it were available and the sharing of identification information, even if it were available
usable. and usable.
Identifying the type of measurement source allows a location Identifying the type of measurement source allows a location
recipient to make a decision about the trustworthiness of location recipient to make a decision about the trustworthiness of location
information without depending on having authenticated identity information without depending on having authenticated identity
information for each source. An element for this purpose is defined information for each source. An element for this purpose is defined
in Section 4.4. in Section 4.4.
When including location information that is based on measurement data When including location information that is based on measurement data
from sources that might be untrusted, a LIS SHOULD include from sources that might be untrusted, a LIS SHOULD include
alternative location information that is derived from trusted sources alternative location information that is derived from trusted sources
of measurement data. Each item of location information can then be of measurement data. Each item of location information can then be
labelled with the source of that data. labeled with the source of that data.
A location recipient that is able to identify a specific source of A location recipient that is able to identify a specific source of
measurement data (whether it be LIS or Device) can use this measurement data (whether it be LIS or Device) can use this
information to attribute location information to either or both information to attribute location information to either entity or to
entity. The location recipient is then better able to make decisions both entities. The location recipient is then better able to make
about trustworthiness based on the source of the data. decisions about trustworthiness based on the source of the data.
A location recipient that does not understand the "source" element is A location recipient that does not understand the "source" element is
unable to make this distinction. When constructing a PIDF-LO unable to make this distinction. When constructing a PIDF-LO
document, trusted location information MUST be placed in the PIDF-LO document, trusted location information MUST be placed in the PIDF-LO
so that it is given higher priority to any untrusted location so that it is given higher priority to any untrusted location
information according to Rule #8 of [RFC5491]. information according to Rule #8 of [RFC5491].
Attribution of information does nothing to address attacks that alter Attribution of information does nothing to address attacks that alter
the observed parameters that are used in location determination the observed parameters that are used in location determination
(Section 7.1.6). (Section 7.1.6).
skipping to change at page 42, line 18 skipping to change at page 42, line 21
Simply limiting the rate of requests from a single Device reduces the Simply limiting the rate of requests from a single Device reduces the
amount of data that a Device can acquire about network topology. A amount of data that a Device can acquire about network topology. A
LIS could also make observations about the movements of a Device. A LIS could also make observations about the movements of a Device. A
Device that is attempting to gather topology information is likely to Device that is attempting to gather topology information is likely to
be assigned a location that changes significantly between subsequent be assigned a location that changes significantly between subsequent
requests, possibly violating physical laws (or lower limits that requests, possibly violating physical laws (or lower limits that
might still be unlikely) with respect to speed and acceleration. might still be unlikely) with respect to speed and acceleration.
7.3. An Unauthorized or Compromised LIS 7.3. An Unauthorized or Compromised LIS
A compromised LIS, or a compromise in LIS discovery [RFC5986] could A compromised LIS, or a compromise in LIS discovery [RFC5986], could
lead to an unathorized entity obtaining measurement data. This lead to an unauthorized entity obtaining measurement data. This
information could then be used or redistributed. A Device MUST information could then be used or redistributed. A Device MUST
ensure that it authenticate a LIS, as described in Section 9 of ensure that it authenticates a LIS, as described in Section 9 of
[RFC5985]. [RFC5985].
An entity that is able to acquire measurement data can, in addition An entity that is able to acquire measurement data can, in addition
to using those measurements to learn the location of a Device, also to using those measurements to learn the location of a Device, also
use that information for other purposes. This information can be use that information for other purposes. This information can be
used to provide insight into network topology (Section 7.1.2). used to provide insight into network topology (Section 7.1.2).
Measurement data might also be exploited in other ways. For example, Measurement data might also be exploited in other ways. For example,
revealing the type of 802.11 transceiver that a Device uses could revealing the type of 802.11 transceiver that a Device uses could
allow an attacker to use specific vulnerabilities to attack a Device. allow an attacker to use specific vulnerabilities to attack a Device.
Similarly, revealing information about network elements could enable Similarly, revealing information about network elements could enable
targeted attacks on that infrastructure. targeted attacks on that infrastructure.
8. Measurement Schemas 8. Measurement Schemas
The schema are broken up into their respective functions. There is a The schemas are broken up into their respective functions. A base
base container schema into which all measurements are placed, plus container schema into which all measurements are placed is defined,
definitions for a measurement request (Section 8.1). A PIDF-LO including the definition of a measurement request (Section 8.1). A
extension is defined in a separate schema (Section 8.2). There is a PIDF-LO extension is defined in a separate schema (Section 8.2). A
basic types schema, that contains various base type definitions for basic Types Schema contains common definitions, including the
things such as the "rmsError" and "samples" attributes IPv4, IPv6 and "rmsError" and "samples" attributes, plus types for IPv4, IPv6, and
MAC addresses (Section 8.3). Then each of the specific measurement MAC addresses (Section 8.3). Each of the specific measurement types
types is defined in its own schema. is defined in a separate schema.
8.1. Measurement Container Schema 8.1. Measurement Container Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm" xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:appinfo <xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm"> source="urn:ietf:params:xml:schema:geopriv:lm">
</xs:appinfo> </xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of source="http://www.rfc-editor.org/rfc/rfc7105.txt">
published RFC and remove this note.]] --> This schema defines a framework for location measurements.
This schema defines a framework for location measurements.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/> <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:element name="measurements"> <xs:element name="measurements">
<xs:complexType> <xs:complexType>
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="time" type="xs:dateTime"/> <xs:attribute name="time" type="xs:dateTime"/>
<xs:attribute name="timeError" type="bt:positiveDouble"/> <xs:attribute name="timeError" type="bt:positiveDouble"/>
<xs:attribute name="expires" type="xs:dateTime"/> <xs:attribute name="expires" type="xs:dateTime"/>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="measurementRequest" <xs:element name="measurementRequest"
type="lm:measurementRequestType"/> type="lm:measurementRequestType"/>
<xs:complexType name="measurementRequestType"> <xs:complexType name="measurementRequestType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element ref="lm:measurement" <xs:element ref="lm:measurement"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax"
</xs:sequence> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="measurement" type="lm:measurementType"/> <xs:element name="measurement" type="lm:measurementType"/>
<xs:complexType name="measurementType"> <xs:complexType name="measurementType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="type" type="xs:QName" use="required"/> <xs:attribute name="type" type="xs:QName" use="required"/>
<xs:attribute name="samples" type="xs:positiveInteger"/> <xs:attribute name="samples" type="xs:positiveInteger"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<!-- PIDF-LO extension for source --> <!-- PIDF-LO extension for source -->
<xs:element name="source" type="lm:sourceType"/> <xs:element name="source" type="lm:sourceType"/>
<xs:simpleType name="sourceType"> <xs:simpleType name="sourceType">
<xs:list> <xs:list>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="lis"/> <xs:enumeration value="lis"/>
<xs:enumeration value="device"/> <xs:enumeration value="device"/>
<xs:enumeration value="other"/> <xs:enumeration value="other"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:list> </xs:list>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Measurement Container Schema Measurement Container Schema
8.2. Measurement Source Schema 8.2. Measurement Source Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc" xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc" targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:appinfo <xs:appinfo
source="urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc"> source="urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc">
</xs:appinfo> </xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of source="http://www.rfc-editor.org/rfc/rfc7105.txt">
published RFC and remove this note.]] --> This schema defines an extension to PIDF-LO that indicates
This schema defines an extension to PIDF-LO that indicates the the type of measurement source that produced the measurement
type of source that produced the measurement data used in data used in generating the associated location information.
generating the associated location information.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:element name="source" type="lmsrc:sourceType"/> <xs:element name="source" type="lmsrc:sourceType"/>
<xs:simpleType name="sourceType"> <xs:simpleType name="sourceType">
<xs:list> <xs:list>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="lis"/> <xs:enumeration value="lis"/>
<xs:enumeration value="device"/> <xs:enumeration value="device"/>
<xs:enumeration value="other"/> <xs:enumeration value="other"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:list> </xs:list>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Measurement Source PIDF-LO Extension Schema Measurement Source PIDF-LO Extension Schema
8.3. Base Type Schema 8.3. Base Types Schema
Note that the pattern rules in the following schema wrap due to Note that the pattern rules in the following schema wrap due to
length constraints. None of the patterns contain whitespace. length constraints. None of the patterns contain whitespace.
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:appinfo <xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:basetypes"> source="urn:ietf:params:xml:schema:geopriv:lm:basetypes">
</xs:appinfo> </xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of source="http://www.rfc-editor.org/rfc/rfc7105.txt">
published RFC and remove this note.]] --> This schema defines a set of base type elements.
This schema defines a set of base type elements.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:simpleType name="byteType"> <xs:simpleType name="byteType">
<xs:restriction base="xs:integer"> <xs:restriction base="xs:integer">
<xs:minInclusive value="0"/> <xs:minInclusive value="0"/>
<xs:maxInclusive value="255"/> <xs:maxInclusive value="255"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="twoByteType"> <xs:simpleType name="twoByteType">
<xs:restriction base="xs:integer"> <xs:restriction base="xs:integer">
<xs:minInclusive value="0"/> <xs:minInclusive value="0"/>
<xs:maxInclusive value="65535"/> <xs:maxInclusive value="65535"/>
skipping to change at page 46, line 27 skipping to change at page 47, line 4
<xs:simpleType name="nonNegativeDouble"> <xs:simpleType name="nonNegativeDouble">
<xs:restriction base="xs:double"> <xs:restriction base="xs:double">
<xs:minInclusive value="0.0"/> <xs:minInclusive value="0.0"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="positiveDouble"> <xs:simpleType name="positiveDouble">
<xs:restriction base="bt:nonNegativeDouble"> <xs:restriction base="bt:nonNegativeDouble">
<xs:minExclusive value="0.0"/> <xs:minExclusive value="0.0"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="doubleWithRMSError"> <xs:complexType name="doubleWithRMSError">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:double"> <xs:extension base="xs:double">
<xs:attribute name="rmsError" type="bt:positiveDouble"/> <xs:attribute name="rmsError" type="bt:positiveDouble"/>
<xs:attribute name="samples" type="xs:positiveInteger"/> <xs:attribute name="samples" type="xs:positiveInteger"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="nnDoubleWithRMSError"> <xs:complexType name="nnDoubleWithRMSError">
<xs:simpleContent> <xs:simpleContent>
<xs:restriction base="bt:doubleWithRMSError"> <xs:restriction base="bt:doubleWithRMSError">
<xs:minInclusive value="0"/> <xs:minInclusive value="0"/>
</xs:restriction> </xs:restriction>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:simpleType name="ipAddressType"> <xs:simpleType name="ipAddressType">
<xs:union memberTypes="bt:IPv6AddressType bt:IPv4AddressType"/> <xs:union memberTypes="bt:IPv6AddressType bt:IPv4AddressType"/>
</xs:simpleType> </xs:simpleType>
<!-- IPv6 format definition --> <!-- IPv6 format definition -->
<xs:simpleType name="IPv6AddressType"> <xs:simpleType name="IPv6AddressType">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
An IP version 6 address, based on RFC 4291.
An IP version 6 address, based on RFC 4291.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<!-- Fully specified address --> <!-- Fully specified address -->
<xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/> <xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/>
<!-- Double colon start --> <!-- Double colon start -->
<xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/> <xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/>
<!-- Double colon middle --> <!-- Double colon middle -->
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6} <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6}
(:[0-9A-Fa-f]{1,4}){1}"/> (:[0-9A-Fa-f]{1,4}){1}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5} <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
(:[0-9A-Fa-f]{1,4}){1,2}"/> (:[0-9A-Fa-f]{1,4}){1,2}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4} <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
(:[0-9A-Fa-f]{1,4}){1,3}"/> (:[0-9A-Fa-f]{1,4}){1,3}"/>
<xs:pattern value="([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}"/> (:[0-9A-Fa-f]{1,4}){1,4}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2} <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
(:[0-9A-Fa-f]{1,4}){1,5}"/> (:[0-9A-Fa-f]{1,4}){1,5}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1} <xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
(:[0-9A-Fa-f]{1,4}){1,6}"/> (:[0-9A-Fa-f]{1,4}){1,6}"/>
<!-- Double colon end --> <!-- Double colon end -->
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,7}:"/> <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,7}:"/>
<!-- IPv4-Compatible and IPv4-Mapped Addresses --> <!-- IPv4-Compatible and IPv4-Mapped Addresses -->
<xs:pattern value="((:(:0{1,4}){0,3}:[fF]{4})|(0{1,4}: <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}){0,2}:[fF]{4})|((0{1,4}:){2}
(:0{1,4})?:[fF]{4})|((0{1,4}:){3}:[fF]{4}) (: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,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-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])\.(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])"/> [0-9]?[0-9])"/>
<!-- The unspecified address --> <!-- The unspecified address -->
<xs:pattern value="::"/> <xs:pattern value="::"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- IPv4 format definition --> <!-- IPv4 format definition -->
<xs:simpleType name="IPv4AddressType"> <xs:simpleType name="IPv4AddressType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\. <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])\. (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:restriction>
</xs:simpleType> </xs:simpleType>
<!-- MAC address (EUI-48) or EUI-64 address --> <!-- MAC address (EUI-48) or EUI-64 address -->
<xs:simpleType name="macAddressType"> <xs:simpleType name="macAddressType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern <xs:pattern
value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/> value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
skipping to change at page 48, line 10 skipping to change at page 48, line 35
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<!-- MAC address (EUI-48) or EUI-64 address --> <!-- MAC address (EUI-48) or EUI-64 address -->
<xs:simpleType name="macAddressType"> <xs:simpleType name="macAddressType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern <xs:pattern
value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/> value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Base Type Schema Base Types Schema
8.4. LLDP Measurement Schema 8.4. LLDP Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:lldp="urn:ietf:params:xml:ns:geopriv:lm:lldp" xmlns:lldp="urn:ietf:params:xml:ns:geopriv:lm:lldp"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:lldp" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:lldp"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:appinfo <xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:lldp"> source="urn:ietf:params:xml:schema:geopriv:lm:lldp">
</xs:appinfo> </xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of source="http://www.rfc-editor.org/rfc/rfc7105.txt">
published RFC and remove this note.]] --> This schema defines a set of LLDP location measurements.
This schema defines a set of LLDP location measurements.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/> <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:element name="lldp" type="lldp:lldpMeasurementType"/> <xs:element name="lldp" type="lldp:lldpMeasurementType"/>
<xs:complexType name="lldpMeasurementType"> <xs:complexType name="lldpMeasurementType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="chassis" type="lldp:lldpDataType"/> <xs:element name="chassis" type="lldp:lldpDataType"/>
<xs:element name="port" type="lldp:lldpDataType"/> <xs:element name="port" type="lldp:lldpDataType"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="lldpDataType"> <xs:complexType name="lldpDataType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="lldp:lldpOctetStringType"> <xs:extension base="lldp:lldpOctetStringType">
<xs:attribute name="type" type="bt:byteType" <xs:attribute name="type" type="bt:byteType"
use="required"/> use="required"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:simpleType name="lldpOctetStringType"> <xs:simpleType name="lldpOctetStringType">
<xs:restriction base="xs:hexBinary"> <xs:restriction base="xs:hexBinary">
<xs:minLength value="1"/> <xs:minLength value="1"/>
<xs:maxLength value="255"/> <xs:maxLength value="255"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
LLDP measurement schema LLDP Measurement Schema
8.5. DHCP Measurement Schema 8.5. DHCP Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:dhcp="urn:ietf:params:xml:ns:geopriv:lm:dhcp" xmlns:dhcp="urn:ietf:params:xml:ns:geopriv:lm:dhcp"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dhcp" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dhcp"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:appinfo <xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:dhcp"> source="urn:ietf:params:xml:schema:geopriv:lm:dhcp">
</xs:appinfo> </xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of source="http://www.rfc-editor.org/rfc/rfc7105.txt">
published RFC and remove this note.]] --> This schema defines a set of DHCP location measurements.
This schema defines a set of DHCP location measurements.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/> <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<!-- DHCP Relay Agent Information Option --> <!-- DHCP Relay Agent Information option -->
<xs:element name="dhcp-rai" type="dhcp:dhcpType"/> <xs:element name="dhcp-rai" type="dhcp:dhcpType"/>
<xs:complexType name="dhcpType"> <xs:complexType name="dhcpType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="giaddr" type="bt:ipAddressType"/> <xs:element name="giaddr" type="bt:ipAddressType"/>
<xs:element name="circuit" <xs:element name="circuit"
type="xs:hexBinary" minOccurs="0"/> type="xs:hexBinary" minOccurs="0"/>
<xs:element name="remote" <xs:element name="remote"
type="dhcp:dhcpRemoteType" minOccurs="0"/> type="dhcp:dhcpRemoteType" minOccurs="0"/>
<xs:element name="subscriber" <xs:element name="subscriber"
type="xs:hexBinary" minOccurs="0"/> type="xs:hexBinary" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax"
</xs:sequence> minOccurs="0" maxOccurs="unbounded"/>
<xs:anyAttribute namespace="##any" processContents="lax"/> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="dhcpRemoteType"> <xs:complexType name="dhcpRemoteType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:hexBinary"> <xs:extension base="xs:hexBinary">
<xs:attribute name="enterprise" type="xs:positiveInteger" <xs:attribute name="enterprise" type="xs:positiveInteger"
use="optional"/> use="optional"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
DHCP measurement schema DHCP Measurement Schema
8.6. WiFi Measurement Schema 8.6. WiFi Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi" xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:wifi" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:wifi"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:appinfo <xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:wifi"> source="urn:ietf:params:xml:schema:geopriv:lm:wifi">
802.11 location measurements 802.11 location measurements
</xs:appinfo> </xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of source="http://www.rfc-editor.org/rfc/rfc7105.txt">
published RFC and remove this note.]] --> This schema defines a basic set of 802.11 location
This schema defines a basic set of 802.11 location measurements. measurements.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/> <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:import namespace="http://www.opengis.net/gml"/> <xs:import namespace="http://www.opengis.net/gml"/>
<xs:element name="wifi" type="wifi:wifiNetworkType"/> <xs:element name="wifi" type="wifi:wifiNetworkType"/>
<xs:complexType name="wifiNetworkType"> <xs:complexType name="wifiNetworkType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="nicType" type="xs:token" <xs:element name="nicType" type="xs:token"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="ap" type="wifi:wifiType" <xs:element name="ap" type="wifi:wifiType"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="wifiType"> <xs:complexType name="wifiType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="bssid" type="wifi:bssidType"/> <xs:element name="bssid" type="wifi:bssidType"/>
<xs:element name="ssid" type="wifi:ssidType" <xs:element name="ssid" type="wifi:ssidType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="channel" type="xs:nonNegativeInteger" <xs:element name="channel" type="xs:nonNegativeInteger"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="location" minOccurs="0" <xs:element name="location" minOccurs="0"
type="xs:anyType"/> type="xs:anyType"/>
<xs:element name="type" type="wifi:networkType" <xs:element name="type" type="wifi:networkType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="regclass" type="wifi:regclassType" <xs:element name="regclass" type="wifi:regclassType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="antenna" type="wifi:octetType" <xs:element name="antenna" type="wifi:octetType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="flightTime" minOccurs="0" <xs:element name="flightTime" minOccurs="0"
type="bt:nnDoubleWithRMSError"/> type="bt:nnDoubleWithRMSError"/>
<xs:element name="apSignal" type="wifi:signalType" <xs:element name="apSignal" type="wifi:signalType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="deviceSignal" type="wifi:signalType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="serving" type="xs:boolean"
default="false"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
<xs:element name="deviceSignal" type="wifi:signalType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="serving" type="xs:boolean"
default="false"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="bssidType"> <xs:complexType name="bssidType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="bt:macAddressType"> <xs:extension base="bt:macAddressType">
<xs:attribute name="verified" type="xs:boolean" <xs:attribute name="verified" type="xs:boolean"
default="false"/> default="false"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<!-- Note that this pattern does not prevent multibyte UTF-8 <!-- Note that this pattern does not prevent multibyte UTF-8
sequences that result in a SSID longer than 32 octets. --> sequences that result in an SSID longer than 32 octets. -->
<xs:simpleType name="ssidType"> <xs:simpleType name="ssidType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="(\\[\da-fA-F]{2}|[^\\]){0,32}"/> <xs:pattern value="(\\[\da-fA-F]{2}|[^\\]){0,32}"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="networkType"> <xs:simpleType name="networkType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="[a-zA-Z]+"/> <xs:pattern value="[a-zA-Z]+"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="regclassType"> <xs:complexType name="regclassType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="wifi:octetType"> <xs:extension base="wifi:octetType">
<xs:attribute name="country"> <xs:attribute name="country">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="[A-Z]{2}[OIX]?"/> <xs:pattern value="[A-Z]{2}[OIX]?"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:simpleType name="octetType"> <xs:simpleType name="octetType">
<xs:restriction base="xs:nonNegativeInteger"> <xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="255"/> <xs:maxInclusive value="255"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="signalType"> <xs:complexType name="signalType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="transmit" type="xs:double" <xs:element name="transmit" type="xs:double"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="gain" type="xs:double" minOccurs="0"/> <xs:element name="gain" type="xs:double" minOccurs="0"/>
<xs:element name="rcpi" type="wifi:rssiType" <xs:element name="rcpi" type="wifi:rssiType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="rsni" type="bt:doubleWithRMSError" <xs:element name="rsni" type="bt:doubleWithRMSError"
minOccurs="0"/> minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="rssiType"> <xs:complexType name="rssiType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="bt:doubleWithRMSError"> <xs:extension base="bt:doubleWithRMSError">
<xs:attribute name="dBm" type="xs:boolean" default="true"/> <xs:attribute name="dBm" type="xs:boolean" default="true"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<!-- Measurement Request elements --> <!-- Measurement Request elements -->
<xs:element name="type" type="wifi:networkType"/> <xs:element name="type" type="wifi:networkType"/>
<xs:element name="parameter" type="wifi:parameterType"/> <xs:element name="parameter" type="wifi:parameterType"/>
<xs:complexType name="parameterType"> <xs:complexType name="parameterType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:QName"> <xs:extension base="xs:QName">
<xs:attribute name="context" use="optional"> <xs:attribute name="context" use="optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="ap"/> <xs:enumeration value="ap"/>
<xs:enumeration value="device"/> <xs:enumeration value="device"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
WiFi measurement schema WiFi Measurement Schema
8.7. Cellular Measurement Schema 8.7. Cellular Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:cell="urn:ietf:params:xml:ns:geopriv:lm:cell" xmlns:cell="urn:ietf:params:xml:ns:geopriv:lm:cell"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:cell" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:cell"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:appinfo <xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:cell"> source="urn:ietf:params:xml:schema:geopriv:lm:cell">
</xs:appinfo> </xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of source="http://www.rfc-editor.org/rfc/rfc7105.txt">
published RFC and remove this note.]] --> This schema defines a set of cellular location measurements.
This schema defines a set of cellular location measurements.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:element name="cellular" type="cell:cellularType"/> <xs:element name="cellular" type="cell:cellularType"/>
<xs:complexType name="cellularType"> <xs:complexType name="cellularType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:choice> <xs:choice>
<xs:element name="servingCell" type="cell:cellType"/> <xs:element name="servingCell" type="cell:cellType"/>
<xs:element name="observedCell" type="cell:cellType"/> <xs:element name="observedCell" type="cell:cellType"/>
</xs:choice> </xs:choice>
<xs:element name="observedCell" type="cell:cellType" <xs:element name="observedCell" type="cell:cellType"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="cellType"> <xs:complexType name="cellType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <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:choice>
<xs:sequence> <xs:sequence>
<xs:choice> <xs:element name="mcc" type="cell:mccType"/>
<xs:element name="rnc" type="cell:cellIdType"/> <xs:element name="mnc" type="cell:mncType"/>
<xs:element name="lac" type="cell:cellIdType"/> <xs:choice>
</xs:choice> <xs:sequence>
<xs:element name="cid" type="cell:cellIdType"/> <xs:choice>
<xs:element name="rnc" type="cell:cellIdType"/>
<xs:element name="lac" type="cell:cellIdType"/>
</xs:choice>
<xs:element name="cid" type="cell:cellIdType"/>
</xs:sequence>
<xs:element name="eucid" type="cell:cellIdType"/>
</xs:choice>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:element name="eucid" type="cell:cellIdType"/> <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: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:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:simpleType name="mccType"> <xs:simpleType name="mccType">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="[0-9]{3}"/> <xs:pattern value="[0-9]{3}"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
skipping to change at page 56, line 23 skipping to change at page 57, line 13
<xs:enumeration value="umts"/> <xs:enumeration value="umts"/>
<xs:enumeration value="lte"/> <xs:enumeration value="lte"/>
<xs:enumeration value="cdma"/> <xs:enumeration value="cdma"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element name="network" type="cell:networkType"/> <xs:element name="network" type="cell:networkType"/>
<xs:complexType name="networkType"> <xs:complexType name="networkType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:choice> <xs:choice>
<xs:sequence> <xs:sequence>
<xs:element name="mcc" type="cell:mccType"/> <xs:element name="mcc" type="cell:mccType"/>
<xs:element name="mnc" type="cell:mncType"/> <xs:element name="mnc" type="cell:mncType"/>
</xs:sequence> </xs:sequence>
<xs:element name="nid" type="cell:cellIdType"/> <xs:element name="nid" type="cell:cellIdType"/>
</xs:choice> </xs:choice>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
Cellular measurement schema Cellular Measurement Schema
8.8. GNSS Measurement Schema 8.8. GNSS Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:gnss="urn:ietf:params:xml:ns:geopriv:lm:gnss" xmlns:gnss="urn:ietf:params:xml:ns:geopriv:lm:gnss"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:gnss" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:gnss"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:appinfo <xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:gnss"> source="urn:ietf:params:xml:schema:geopriv:lm:gnss">
</xs:appinfo> </xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of source="http://www.rfc-editor.org/rfc/rfc7105.txt">
published RFC and remove this note.]] --> This schema defines a set of GNSS location measurements.
This schema defines a set of GNSS location measurements
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/> <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<!-- GNSS --> <!-- GNSS -->
<xs:element name="gnss" type="gnss:gnssMeasurementType"> <xs:element name="gnss" type="gnss:gnssMeasurementType">
<xs:unique name="gnssSatellite"> <xs:unique name="gnssSatellite">
<xs:selector xpath="sat"/> <xs:selector xpath="sat"/>
<xs:field xpath="@num"/> <xs:field xpath="@num"/>
</xs:unique> </xs:unique>
</xs:element> </xs:element>
<xs:complexType name="gnssMeasurementType"> <xs:complexType name="gnssMeasurementType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="gnssTime" type="bt:nnDoubleWithRMSError" <xs:element name="gnssTime" type="bt:nnDoubleWithRMSError"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="sat" type="gnss:gnssSatelliteType" <xs:element name="sat" type="gnss:gnssSatelliteType"
minOccurs="1" maxOccurs="64"/> minOccurs="1" maxOccurs="64"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="system" type="xs:token" use="required"/> <xs:attribute name="system" type="xs:token" use="required"/>
<xs:attribute name="signal" type="xs:token"/> <xs:attribute name="signal" type="xs:token"/>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="gnssSatelliteType"> <xs:complexType name="gnssSatelliteType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:sequence> <xs:sequence>
<xs:element name="doppler" type="bt:doubleWithRMSError"/> <xs:element name="doppler" type="bt:doubleWithRMSError"/>
<xs:element name="codephase" <xs:element name="codephase"
type="bt:nnDoubleWithRMSError"/> type="bt:nnDoubleWithRMSError"/>
<xs:element name="cn0" type="bt:nonNegativeDouble"/> <xs:element name="cn0" type="bt:nonNegativeDouble"/>
<xs:element name="mp" type="bt:positiveDouble" <xs:element name="mp" type="bt:positiveDouble"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="cq" type="gnss:codePhaseQualityType" <xs:element name="cq" type="gnss:codePhaseQualityType"
minOccurs="0"/> minOccurs="0"/>
<xs:element name="adr" type="xs:double" minOccurs="0"/> <xs:element name="adr" type="xs:double" minOccurs="0"/>
</xs:sequence>
</xs:sequence> <xs:attribute name="num" type="xs:positiveInteger"
<xs:attribute name="num" type="xs:positiveInteger" use="required"/>
use="required"/>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="codePhaseQualityType"> <xs:complexType name="codePhaseQualityType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:attribute name="continuous" type="xs:boolean" <xs:attribute name="continuous" type="xs:boolean"
default="true"/> default="true"/>
<xs:attribute name="direct" use="required"> <xs:attribute name="direct" use="required">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="direct"/> <xs:enumeration value="direct"/>
<xs:enumeration value="inverted"/> <xs:enumeration value="inverted"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:restriction> </xs:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
GNSS measurement Schema GNSS Measurement Schema
8.9. DSL Measurement Schema 8.9. DSL Measurement Schema
<?xml version="1.0"?> <?xml version="1.0"?>
<xs:schema <xs:schema
xmlns:dsl="urn:ietf:params:xml:ns:geopriv:lm:dsl" xmlns:dsl="urn:ietf:params:xml:ns:geopriv:lm:dsl"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes" xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dsl" targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dsl"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:appinfo <xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:dsl"> source="urn:ietf:params:xml:schema:geopriv:lm:dsl">
DSL measurement definitions DSL measurement definitions
</xs:appinfo> </xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt"> <xs:documentation
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of source="http://www.rfc-editor.org/rfc/rfc7105.txt">
published RFC and remove this note.]] --> This schema defines a basic set of DSL location measurements.
This schema defines a basic set of DSL location measurements.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/> <xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:element name="dsl" type="dsl:dslVlanType"/> <xs:element name="dsl" type="dsl:dslVlanType"/>
<xs:complexType name="dslVlanType"> <xs:complexType name="dslVlanType">
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <xs:restriction base="xs:anyType">
<xs:choice> <xs:choice>
<xs:element name="l2tp"> <xs:element name="l2tp">
<xs:complexType> <xs:complexType>
<xs:complexContent> <xs:complexContent>
<xs:restriction base="xs:anyType"> <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:sequence>
<xs:element name="src" type="bt:ipAddressType"/> <xs:element name="an" type="xs:token"/>
<xs:element name="dest" type="bt:ipAddressType"/> <xs:group ref="dsl:dslSlotPort"/>
<xs:element name="session"
type="xs:nonNegativeInteger"/>
</xs:sequence> </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:sequence>
<xs:element name="ctag" type="dsl:vlanIDType"/> <xs:element name="stag" type="dsl:vlanIDType"/>
<xs:group ref="dsl:dslSlotPort" minOccurs="0"/> <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:group ref="dsl:dslSlotPort"/> <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:choice>
</xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/>
<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:restriction>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:simpleType name="vlanIDType"> <xs:simpleType name="vlanIDType">
<xs:restriction base="xs:nonNegativeInteger"> <xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="4095"/> <xs:maxInclusive value="4095"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:group name="dslSlotPort"> <xs:group name="dslSlotPort">
<xs:sequence> <xs:sequence>
skipping to change at page 60, line 15 skipping to change at page 61, line 15
<xs:restriction base="xs:nonNegativeInteger"> <xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="4095"/> <xs:maxInclusive value="4095"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:group name="dslSlotPort"> <xs:group name="dslSlotPort">
<xs:sequence> <xs:sequence>
<xs:element name="slot" type="xs:token"/> <xs:element name="slot" type="xs:token"/>
<xs:element name="port" type="xs:token"/> <xs:element name="port" type="xs:token"/>
</xs:sequence> </xs:sequence>
</xs:group> </xs:group>
</xs:schema> </xs:schema>
DSL measurement schema DSL Measurement Schema
9. IANA Considerations 9. IANA Considerations
This section creates a registry for GNSS types (Section 5.5) and This section creates a registry for GNSS types (Section 5.5) and
registers the namespaces and schema defined in Section 8. registers the namespaces and schemas defined in Section 8.
9.1. IANA Registry for GNSS Types 9.1. IANA Registry for GNSS Types
This document establishes a new IANA registry for "Global Navigation This document establishes a new IANA registry for "Global Navigation
Satellite System (GNSS) types". The registry includes tokens for the Satellite System (GNSS)" types. The registry includes tokens for the
GNSS type and for each of the signals within that type. Referring to GNSS type and for each of the signals within that type. Referring to
[RFC5226], this registry operates under "Specification Required" [RFC5226], this registry operates under "Specification Required"
rules. The IESG will appoint an Expert Reviewer who will advise IANA rules. The IESG will appoint an Expert Reviewer who will advise IANA
promptly on each request for a new or updated GNSS type. promptly on each request for a new or updated GNSS type.
Each entry in the registry requires the following information: Each entry in the registry requires the following information:
GNSS name: the name of the GNSS GNSS Name: the name of the GNSS
Brief description: a brief description of the GNSS Brief Description: a brief description of the GNSS
GNSS token: a token that can be used to identify 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 Signals: a set of tokens that represent each of the signals that the
system provides system provides
Documentation reference: a reference to one or more stable, public Documentation Reference: a reference to one or more stable, public
specifications that outline usage of the GNSS, including (but not specifications that outline usage of the GNSS, including (but not
limited to) signal specifications and time systems limited to) signal specifications and time systems
The registry initially includes two registrations: The registry initially includes two registrations:
GNSS name: Global Positioning System (GPS) GNSS Name: Global Positioning System (GPS)
Brief description: a system of satellites that use spread-spectrum Brief Description: a system of satellites that use spread-spectrum
transmission, operated by the US military for commercial and transmission, operated by the US military for commercial and
military applications military applications
GNSS token: gps GNSS Token: gps
Signals: L1, L2, L1C, L2C, L5 Signals: L1, L2, L1C, L2C, L5
Documentation reference: Navstar GPS Space Segment/Navigation User Documentation Reference: Navstar GPS Space Segment/Navigation User
Interface [GPS.ICD] Interface [GPS.ICD]
GNSS name: Galileo GNSS Name: Galileo
Brief description: a system of satellites that operate in the same Brief Description: a system of satellites that operate in the same
spectrum as GPS, operated by the European Union for commercial spectrum as GPS, operated by the European Union for commercial
applications applications
GNSS Token: galileo GNSS Token: galileo
Signals: L1, E5A, E5B, E5A+B, E6 Signals: L1, E5A, E5B, E5A+B, E6
Documentation Reference: Galileo Open Service Signal In Space Documentation Reference: Galileo Open Service Signal In Space
Interface Control Document (SIS ICD) [Galileo.ICD] Interface Control Document (SIS ICD) [Galileo.ICD]
9.2. URN Sub-Namespace Registration for 9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines
in [RFC3688]. in [RFC3688].
URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group
(geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>Measurement Source for PIDF-LO</title> <title>Measurement Source for PIDF-LO</title>
</head> </head>
<body> <body>
<h1>Namespace for Location Measurement Source</h1> <h1>Namespace for Location Measurement Source</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc</h2> <h2>urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
with the RFC number for this specification.]] RFC 7105</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
9.3. URN Sub-Namespace Registration for 9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm urn:ietf:params:xml:ns:geopriv:lm
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm URI: urn:ietf:params:xml:ns:geopriv:lm
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group
(geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>Measurement Container</title> <title>Measurement Container</title>
</head> </head>
<body> <body>
<h1>Namespace for Location Measurement Container</h1> <h1>Namespace for Location Measurement Container</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm</h2> <h2>urn:ietf:params:xml:ns:geopriv:lm</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
with the RFC number for this specification.]] RFC 7105</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
9.4. URN Sub-Namespace Registration for 9.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:basetypes urn:ietf:params:xml:ns:geopriv:lm:basetypes
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines
in [RFC3688]. in [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes
Registrant Contact: IETF, GEOPRIV working group
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
(geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>Base Device Types</title> <title>Base Device Types</title>
</head> </head>
<body> <body>
<h1>Namespace for Base Types</h1> <h1>Namespace for Base Types</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:basetypes</h2> <h2>urn:ietf:params:xml:ns:geopriv:lm:basetypes</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
with the RFC number for this specification.]] RFC 7105</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
9.5. URN Sub-Namespace Registration for 9.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:lldp urn:ietf:params:xml:ns:geopriv:lm:lldp
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:lldp URI: urn:ietf:params:xml:ns:geopriv:lm:lldp
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group
(geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>LLDP Measurement Set</title> <title>LLDP Measurement Set</title>
</head> </head>
<body> <body>
<h1>Namespace for LLDP Measurement Set</h1> <h1>Namespace for LLDP Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:lldp</h2> <h2>urn:ietf:params:xml:ns:geopriv:lm:lldp</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
with the RFC number for this specification.]] RFC 7105</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
9.6. URN Sub-Namespace Registration for 9.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dhcp urn:ietf:params:xml:ns:geopriv:lm:dhcp
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group
(geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>DHCP Measurement Set</title> <title>DHCP Measurement Set</title>
</head> </head>
<body> <body>
<h1>Namespace for DHCP Measurement Set</h1> <h1>Namespace for DHCP Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:dhcp</h2> <h2>urn:ietf:params:xml:ns:geopriv:lm:dhcp</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
with the RFC number for this specification.]] RFC 7105</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
9.7. URN Sub-Namespace Registration for 9.7. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:wifi urn:ietf:params:xml:ns:geopriv:lm:wifi
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in
[RFC3688]. [RFC3688].
skipping to change at page 65, line 16 skipping to change at page 66, line 4
END END
9.7. URN Sub-Namespace Registration for 9.7. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:wifi urn:ietf:params:xml:ns:geopriv:lm:wifi
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:wifi URI: urn:ietf:params:xml:ns:geopriv:lm:wifi
Registrant Contact: IETF, GEOPRIV working group
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
(geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>WiFi Measurement Set</title> <title>WiFi Measurement Set</title>
</head> </head>
<body> <body>
<h1>Namespace for WiFi Measurement Set</h1> <h1>Namespace for WiFi Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:wifi</h2> <h2>urn:ietf:params:xml:ns:geopriv:lm:wifi</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
with the RFC number for this specification.]] RFC 7105</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
9.8. URN Sub-Namespace Registration for 9.8. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:cell urn:ietf:params:xml:ns:geopriv:lm:cell
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:cell URI: urn:ietf:params:xml:ns:geopriv:lm:cell
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group
(geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>Cellular Measurement Set</title> <title>Cellular Measurement Set</title>
</head> </head>
<body> <body>
<h1>Namespace for Cellular Measurement Set</h1> <h1>Namespace for Cellular Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:cell</h2> <h2>urn:ietf:params:xml:ns:geopriv:lm:cell</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
with the RFC number for this specification.]] RFC 7105</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
9.9. URN Sub-Namespace Registration for 9.9. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:gnss urn:ietf:params:xml:ns:geopriv:lm:gnss
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:gnss URI: urn:ietf:params:xml:ns:geopriv:lm:gnss
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group
(geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>GNSS Measurement Set</title> <title>GNSS Measurement Set</title>
</head> </head>
<body> <body>
<h1>Namespace for GNSS Measurement Set</h1> <h1>Namespace for GNSS Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:gnss</h2> <h2>urn:ietf:params:xml:ns:geopriv:lm:gnss</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
with the RFC number for this specification.]] RFC 7105</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
9.10. URN Sub-Namespace Registration for 9.10. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dsl urn:ietf:params:xml:ns:geopriv:lm:dsl
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:lm:dsl URI: urn:ietf:params:xml:ns:geopriv:lm:dsl
Registrant Contact: IETF, GEOPRIV working group
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
(geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>DSL Measurement Set</title> <title>DSL Measurement Set</title>
</head> </head>
<body> <body>
<h1>Namespace for DSL Measurement Set</h1> <h1>Namespace for DSL Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:dsl</h2> <h2>urn:ietf:params:xml:ns:geopriv:lm:dsl</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
with the RFC number for this specification.]] RFC 7105</a>.</p>
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
9.11. XML Schema Registration for Measurement Source Schema 9.11. XML Schema Registration for Measurement Source Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@commscope.com). Martin Thomson (martin.thomson@gmail.com).
Schema: The XML for this schema can be found in Section 8.2 of this Schema: The XML for this schema can be found in Section 8.2 of this
document. document.
9.12. XML Schema Registration for Measurement Container Schema 9.12. XML Schema Registration for Measurement Container Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm URI: urn:ietf:params:xml:schema:geopriv:lm
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@commscope.com). Martin Thomson (martin.thomson@gmail.com).
Schema: The XML for this schema can be found in Section 8.1 of this Schema: The XML for this schema can be found in Section 8.1 of this
document. document.
9.13. XML Schema Registration for Base Types Schema 9.13. XML Schema Registration for Base Types Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:basetypes URI: urn:ietf:params:xml:schema:geopriv:lm:basetypes
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@commscope.com). Martin Thomson (martin.thomson@gmail.com).
Schema: The XML for this schema can be found in Section 8.3 of this Schema: The XML for this schema can be found in Section 8.3 of this
document. document.
9.14. XML Schema Registration for LLDP Schema 9.14. XML Schema Registration for LLDP Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:lldp URI: urn:ietf:params:xml:schema:geopriv:lm:lldp
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@commscope.com). Martin Thomson (martin.thomson@gmail.com).
Schema: The XML for this schema can be found in Section 8.4 of this Schema: The XML for this schema can be found in Section 8.4 of this
document. document.
9.15. XML Schema Registration for DHCP Schema 9.15. XML Schema Registration for DHCP Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:dhcp URI: urn:ietf:params:xml:schema:geopriv:lm:dhcp
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Martin Thomson (martin.thomson@commscope.com). 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 Schema: The XML for this schema can be found in Section 8.5 of this
document. document.
9.16. XML Schema Registration for WiFi Schema 9.16. XML Schema Registration for WiFi Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:wifi URI: urn:ietf:params:xml:schema:geopriv:lm:wifi
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@commscope.com). Martin Thomson (martin.thomson@gmail.com).
Schema: The XML for this schema can be found in Section 8.6 of this Schema: The XML for this schema can be found in Section 8.6 of this
document. document.
9.17. XML Schema Registration for Cellular Schema 9.17. XML Schema Registration for Cellular Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:cellular URI: urn:ietf:params:xml:schema:geopriv:lm:cell
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@commscope.com). Martin Thomson (martin.thomson@gmail.com).
Schema: The XML for this schema can be found in Section 8.7 of this Schema: The XML for this schema can be found in Section 8.7 of this
document. document.
9.18. XML Schema Registration for GNSS Schema 9.18. XML Schema Registration for GNSS Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:gnss URI: urn:ietf:params:xml:schema:geopriv:lm:gnss
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@commscope.com). Martin Thomson (martin.thomson@gmail.com).
Schema: The XML for this schema can be found in Section 8.8 of this Schema: The XML for this schema can be found in Section 8.8 of this
document. document.
9.19. XML Schema Registration for DSL Schema 9.19. XML Schema Registration for DSL Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:lm:dsl URI: urn:ietf:params:xml:schema:geopriv:lm:dsl
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Martin Thomson (martin.thomson@commscope.com). Martin Thomson (martin.thomson@gmail.com).
Schema: The XML for this schema can be found in Section 8.9 of this Schema: The XML for this schema can be found in Section 8.9 of this
document. document.
10. Acknowledgements 10. Acknowledgements
Thanks go to Simon Cox for his comments relating to terminology that Thanks go to Simon Cox for his comments relating to terminology; his
have helped ensure that this document is aligned with ongoing work in comments have helped ensure that this document is aligned with
the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his ongoing work in the Open Geospatial Consortium (OGC). Thanks to Neil
review and comments on the GNSS sections of this document. Thanks to Harper for his review and comments on the GNSS sections of this
Noor-E-Gagan Singh, Gabor Bajko, Russell Priebe, and Khalid Al-Mufti document. Thanks to Noor-E-Gagan Singh, Gabor Bajko, Russell Priebe,
for their significant input to and suggestions for improving the and Khalid Al-Mufti for their significant input to, and suggestions
802.11 measurements. Thanks to Cullen Jennings for feedback and for, improving the 802.11 measurements. Thanks to Cullen Jennings
suggestions. Bernard Aboba provided review and feedback on a range for feedback and suggestions. Bernard Aboba provided review and
of measurement data definitions. Mary Barnes and Geoff Thompson feedback on a range of measurement data definitions. Mary Barnes and
provided a review and corrections. David Waitzman and John Bressler Geoff Thompson provided a review and corrections. David Waitzman and
both noted shortcomings with 802.11 measurements. Keith Drage, John Bressler both noted shortcomings with 802.11 measurements.
Darren Pawson provided expert LTE knowledge. Keith Drage and Darren Pawson provided expert LTE knowledge.
11. References 11. References
11.1. Normative References 11.1. Normative References
[ASCII] , "US-ASCII. Coded Character Set - 7-Bit American Standard [ASCII] ANSI, "US-ASCII. Coded Character Set - 7-Bit American
Code for Information Interchange. Standard ANSI X3.4-1986, Standard Code for Information Interchange. Standard ANSI
ANSI, 1986.", . X3.4-1986", 1986.
[GPS.ICD] , "Navstar GPS Space Segment/Navigation User Interface", [GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface", ICD
ICD GPS-200, Apr 2000. GPS-200, April 2000.
[Galileo.ICD] [Galileo.ICD]
GJU, "Galileo Open Service Signal In Space Interface GJU, "Galileo Open Service Signal In Space Interface
Control Document (SIS ICD)", May 2006. Control Document (SIS ICD)", May 2006.
[IANA.enterprise] [IANA.enterprise]
IANA, "Private Enterprise Numbers", 2011, IANA, "Private Enterprise Numbers", 2014,
<http://www.iana.org/assignments/enterprise-numbers>. <http://www.iana.org/assignments/enterprise-numbers>.
[IEEE.80211] [IEEE.80211]
IEEE, "Wireless LAN Medium Access Control (MAC) and IEEE, "Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) specifications", IEEE Std Physical Layer (PHY) Specifications", IEEE
802.11-2012, March 2012. Std 802.11-2012, March 2012.
[IEEE.8021AB] [IEEE.8021AB]
IEEE, "IEEE Standard for Local and Metropolitan area IEEE, "IEEE Standard for Local and Metropolitan Area
networks, Station and Media Access Control Connectivity Networks, Station and Media Access Control Connectivity
Discovery", IEEE Std 802.1AB-2009, September 2009. Discovery", IEEE Std 802.1AB-2009, September 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
3046, January 2001. RFC 3046, January 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of
10646", STD 63, RFC 3629, November 2003. ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, January 2005.
[RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
Suboption for the Dynamic Host Configuration Protocol Suboption for the Dynamic Host Configuration Protocol
(DHCP) Relay Agent Option", RFC 3993, March 2005. (DHCP) Relay Agent Option", RFC 3993, March 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580,
2006. June 2006.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
2006. August 2006.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
5985, September 2010. RFC 5985, September 2010.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986, September Location Information Server (LIS)", RFC 5986,
2010. September 2010.
[TIA-2000.5] [TIA-2000.5]
TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for
cdma2000(R) Spread Spectrum Systems", TIA-2000.5-D, March cdma2000(R) Spread Spectrum Systems", TR-45.5 / TSG-C
2004. TIA-2000.5-E / C.S0005-E v1.0, September 2009.
[TS.3GPP.23.003] [TS.3GPP.23.003]
3GPP, "Numbering, addressing and identification", 3GPP TS 3GPP, "Numbering, addressing and identification", 3GPP TS
23.003 9.4.0, September 2010. 23.003 12.0.0, September 2013,
<http://www.3gpp.org/ftp/Specs/html-info/23003.htm>.
11.2. Informative References 11.2. Informative References
[ANSI-TIA-1057] [ANSI-TIA-1057]
ANSI/TIA, "Link Layer Discovery Protocol for Media ANSI/TIA, "Link Layer Discovery Protocol for Media
Endpoint Devices", TIA 1057, April 2006. Endpoint Devices", TIA 1057, April 2006.
[DSL.TR025] [DSL.TR025]
Wang, R., "Core Network Architecture Recommendations for Wang, R., "Core Network Architecture Recommendations for
Access to Legacy Data Networks over ADSL", September 1999. Access to Legacy Data Networks over ADSL", September 1999.
[DSL.TR101] [DSL.TR101]
Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
Aggregation", April 2006. Aggregation", April 2006.
[GPS.SPOOF] [GPS.SPOOF]
Scott, L., "Anti-Spoofing and Authenticated Signal Scott, L., "Anti-Spoofing and Authenticated Signal
Architectures for Civil Navigation Signals", ION-GNSS Architectures for Civil Navigation Signals", ION-GNSS
Portland, Oregon, 2003. Portland, Oregon, 2003.
[HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side [HARPER] Harper, N., "Server-side GPS and Assisted-GPS in Java",
spoofing and detection for Assisted-GPS", Proceedings of December 2009.
International Global Navigation Satellite Systems Society
(IGNSS) Symposium 2009 16, December 2009,
<http://ignss.org/files/Paper16.pdf>.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999. RFC 2661, August 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC "Remote Authentication Dial In User Service (RADIUS)",
2865, June 2000. RFC 2865, June 2000.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
skipping to change at page 73, line 31 skipping to change at page 74, line 13
Delivery (HELD)", RFC 6155, March 2011. Delivery (HELD)", RFC 6155, March 2011.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, July 2011. BCP 160, RFC 6280, July 2011.
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Microsoft Mozilla
3210 Porter Drive Suite 300
Palo Alto, CA 94304 650 Castro Street
Mountain View, CA 94041
US US
Phone: +1 650-353-1925 EMail: martin.thomson@gmail.com
Email: martin.thomson@skype.net
James Winterbottom James Winterbottom
Unaffiliated Unaffiliated
AU AU
Email: a.james.winterbottom@gmail.com EMail: a.james.winterbottom@gmail.com
 End of changes. 322 change blocks. 
1084 lines changed or deleted 1064 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/