idnits 2.17.1 draft-thomson-geopriv-held-measurements-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 27, 2010) is 5083 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-5' is mentioned on line 1361, but not defined == Missing Reference: '0-4' is mentioned on line 1361, but not defined == Missing Reference: '0-9' is mentioned on line 1361, but not defined == Missing Reference: '0-1' is mentioned on line 1361, but not defined == Unused Reference: 'I-D.thomson-geopriv-uncertainty' is defined on line 2950, but no explicit reference was found in the text == Unused Reference: 'RFC5808' is defined on line 2993, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-06) exists of draft-ietf-geopriv-held-identity-extensions-03 == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-04 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft J. Winterbottom 4 Intended status: Standards Track Andrew 5 Expires: November 28, 2010 May 27, 2010 7 Using Device-provided Location-Related Measurements in Location 8 Configuration Protocols 9 draft-thomson-geopriv-held-measurements-06 11 Abstract 13 A method is described by which a Device is able to provide location- 14 related measurement data to a LIS within a request for location 15 information. Location-related measurement information are 16 observations concerning properties related to the position of a 17 Device, which could be data about network attachment or about the 18 physical environment. When a LIS generates location information for 19 a Device, information from the Device can improve the accuracy of the 20 location estimate. A basic set of location-related measurements are 21 defined, including common modes of network attachment as well as 22 assisted Global Navigation Satellite System (GNSS) parameters. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 28, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Conventions used in this document . . . . . . . . . . . . . . 5 72 3. Location-Related Measurements in LCPs . . . . . . . . . . . . 6 73 4. Location-Related Measurement Data Types . . . . . . . . . . . 7 74 4.1. Measurement Container . . . . . . . . . . . . . . . . . . 8 75 4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 8 76 4.1.2. Expiry Time on Location-Related Measurement Data . . . 8 77 4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 9 78 4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . . 9 79 4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 10 80 4.4. Identifying Location Provenance . . . . . . . . . . . . . 11 81 5. Location-Related Measurement Data Types . . . . . . . . . . . 13 82 5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 13 83 5.2. DHCP Relay Agent Information Measurements . . . . . . . . 13 84 5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 14 85 5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 16 86 5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 17 87 5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 20 88 5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 20 89 5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . . 22 90 5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . . 23 92 5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 24 93 5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 24 94 5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 25 95 5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 25 96 5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 26 97 5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 26 98 6. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 26 99 6.1. Measurement Container Schema . . . . . . . . . . . . . . . 27 100 6.2. Measurement Source Schema . . . . . . . . . . . . . . . . 29 101 6.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . . 29 102 6.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 32 103 6.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 33 104 6.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 35 105 6.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 37 106 6.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 39 107 6.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . . 41 108 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 43 109 7.1. Measurement Data Privacy Model . . . . . . . . . . . . . . 43 110 7.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . . 44 111 7.3. Measurement Data and Location URIs . . . . . . . . . . . . 44 112 7.4. Third-Party-Provided Measurement Data . . . . . . . . . . 44 113 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 114 8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 45 115 8.1.1. Acquiring Location Information Without 116 Authorization . . . . . . . . . . . . . . . . . . . . 45 117 8.1.2. Extracting Network Topology Data . . . . . . . . . . . 46 118 8.1.3. Lying By Proxy . . . . . . . . . . . . . . . . . . . . 47 119 8.1.4. Measurement Replay . . . . . . . . . . . . . . . . . . 48 120 8.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 48 121 8.2.1. Measurement Validation . . . . . . . . . . . . . . . . 49 122 8.2.2. Location Validation . . . . . . . . . . . . . . . . . 50 123 8.2.3. Supporting Observations . . . . . . . . . . . . . . . 51 124 8.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 53 125 8.2.5. Stateful Correlation of Location Requests . . . . . . 54 126 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 127 9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 54 128 9.2. URN Sub-Namespace Registration for 129 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 55 130 9.3. URN Sub-Namespace Registration for 131 urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 56 132 9.4. URN Sub-Namespace Registration for 133 urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 57 134 9.5. URN Sub-Namespace Registration for 135 urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . . 57 136 9.6. URN Sub-Namespace Registration for 137 urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . . 58 138 9.7. URN Sub-Namespace Registration for 139 urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . . 59 140 9.8. URN Sub-Namespace Registration for 141 urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . . 59 142 9.9. URN Sub-Namespace Registration for 143 urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . . 60 144 9.10. URN Sub-Namespace Registration for 145 urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 61 146 9.11. XML Schema Registration for Measurement Source Schema . . 61 147 9.12. XML Schema Registration for Measurement Container 148 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 62 149 9.13. XML Schema Registration for Base Types Schema . . . . . . 62 150 9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 62 151 9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 62 152 9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 63 153 9.17. XML Schema Registration for Cellular Schema . . . . . . . 63 154 9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 63 155 9.19. XML Schema Registration for DSL Schema . . . . . . . . . . 64 156 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 157 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 158 11.1. Normative References . . . . . . . . . . . . . . . . . . . 64 159 11.2. Informative References . . . . . . . . . . . . . . . . . . 65 160 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 162 1. Introduction 164 A location configuration protocol (LCP) provides a means for a Device 165 to request information about its physical location from an access 166 network. A location information server (LIS) is the server that 167 provides location information; information that is available due to 168 the knowledge about the network and physical environment that is 169 available to the LIS. 171 As a part of the access network, the LIS is able to acquire 172 measurement results from network Devices within the network that are 173 related to Device location. The LIS also has access to information 174 about the network topology that can be used to turn measurement data 175 into location information. However, this information can be enhanced 176 with information acquired from the Device itself. 178 A Device is able to make observations about its network attachment, 179 or its physical environment. The location-related measurement data 180 might be unavailable to the LIS; alternatively, the LIS might be able 181 to acquire the data, but at a higher cost in time or otherwise. 182 Providing measurement data gives the LIS more options in determining 183 location, which could improve the quality of the service provided by 184 the LIS. Improvements in accuracy are one potential gain, but 185 improved response times and lower error rates are also possible. 187 This document describes a means for a Device to report location- 188 related measurement data to the LIS. Examples based on the HELD 189 [I-D.ietf-geopriv-http-location-delivery] location configuration 190 protocol are provided. 192 2. Conventions used in this document 194 The terms LIS and Device are used in this document in a manner 195 consistent with the usage in 196 [I-D.ietf-geopriv-http-location-delivery]. 198 This document also uses the following definitions: 200 Location Measurement: An observation about the physical properties 201 of a particular Device's network access. The result of a location 202 measurement--"location-related measurement data", or simply 203 "measurement data" given sufficient context--can be used to 204 determine the location of a Device. Location-related measurement 205 data does not identify a Device; measurement data can change with 206 time if the location of the Device also changes. 208 Location-related measurement data does not necessarily contain 209 location information directly, but it can be used in combination 210 with contextual knowledge of the network, or algorithms to derive 211 location information. Examples of location-related measurement 212 data are: radio signal strength or timing measurements, Ethernet 213 switch and port identifiers. 215 Location-related measurement data can be considered sighting 216 information, based on the definition in [RFC3693]. 218 Location Estimate: The result of location determination, a location 219 estimate is an approximation of where the Device is located. 220 Location estimates are subject to uncertainty, which arise from 221 errors in measurement results. 223 GNSS: Global Navigation Satellite System. A satellite-based system 224 that provides positioning and time information. For example, the 225 US Global Positioning System (GPS) or the European Galileo system. 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in [RFC2119]. 231 3. Location-Related Measurements in LCPs 233 This document defines a standard container for the conveyance of 234 location-related measurement parameters in location configuration 235 protocols. This is an XML container that identifies parameters by 236 type and allows the Device to provide the results of any measurement 237 it is able to perform. A set of measurement schemas are also defined 238 that can be carried in the generic container. 240 The simplest example of measurement data conveyance is illustrated by 241 the example message in Figure 1. This shows a HELD location request 242 message with an Ethernet switch and port measurement taken using LLDP 243 [IEEE.8021AB]. 245 246 civic 247 249 250 0a01003c 251 c2 252 253 254 255 Figure 1: HELD Location Request with Measurement Data 257 Measurement data that the LIS does not support or understand can be 258 ignored. The measurements defined in this document follow this rule; 259 extensions that could result in backward incompatibility MUST be 260 added as new measurement definitions rather than extensions to 261 existing types. 263 Multiple sets of measurement data, either of the same type or from 264 different sources can be included in the "measurements" element. See 265 Section 4.1.1 for details on repetition of this element. 267 Use of location-related measurement data is at the discretion of the 268 LIS, but the "method" parameter in the PIDF-LO SHOULD be adjusted to 269 reflect the method used. 271 Location-related measurement data need not be provided exclusively by 272 Devices. A third party location requester can request location 273 information using measurement data, if they are able and authorized. 274 There are privacy considerations relating to the use of measurements 275 by third parties, which are discussed in Section 7.4. 277 Location-related measurement data and its use presents a number of 278 security challenges. These are described in more detail in 279 Section 8. 281 4. Location-Related Measurement Data Types 283 A common container is defined for the expression of location 284 measurement data, as well as a simple means of identifying specific 285 types of measurement data for the purposes of requesting them. 287 The following example shows a measurement container with measurement 288 time and expiration time included. A WiFi measurement is enclosed. 290 293 294 295 wlan-home 296 00-12-F0-A0-80-EF 297 298 299 301 Figure 2: Measurement Example 303 4.1. Measurement Container 305 The "measurement" element is used to encapsulate measurement data 306 that is collected at a certain point in time. It contains time-based 307 attributes that are common to all forms of measurement data, and 308 permits the inclusion of arbitrary measurement data. 310 This container can be added to any request for location information, 311 such as a HELD location request 312 [I-D.ietf-geopriv-http-location-delivery]. 314 4.1.1. Time of Measurement 316 The "time" attribute records the time that the measurement or 317 observation was made. This time can be different to the time that 318 the measurement information was reported. Time information can be 319 used to populate a timestamp on the location result, or to determine 320 if the measurement information is used. 322 The "time" attribute is optional to avoid forcing an arbitrary choice 323 of timestamp for relatively static types of measurement (for 324 instance, the DSL measurements in Section 5.6) and for legacy Devices 325 that don't record time information (such as the Home Location 326 Register/Home Subscriber Server for cellular). However, time SHOULD 327 be provided whenever possible. 329 The "time" attribute is attached to the root "measurement" element. 330 If it is necessary to provide multiple sets of measurement data with 331 different times, multiple "measurement" elements SHOULD be provided. 333 4.1.2. Expiry Time on Location-Related Measurement Data 335 A Device is able to indicate an expiry time in the location 336 measurement using the "expires" attribute. Nominally, this attribute 337 indicates how long information is expected to be valid for, but it 338 can also indicate a time limit on the retention and use of the 339 measurement data. A Device can use this attribute to prevent the LIS 340 from retaining measurement data or limit the time that a LIS retains 341 this information. 343 Note: Movement of a Device might result in the measurement data 344 being invalidated before the expiry time. 346 The LIS MUST NOT keep location-related measurement data beyond the 347 time indicated in the "expires" attribute. 349 4.2. RMS Error and Number of Samples 351 Often a measurement is taken more than once over a period of time. 352 Reporting the average of a number of measurement results mitigates 353 the effects of random errors that occur in the measurement process. 354 Typically, a mean value is reported at the end of the measurement 355 interval, but additional information about the distribution of the 356 results can be useful in determining location uncertainty. 358 Two optional attributes are provided for certain measurement values: 360 rmsError: The root-mean-squared (RMS) error of the set of 361 measurement values used in calculating the result. RMS error is 362 expressed in the same units as the measurement, unless otherwise 363 stated. If an accurate value for RMS error is not known, this 364 value can be used to indicate an upper bound for the RMS error. 366 samples: The number of samples that were taken in determining the 367 measurement value. If omitted, this value can be assumed to be a 368 very large value, so that the RMS error is an indication of the 369 standard deviation of the sample set. 371 For some measurement techniques, measurement error is largely 372 dependent on the measurement technique employed. In these cases, 373 measurement error is largely a product of the measurement technique 374 and not the specific circumstances, so RMS error does not need to be 375 actively measured. A fixed value MAY be provided for RMS error where 376 appropriate. 378 The "rmsError" and "samples" elements are added as attributes of 379 specific measurement data types. 381 4.2.1. Time RMS Error 383 Measurement of time can be significant in certain circumstances. The 384 GNSS measurements included in this document are one such case where a 385 small error in time can result in a large error in location. Factors 386 such as clock drift and errors in time sychronization can result in 387 small, but significant, time errors. Including an indication of the 388 quality of the time can be helpful. 390 An optional "timeError" attribute can be added to the "measurement" 391 element to indicate the RMS error in time. "timeError" indicates an 392 upper bound on the time RMS error in seconds. 394 The "timeError" attribute does not apply where multiple samples of a 395 measurement is taken over time. If multiple samples are taken, each 396 SHOULD be included in a different "measurement" element. 398 4.3. Measurement Request 400 A measurement request is used by a protocol peer to describe a set of 401 measurement data that it desires. A "measurementRequest" element is 402 defined that can be included in a protocol exchange. 404 For instance, a LIS can use a measurement request in HELD responses. 405 If the LIS is unable to provide location information, but it believes 406 that a particular measurement type would enable it to provide a 407 location, it can include a measurement request in an error response. 409 The "measurement" element of the measurement request identifies the 410 type of measurement that is requested. The "type" attribute of this 411 element indicates the type of measurement, as identified by an XML 412 qualified name. An optional "samples" attribute indicates how many 413 samples of the identified measurement are requested. 415 The "measurement" element can be repeated to request multiple (or 416 alternative) measurement types. 418 Additional XML content might be defined for a particular measurement 419 type that is used to further refine a request. These elements either 420 constrain what is requested or specify optional components of the 421 measurement data that are needed. These are defined along with the 422 specific measurement type. 424 In the HELD protocol, the inclusion of a measurement request in a 425 error response with a code of "locationUnknown" indicates that the 426 LIS believes that providing the indicated measurements would increase 427 the likelihood of a subsequent request being successful. 429 The following example shows a HELD error response that indicates that 430 WiFi measurement data would be useful if a later request were made. 431 Additional elements indicate that received signal strength for an 432 802.11n access point is requested. 434 436 Insufficient measurement data 437 440 441 n 442 wifi:rssi 443 444 445 446 Figure 3 448 A measurement request that is included in other HELD messages has 449 undefined semantics and can be safely ignored. Other specifications 450 might define semantics for measurement requests under other 451 conditions. 453 4.4. Identifying Location Provenance 455 An extension is made to the PIDF-LO [RFC4119] that allows a location 456 recipient to identify the source (or sources) of location information 457 and the measurement data that was used to determine that location 458 information. 460 The "source" element is added to the "geopriv" element of the 461 PIDF-LO. This element does not identify specific entities. Instead, 462 it identifies the type of source. 464 The following types of measurement source are identified: 466 lis: Location information is based on measurement data that the LIS 467 or sources that it trusts have acquired. This label might be used 468 if measurement data provided by the Device has been completely 469 validated by the LIS. 471 device: Location information is based on measurement data that the 472 Device has provided to the LIS. 474 other: Location information is based on measurement data that a 475 third party has provided. This might be an authorized third party 476 that uses identity parameters 477 [I-D.ietf-geopriv-held-identity-extensions] or any other entity. 479 No assertion is made about the veracity of the measurement data from 480 sources other than the LIS. A combination of tags MAY be included to 481 indicate that measurement data from both sources was used. 483 For example, the first tuple of the following PIDF-LO indicates that 484 measurement data from a LIS and a device was combined to produce the 485 result, the second tuple was produced by the LIS alone. 487 493 494 495 496 497 498 7.34324 134.47162 499 500 850.24 501 502 503 504 505 OTDOA 506 lis device 507 508 509 510 511 512 513 514 515 7.34379 134.46484 516 517 9000 518 519 520 521 522 Cell 523 lis 524 525 526 527 529 5. Location-Related Measurement Data Types 531 This document defines location-related measurement data types for a 532 range of common network types. 534 5.1. LLDP Measurements 536 LLDP messages are sent between adjacent nodes in an IEEE 802 network 537 (e.g. wired Ethernet, WiFi, 802.16). These messages all contain 538 identification information for the sending node, which can be used to 539 determine location information. A Device that receives LLDP messages 540 can report this information as a location-related measurement to the 541 LIS, which is then able to use the measurement data in determining 542 the location of the Device. 544 The Device MUST report the values directly as they were provided by 545 the adjacent node. Attempting to adjust or translate the type of 546 identifier is likely to cause the measurement data to be useless. 548 Where a Device has received LLDP messages from multiple adjacent 549 nodes, it should provide information extracted from those messages by 550 repeating the "lldp" element. 552 An example of an LLDP measurement is shown in Figure 4. This shows 553 an adjacent node (chassis) that is identified by the IP address 554 192.0.2.45 (hexadecimal c000022d) and the port on that node is 555 numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2). 557 559 560 c000022d 561 a2 562 563 565 Figure 4: LLDP Measurement Example 567 IEEE 802 Devices that are able to obtain information about adjacent 568 network switches and their attachment to them by other means MAY use 569 this data type to convey this information. 571 5.2. DHCP Relay Agent Information Measurements 573 The DHCP Relay Agent Information option [RFC3046] provides 574 measurement data about the network attachment of a Device. This 575 measurement data can be included in the "dhcp-rai" element. 577 The elements in the DHCP relay agent information options are opaque 578 data types assigned by the DHCP relay agent. The three items are all 579 optional: circuit identifier ("circuit", [RFC3046]), remote 580 identifier ("remote", [RFC3046], [RFC4649]) and subscriber identifier 581 ("subscriber", [RFC3993], [RFC4580]). The DHCPv6 remote identifier 582 has an associated enterprise number [IANA.enterprise] as an XML 583 attribute. 585 587 588 ::ffff:192.0.2.158 589 108b 590 591 593 Figure 5: DHCP Relay Agent Information Measurement Example 595 The "giaddr" is specified as a dotted quad IPv4 address or an RFC 596 4291 [RFC4291] IPv6 address. The enterprise number is specified as a 597 decimal integer. All other information is included verbatim from the 598 DHCP request in hexadecimal format. 600 5.3. 802.11 WLAN Measurements 602 In WiFi, or 802.11, networks a Device might be able to provide 603 information about the wireless access point (WAP) that it is attached 604 to, or other WiFi points it is able to see. This is provided using 605 the "wifi" element, as shown in Figure 6. 607 609 610 Example WiFi Device 611 612 wlan-home 613 00-12-F0-A0-80-EF 614 7 615 -55 616 617 618 wlan-home 619 00-12-F0-A0-80-F0 620 -65 621 622 623 vendordefault 624 00-12-F0-A0-80-F1 625 -68 626 627 628 ironicname 629 00-12-F0-A0-80-F2 630 -75 631 632 633 635 Figure 6: 802.11 WLAN Measurement Example 637 A wifi element is made up of a serving WAP, zero or more neighbouring 638 WAPs, and an optional "nicType" element. Each WAP element is 639 comprised of the following fields: 641 ssid: The service set identifier for the wireless network. This 642 parameter MAY be provided. 644 bssid: The basic service set identifier. In an Infrastructure BSS 645 network, the bssid is the 48 bit MAC address of the wireless 646 access point, and it MUST be provided. 648 wapname: The broadcast name for the wireless access point. This 649 element is optional. 651 location: The location of the wireless access point, as reported 652 using by the wireless access point. This optional element 653 contains GML geometry, following the restrictions described in 654 [RFC5491]. 656 type: The network type for the network access. This element 657 includes the alphabetic suffix of the 802.11 specification that 658 defines the radio interface; e.g. "a", "b", "g", or "n". This 659 element is optional. 661 channel: The channel number (frequency) that the wireless access 662 point operates on. This element is optional. 664 rssi: The received signal strength indicator of the WAP as seen by 665 the wireless receiver. This value SHOULD be in units of dBm (with 666 RMS error in dB). If the units are unknown, the "dBm" attribute 667 MUST be set to "false". Signal strength reporting on current 668 hardware uses a range of different units; therefore, the value of 669 the "nicType" element SHOULD be included if the units are not 670 known to be in dBm and the value reported by the hardware should 671 be included without modification. This element is optional and 672 includes optional "rmsError" and "samples" attributes. 674 snr: The signal to noise ratio measured by the Device, in dBm. This 675 element is optional and includes optional "rmsError" and "samples" 676 attributes. 678 rtt: The total round trip time from the time that a request is sent 679 by the Device to the time that it receives the response from the 680 access point. This measurement includes any delays that might 681 occur between the time that the access point receives the message 682 and the time that it sends the response. If the delay at an 683 access point is known, this value can be used to calculate an 684 approximate distance between device and access point. This 685 element is optional and includes optional "rmsError" and "samples" 686 attributes. 688 The "nicType" element is used to specify the make and model of the 689 wireless network interface in the Device. Different 802.11 chipsets 690 report the signal strength in different ways, so the network 691 interface type must be specified in order for the LIS to use signal 692 strength indicators as part of its location determination process. 693 The content of this field is unconstrained and no mechanisms are 694 specified to ensure uniqueness. 696 5.3.1. Wifi Measurement Requests 698 Two elements are defined for requesting WiFi measurements in a 699 measurement request: 701 type: The "type" element identifies the desired type (or types that 702 are requested. 704 parameter: The "parameter" element identifies an optional 705 measurements are requested for each measured access point. An 706 element is identified by its qualified name. 708 Multiple types or parameters can be requested by repeating either 709 element. 711 5.4. Cellular Measurements 713 Cellular Devices are common throughout the world and base station 714 identifiers can provide a good source of coarse location information. 715 This information can be provided to a LIS run by the cellar operator, 716 or may be provided to an alternative LIS operator that has access to 717 one of several global cell-id to location mapping databases. 719 A number of advanced location determination methods have been 720 developed for cellular networks. For these methods a range of 721 measurement parameters can be collected by the network, Device, or 722 both in cooperation. This document includes a basic identifier for 723 the wireless transmitter only; future efforts might define additional 724 parameters that enable more accurate methods of location 725 determination. 727 The cellular measurement set allows a Device to report to a LIS any 728 LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9) or CDMA (Figure 10) 729 cells that it is able to observe. Cells are reported using their 730 global identifiers. All 3GPP cells are identified by public land 731 mobile network (PLMN), which is formed of mobile country code (MCC) 732 and mobile network code (MNC); specific fields are added for each 733 network type. All other values are decimal integers. 735 737 738 739 46520 740 80936424 741 742 743 46506 744 10736789 745 746 747 749 Long term evolution (LTE) cells are identified by a 28-bit cell 750 identifier (eucid). 752 Figure 7: Example LTE Cellular Measurement 754 756 757 758 46520 759 200065000 760 761 762 46506 763 1638332767 764 765 766 768 Universal mobile telephony service (UMTS) cells are identified by 769 radio network controller (rnc) and cell id (cid). 771 Figure 8: Example UMTS Cellular Measurement 773 775 776 777 46506 778 1638332767 779 780 781 783 Groupe Spe'ciale Mobile (GSM) cells are identified by local radio 784 network controller (rnc) and cell id (cid). 786 Figure 9: Example GSM Cellular Measurement 788 790 791 792 47231589212 793 794 795 47231589213 796 797 798 800 Code division multiple access (CDMA) cells are not identified by 801 PLMN, instead these use network id (nid), system id (sid) and base 802 station id (baseid). 804 Figure 10: Example CDMA Cellular Measurement 806 In general a cellular Device will be attached to the cellular network 807 and so the notion of a serving cell exists. Cellular network also 808 provide overlap between neighbouring sites, so a mobile Device can 809 hear more than one cell. The measurement schema supports sending 810 both the serving cell and any other cells that the mobile might be 811 able to hear. In some cases, the Device may simply be listening to 812 cell information without actually attaching to the network, mobiles 813 without a SIM are an example of this. In this case the Device may 814 simply report cells it can hear without flagging one as a serving 815 cell. An example of this is shown in Figure 11. 817 819 820 821 46520 822 200065000 823 824 825 46506 826 1638332767 827 828 829 831 Figure 11: Example Observed Cellular Measurement 833 5.4.1. Cellular Measurement Requests 835 Two elements can be used in measurement requests for cellular 836 measurements: 838 type: A label indicating the type of identifier to provide: one of 839 "gsm", "umts", "lte", or "cdma". 841 network: The network portion of the cell identifier. For 3GPP 842 networks, this is the combination of MCC and MNC; for CDMA, this 843 is the network identifier. 845 Multiple identifier types or networks can be identified by repeating 846 either element. 848 5.5. GNSS Measurements 850 GNSS use orbiting satellites to transmit signals. A Device with a 851 GNSS receiver is able to take measurements from the satellite 852 signals. The results of these measurements can be used to determine 853 time and the location of the Device. 855 Determining location and time in autonomous GNSS receivers follows 856 three steps: 858 Signal acquisition: During the signal acquisition stage, the 859 receiver searches for the repeating code that is sent by each GNSS 860 satellite. Successful operation typically requires measurement 861 data for a minimum of 5 satellites. At this stage, measurement 862 data is available to the Device. 864 Navigation message decode: Once the signal has been acquired, the 865 receiver then receives information about the configuration of the 866 satellite constellation. This information is broadcast by each 867 satellite and is modulated with the base signal at a low rate; for 868 instance, GPS sends this information at about 50 bits per second. 870 Calculation: The measurement data is combined with the data on the 871 satellite constellation to determine the location of the receiver 872 and the current time. 874 A Device that uses a GNSS receiver is able to report measurements 875 after the first stage of this process. A LIS can use the results of 876 these measurements to determine a location. In the case where there 877 are fewer results available than the optimal minimum, the LIS might 878 be able to use other sources of measurement information and combine 879 these with the available measurement data to determine a position. 881 Note: The use of different sets of GNSS _assistance data_ can 882 reduce the amount of time required for the signal acquisition 883 stage and obviate the need for the receiver to extract data on the 884 satellite constellation. Provision of assistance data is outside 885 the scope of this document. 887 Figure 12 shows an example of GNSS measurement data. The measurement 888 shown is for the GPS system and includes measurement data for three 889 satellites only. 891 893 895 896 499.9395 897 0.87595747 898 45 899 900 901 378.2657 902 0.56639479 903 52 904 905 906 -633.0309 907 0.57016835 908 48 909 910 911 913 Figure 12: Example GNSS Measurement 915 Each "gnss" element represents a single set of GNSS measurement data, 916 taken at a single point in time. Measurements taken at different 917 times can be included in different "gnss" elements to enable 918 iterative refinement of results. 920 GNSS measurement parameters are described in more detail in the 921 following sections. 923 5.5.1. GNSS System and Signal 925 The GNSS measurement structure is designed to be generic and to apply 926 to different GNSS types. Different signals within those systems are 927 also accounted for and can be measured separately. 929 The GNSS type determines the time system that is used. An indication 930 of the type of system and signal can ensure that the LIS is able to 931 correctly use measurements. 933 Measurements for multiple GNSS types and signals can be included by 934 repeating the "gnss" element. 936 This document creates an IANA registry for GNSS types. Two satellite 937 systems are registered by this document: GPS and Galileo. Details 938 for the registry are included in Section 9.1. 940 5.5.2. Time 942 Each set of GNSS measurements is taken at a specific point in time. 943 The "time" attribute is used to indicate the time that the 944 measurement was acquired, if the receiver knows how the time system 945 used by the GNSS relates to UTC time. 947 Alternative to (or in addition to) the measurement time, the 948 "gnssTime" element MAY be included. The "gnssTime" element includes 949 a relative time in milliseconds using the time system native to the 950 satellite system. For the GPS satellite system, the "gnssTime" 951 element includes the time of week in milliseconds. For the Galileo 952 system, the "gnssTime" element includes the time of day in 953 milliseconds. 955 The accuracy of the time measurement provided is critical in 956 determining the accuracy of the location information derived from 957 GNSS measurements. The receiver SHOULD indicate an estimated time 958 error for any time that is provided. An RMS error can be included 959 for the "gnssTime" element, with a value in milliseconds. 961 5.5.3. Per-Satellite Measurement Data 963 Multiple satellites are included in each set of GNSS measurements 964 using the "sat" element. Each satellite is identified by a number in 965 the "num" attribute. The satellite number is consistent with the 966 identifier used in the given GNSS. 968 Both the GPS and Galileo systems use satellite numbers between 1 and 969 64. 971 The GNSS receiver measures the following parameters for each 972 satellite: 974 doppler: The observed Doppler shift of the satellite signal, 975 measured in meters per second. This is converted from a value in 976 Hertz by the receiver to allow the measurement to be used without 977 knowledge of the carrier frequency of the satellite system. This 978 value includes an optional RMS error attribute, also measured in 979 meters per second. 981 codephase: The observed code phase for the satellite signal, 982 measured in milliseconds. This is converted from a value in chips 983 or wavelengths. Increasing values indicate increasing 984 pseudoranges. This value includes an optional RMS error 985 attribute, also measured in milliseconds. 987 cn0: The signal to noise ratio for the satellite signal, measured in 988 decibel-Hertz (dB-Hz). The expected range is between 20 and 50 989 dB-Hz. 991 mp: An estimation of the amount of error that multipath signals 992 contribute in metres. This parameter is optional. 994 cq: An indication of the carrier quality. Two attributes are 995 included: "continuous" may be either "true" or "false"; direct may 996 be either "direct" or "inverted". This parameter is optional. 998 adr: The accumulated Doppler range, measured in metres. This 999 parameter is optional and is not necessary unless multiple sets of 1000 GNSS measurements are provided. 1002 All values are converted from measures native to the satellite system 1003 to generic measures to ensure consistency of interpretation. Unless 1004 necessary, the schema does not constrain these values. 1006 5.5.4. GNSS Measurement Requests 1008 Measurement requests can include a "gnss" element, which includes the 1009 "system" and "signal" attributes. Multiple elements can be included 1010 to indicate a requests for GNSS measurements from multiple systems or 1011 signals. 1013 5.6. DSL Measurements 1015 Digital Subscriber Line (DSL) networks rely on a range of network 1016 technology. DSL deployments regularly require cooperation between 1017 multiple organizations. These fall into two broad categories: 1018 infrastructure providers and Internet service providers (ISPs). 1019 Infrastructure providers manage the bulk of the physical 1020 infrastructure including cabling. End users obtain their service 1021 from an ISP, which manages all aspects visible to the end user 1022 including IP address allocation and operation of a LIS. See 1023 [DSL.TR025] and [DSL.TR101] for further information on DSL network 1024 deployments. 1026 Exchange of measurement information between these organizations is 1027 necessary for location information to be correctly generated. The 1028 ISP LIS needs to acquire location information from the infrastructure 1029 provider. However, the infrastructure provider has no knowledge of 1030 Device identifiers, it can only identify a stream of data that is 1031 sent to the ISP. This is resolved by passing measurement data 1032 relating to the Device to a LIS operated by the infrastructure 1033 provider. 1035 5.6.1. L2TP Measurements 1037 Layer 2 Tunneling Protocol (L2TP) is a common means of linking the 1038 infrastructure provider and the ISP. The infrastructure provider LIS 1039 requires measurement data that identifies a single L2TP tunnel, from 1040 which it can generate location information. Figure 13 shows an 1041 example L2TP measurement. 1043 1045 1046 1047 192.0.2.10 1048 192.0.2.61 1049 528 1050 1051 1052 1054 Figure 13: Example DSL L2TP Measurement 1056 5.6.2. RADIUS Measurements 1058 When authenticating network access, the infrastructure provider might 1059 employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or 1060 Access Node (AN). These messages provide the ISP RADIUS server with 1061 an identifier for the DSLAM or AN, plus the slot and port that the 1062 Device is attached on. These data can be provided as a measurement, 1063 which allows the infrastructure provider LIS to generate location 1064 information. 1066 The format of the AN, slot and port identifiers are not defined in 1067 the RADIUS protocol. Slot and port together identify a circuit on 1068 the AN, analogous to the circuit identifier in [RFC3046]. These 1069 items are provided directly, as they were in the RADIUS message. An 1070 example is shown in Figure 14. 1072 1074 1075 AN-7692 1076 3 1077 06 1078 1079 1081 Figure 14: Example DSL RADIUS Measurement 1083 5.6.3. Ethernet VLAN Tag Measurements 1085 For Ethernet-based DSL access networks, the DSL Access Module (DSLAM) 1086 or Access Node (AN) provide two VLAN tags on packets. A C-TAG is 1087 used to identify the incoming residential circuit, while the S-TAG is 1088 used to identify the DSLAM or AN. The C-TAG and S-TAG together can 1089 be used to identify a single point of network attachment. An example 1090 is shown in Figure 15. 1092 1094 1095 613 1096 1097 1097 1098 1100 Figure 15: Example DSL VLAN Tag Measurement 1102 Alternatively, the C-TAG can be replaced by data on the slot and port 1103 that the Device is attached to. This information might be included 1104 in RADIUS requests that are proxied from the infrastructure provider 1105 to the ISP RADIUS server. 1107 5.6.4. ATM Virtual Circuit Measurements 1109 An ATM virtual circuit can be employed between the ISP and 1110 infrastructure provider. Providing the virtual port ID (VPI) and 1111 virtual circuit ID (VCI) for the virtual circuit gives the 1112 infrastructure provider LIS the ability to identify a single data 1113 stream. A sample measurement is shown in Figure 16. 1115 1117 1118 55 1119 6323 1120 1121 1123 Figure 16: Example DSL ATM Measurement 1125 6. Measurement Schemas 1127 The schema are broken up into their respective functions. There is a 1128 base container schema into which all measurements are placed, plus 1129 definitions for a measurement request (Section 6.1). A PIDF-LO 1130 extension is defined in a separate schema (Section 6.2). There is a 1131 basic types schema, that contains various base type definitions for 1132 things such as the "rmsError" and "samples" attributes IPv4, IPv6 and 1133 MAC addresses (Section 6.3). Then each of the specific measurement 1134 types is defined in its own schema. 1136 6.1. Measurement Container Schema 1138 1139 1147 1148 1150 1151 1152 1154 This schema defines a framework for location measurements. 1155 1156 1158 1160 1161 1162 1163 1164 1165 1167 1168 1169 1170 1171 1172 1173 1174 1175 1177 1179 1180 1181 1182 1183 1185 1187 1188 1189 1190 1192 1193 1194 1195 1196 1198 1199 1200 1201 1202 1203 1205 Measurement Container Schema 1207 6.2. Measurement Source Schema 1209 1210 1217 1218 1220 1221 1222 1224 This schema defines an extension to PIDF-LO that indicates the 1225 type of source that produced the measurement data used in 1226 generating the associated location information. 1227 1228 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1244 Measurement Source PIDF-LO Extension Schema 1246 6.3. Base Type Schema 1248 Note that the pattern rules in the following schema wrap due to 1249 length constraints. None of the patterns contain whitespace. 1251 1252 1259 1260 1262 1263 1264 1266 This schema defines a set of base type elements. 1267 1268 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1310 1311 1312 1314 1315 1316 1317 1318 An IP version 6 address, based on RFC 4291. 1319 1320 1321 1322 1323 1324 1325 1326 1327 1329 1331 1333 1335 1337 1339 1340 1341 1342 1350 1351 1352 1353 1355 1356 1357 1358 1362 1363 1365 1367 1368 1369 1370 1371 1373 1375 Base Type Schema 1377 6.4. LLDP Measurement Schema 1379 1380 1388 1389 1391 1392 1393 1395 This schema defines a set of LLDP location measurements. 1396 1397 1398 1400 1401 1402 1403 1404 1405 1406 1407 1409 1410 1411 1412 1413 1415 1416 1417 1418 1420 1421 1422 1424 1425 1426 1427 1428 1429 1431 1433 LLDP measurement schema 1435 6.5. DHCP Measurement Schema 1437 1438 1446 1447 1449 1450 1451 1453 This schema defines a set of DHCP location measurements. 1454 1455 1457 1459 1460 1461 1462 1463 1464 1465 1466 1468 1470 1472 1474 1475 1476 1477 1478 1480 1481 1482 1483 1485 1486 1487 1489 1491 DHCP measurement schema 1493 6.6. WiFi Measurement Schema 1494 1495 1504 1505 1507 WiFi location measurements 1508 1509 1510 1512 This schema defines a basic set of WiFi location measurements. 1513 1514 1516 1517 1519 1521 1522 1523 1524 1525 1527 1528 1529 1530 1531 1533 1534 1535 1536 1537 1539 1540 1541 1542 1543 1545 1546 1548 1550 1552 1554 1556 1558 1560 1562 1563 1564 1565 1566 1568 1569 1570 1571 1572 1574 1575 1576 1577 1578 1580 1581 1582 1583 1584 1585 1586 1588 1589 1590 1592 1594 WiFi measurement schema 1596 6.7. Cellular Measurement Schema 1598 1599 1606 1607 1609 1610 1611 1613 This schema defines a set of cellular location measurements. 1614 1615 1617 1619 1620 1621 1622 1623 1624 1625 1626 1627 1629 1630 1631 1632 1633 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1654 1655 1656 1657 1658 1659 1661 1662 1664 1665 1666 1667 1669 1670 1671 1672 1673 1675 1676 1677 1678 1679 1681 1682 1683 1684 1685 1686 1688 1689 1690 1691 1692 1693 1694 1695 1696 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1713 1715 Cellular measurement schema 1717 6.8. GNSS Measurement Schema 1719 1720 1728 1729 1731 1732 1733 1735 This schema defines a set of GNSS location measurements 1736 1737 1739 1741 1742 1743 1744 1745 1746 1747 1749 1750 1751 1752 1753 1755 1757 1759 1760 1761 1762 1763 1764 1765 1767 1768 1769 1770 1771 1772 1773 1774 1776 1778 1779 1780 1783 1784 1785 1787 1788 1789 1790 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1805 GNSS measurement Schema 1807 6.9. DSL Measurement Schema 1809 1810 1818 1819 1821 DSL measurement definitions 1822 1823 1824 1826 This schema defines a basic set of DSL location measurements. 1827 1828 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1870 1871 1872 1873 1874 1875 1876 1877 1878 1880 1881 1882 1883 1884 1885 1886 1888 1890 DSL measurement schema 1892 7. Privacy Considerations 1894 Location-related measurement data can be as privacy sensitive as 1895 location information. 1897 Measurement data is effectively equivalent to location information if 1898 the contextual knowledge necessary to generate one from the other is 1899 readily accessible. Even where contextual knowledge is difficult to 1900 acquire, there can be no assurance that an authorized recipient of 1901 the contextual knowledge is also authorized to receive location 1902 information. 1904 In order to protect the privacy of the subject of location-related 1905 measurement data, this implies that measurement data is protected 1906 with the same degree of protection as location information. 1908 7.1. Measurement Data Privacy Model 1910 It is less desirable to distribute measurement data in the same 1911 fashion as location information. Measurement data is less useful to 1912 location recipients than location information. Therefore, a simple 1913 distribution model is desirable. 1915 In this simple model, the Device is the only entity that is able to 1916 distribute measurement data. To use an analogy from the GEOPRIV 1917 architecture, the Device - as the Location Generator (or the 1918 Measurement Data Generator) - is the sole entity that can assume the 1919 roles of Rule Maker and Location Server. 1921 No entity can redistribute measurement data. The Device directs 1922 other entities in how measurement data is used and retained. 1924 7.2. LIS Privacy Requirements 1926 A LIS MUST NOT reveal location-related measurement data or location 1927 information based on measurement data to any other entity unless 1928 directed to do so by the Device. 1930 By adding measurement data to a request for location information, the 1931 Device implicitly grants permission for the LIS to generate the 1932 requested location information using the measurement data. 1933 Permission to use this data for any other purpose is not implied. 1935 As long as measurement data is only used in serving the request that 1936 contains it, rules regarding data retention are not necessary. A LIS 1937 MUST discard location-related measurement data after servicing a 1938 request, unless the Device grants permission to use that information 1939 for other purposes. 1941 7.3. Measurement Data and Location URIs 1943 A LIS MAY use measurement data provided by the Device to serve 1944 requests to location URIs, if the Device permits it. A Device 1945 permits this by including measurement data in a request that 1946 explcitly requests a location URI. By requesting a location URI, the 1947 Device grants permission for the LIS to use the measurement data in 1948 serving requests to that URI. 1950 Note: In HELD, the "any" type is not an explicit request for a 1951 location URI, though a location URI might be provided. 1953 The usefulness of measurement data that is provided in this fashion 1954 is limited. The measurement data is only valid at the time that it 1955 was acquired by the Device. At the time that a request is made to a 1956 location URI, the Device might have moved, rendering the measurement 1957 data incorrect. 1959 A Device is able to explicitly limit the time that a LIS retains 1960 measurement data by adding an expiry time to the measurement data, 1961 see Section 4.1.2. 1963 7.4. Third-Party-Provided Measurement Data 1965 An authorized third-party request for the location of a Device (see 1966 [I-D.ietf-geopriv-held-identity-extensions]) can include location- 1967 related measurement data. This is possible where the third-party is 1968 able to make observations about the Device. 1970 A third-party that provides measurement data MUST be authorized to 1971 provide the specific measurement for the identified device. A third- 1972 party MUST either be trusted by the LIS for the purposes of providing 1973 measurement data of the provided type, or the measurement data MUST 1974 be validated (see Section 8.2.1) before being used. 1976 How a third-party authenticates its identity or gains authorization 1977 to use measurement data is not covered by this document. 1979 8. Security Considerations 1981 Use of location-related measurement data has privacy considerations 1982 that are discussed in Section 7. 1984 8.1. Threat Model 1986 The threat model for location-related measurement data concentrates 1987 on the Device providing falsified, stolen or incorrect measurement 1988 data. 1990 A Device that provides location location-related measurement data 1991 might use data to: 1993 o acquire the location of another Device, without authorization; 1995 o extract information about network topology; or 1997 o coerce the LIS into providing falsified location information based 1998 on the measurement data. 2000 8.1.1. Acquiring Location Information Without Authorization 2002 Requiring authorization for location requests is an important part of 2003 privacy protections of a location protocol. A location configuration 2004 protocol usually operates under a restricted policy that allows a 2005 requester to obtain their own location. HELD identity extensions 2006 [I-D.ietf-geopriv-held-identity-extensions] allows other entities to 2007 be authorized, conditional on a Rule Maker providing sufficient 2008 authorization. 2010 The intent of these protections is to ensure that a location 2011 recipient is authorized to acquire location information. Location- 2012 related measurement data could be used by an attacker to circumvent 2013 such authorization checks if the association between measurement data 2014 and Target Device is not validated by a LIS. 2016 A LIS can be coerced into providing location information for a Device 2017 that a location recipient is not authorized to receive. A request 2018 identifies one Device (implicitly or explicitly), but measurement 2019 data is provided for another Device. If the LIS does not check that 2020 the measurement data is for the identified Device, it could 2021 incorrectly authorize the request. 2023 By using unvalidated measurement data to generate a response, the LIS 2024 provides information about a Device without appropriate 2025 authorization. 2027 The feasibility of this attack depends on the availability of 2028 information that links a Device with measurement data. In some 2029 cases, measurement data that is correlated with a target is readily 2030 available. For instance, LLDP measurements (Section 5.1) are 2031 broadcast to all nodes on the same network segment. An attacker on 2032 that network segment can easily gain measurement data that relates a 2033 Device with measurements. 2035 For some types of measurement data, it's necessary for an attacker to 2036 know the location of the target in order to determine what 2037 measurements to use. This attack is meaningless for types of 2038 measurement data that require that the attacker first know the 2039 location of the target before measurement data can be acquired or 2040 fabricated. GNSS measurements (Section 5.5) share this trait with 2041 many wireless location determination methods. 2043 8.1.2. Extracting Network Topology Data 2045 Allowing requests with measurements might be used to collect 2046 information about a network topology. This is possible if requests 2047 containing measurements are permitted. 2049 Network topology can be considered sensitive information by a network 2050 operator for commercial or security reasons. While it is impossible 2051 to completely prevent a Device from acquiring some knowledge of 2052 network topology if a location service is provided, a network 2053 operator might desire to limit how much of this information is made 2054 available. 2056 Mapping a network topology does not require that an attacker be able 2057 to associate measurement data with a particular Device. If a 2058 requester is able to try a number of measurements, it is possible to 2059 acquire information about network topology. 2061 It is not even necessary that the measurements are valid; random 2062 guesses are sufficient, provided that there is no penalty or cost 2063 associated with attempting to use the measurements. 2065 8.1.3. Lying By Proxy 2067 Location information is a function of its inputs, which includes 2068 measurement data. Thus, falsified measurement data can be used to 2069 alter the location information that is provided by a LIS. 2071 Some types of measurement data are relatively easy to falsify in a 2072 way that the resulting location information to be selected with 2073 little or no error. For instance, GNSS measurements are easy to use 2074 for this purpose because all the contextual information necessary to 2075 calculate a position using measurements is broadcast by the 2076 satellites [HARPER]. 2078 An attacker that falsifies measurement data gains little if they are 2079 the only recipients of the result. The attacker knows that the 2080 location information is bad. The attacker only gains if the 2081 information can somehow be attributed to the LIS by another location 2082 recipient. 2084 A recipient might evaluate the trustworthiness of the location 2085 information based on the credibility of its source. By coercing the 2086 LIS into providing falsified location information, any credibility 2087 that the LIS might have - that the attacker does not - is gained by 2088 the attacker. 2090 A third-party that is reliant on the integrity of the location 2091 information might base an evaluation of the credibility of the 2092 information on the source of the information. If that third party is 2093 able to attribute location information to the LIS, then an attacker 2094 might gain. 2096 Location information that is provided to the Device without any means 2097 to identify the LIS as its source is not subject to this attack. The 2098 Device is identified as the source of the data when it distributes 2099 the location information to location recipients. 2101 An attacker gains if they are able to coerce the LIS into providing 2102 location information based on falsified measurement data and that 2103 information can be attributed to the LIS. 2105 Location information is attributed to the LIS either through the use 2106 of digital signatures or by having the location recipient directly 2107 interact with the LIS. A LIS that digitally signs location 2108 information becomes identifiable as the source of the data. 2109 Similarly, the LIS is identified as a source of data if a location 2110 recipient acquires information directly from a LIS using a location 2111 URI. 2113 8.1.4. Measurement Replay 2115 The value of some measured properties do not change over time for a 2116 single location. This allows for simple replay attacks, where an 2117 attacker acquires measurements that can later be used without being 2118 detected as being invalid. 2120 Measurement data is frequently an observation of an time-invariant 2121 property of the environment at the subject location. For 2122 measurements of this nature, nothing in the measurement itself is 2123 sufficient proof that the Device is present at the resulting 2124 location. Measurement data might have been previously acquired and 2125 reused. 2127 For instance, the identity of a radio transmitter, if broadcast by 2128 that transmitter, can be collected and stored. An attacker that 2129 wishes it known that they exist at a particular location, can claim 2130 to observe this transmitter at any time. Nothing inherent in the 2131 claim reveals it to be false. 2133 For properties of a network, time-invariance is often directly as a 2134 result of the practicalities of operating the network. Limiting the 2135 changes to a network ensures greater consistency of service. A 2136 largely static network also greatly simplifies the data management 2137 tasks involved with providing a location service. 2139 8.2. Mitigation 2141 The following measures can be applied to limit or prevent attacks. 2142 The effectiveness of each depends on the type of measurement data and 2143 how that measurement data is acquired. 2145 Two general approaches are identified for dealing with untrusted 2146 measurement data: 2148 1. Require independent validation of measurement data or the 2149 location information that is produced. 2151 2. Identify the types of sources that provided the measurement data 2152 that location information was derived from. 2154 This section goes into more detail on the different forms of 2155 validation in Section 8.2.1, Section 8.2.2, and Section 8.2.3. The 2156 impact of attributing location information to sources is discussed in 2157 more detail in Section 8.2.4. 2159 8.2.1. Measurement Validation 2161 Detecting that measurement data has been falsified is difficult in 2162 the absence of integrity mechanisms. 2164 Independent confirmation of the veracity of measurement data ensures 2165 that the measurement is accurate and that it applies to the correct 2166 Device. By gathering the same measurement data from a trusted and 2167 independent source, the LIS is able to check that the measurement 2168 data is correct. 2170 Measurement information might contain no inherent indication that it 2171 is falsified. On the contrary, it can be difficult to obtain 2172 information that would provide any degree of assurance that the 2173 measurement device is physically at any particular location. 2174 Measurements that are difficult to verify require other forms of 2175 assurance before they can be used. 2177 8.2.1.1. Effectiveness 2179 Measurement validation MUST be used if measurement data for a 2180 particular Device can be easily acquired by unauthorized location 2181 recipients, as described in Section 8.1.1. This prevents 2182 unauthorized access to location information using measurement data. 2184 Validation of measurement data can be significantly more effective 2185 than independent acquisition of the same. For instance, a Device in 2186 a large Ethernet network could provide a measurement indicating its 2187 point of attachment using LLDP measurements. For a LIS, acquiring 2188 the same measurement data might require a request to all switches in 2189 that network. With the measurement data, validation can target the 2190 identified switch with a specific query. 2192 Validation is effective in identifying falsified measurement data 2193 (Section 8.1.3), including attacks involving replay of measurement 2194 data (Section 8.1.4). Validation also limits the amount of network 2195 topology information (Section 8.1.2) made available to Devices to 2196 that portion of the network topology that they are directly attached. 2198 8.2.1.2. Limitations (Unique Observer) 2200 A Device is often in a unique position to make a measurement. It 2201 alone occupies the point in space-time that the location 2202 determination process seeks to determine. The Device becomes a 2203 unique observer for a particular property. 2205 The ability of the Device to become a unique observer makes the 2206 Device invaluable to the location determination process. As a unique 2207 observer, it also makes the claims of a Device difficult to validate 2208 and easily to spoof. 2210 As long as no other entity is capable of making the same 2211 measurements, there is also no other entity that can independently 2212 check that the measurements are correct and applicable to the Device. 2213 A LIS might be unable to validate all or part of the measurement data 2214 it receives from a unique observer. For instance, a signal strength 2215 measurement of the signal from a radio tower cannot be validated 2216 directly. 2218 Some portion of the measurement data might still be independently 2219 verified, even if all information cannot. In the previous example, 2220 the radio tower might be able to provide verification that the Device 2221 is present if it is able to observe a radio signal sent by the 2222 Device. 2224 If measurement data can only be partially validated, the extent to 2225 which it can be validated determines the effectiveness of validation 2226 against these attacks. 2228 The advantage of having the Device as a unique observer is that it 2229 makes it difficult for an attacker to acquire measurements without 2230 the assistance of the Device. Attempts to use measurements to gain 2231 unauthorized access to measurement data (Section 8.1.1) are largely 2232 ineffectual against a unique observer. 2234 8.2.2. Location Validation 2236 Location information that is derived from location-related 2237 measurement data can also be verified against trusted location 2238 information. Rather than validating inputs to the location 2239 determination process, suspect locations are identified at the output 2240 of the process. 2242 Trusted location information is acquired using sources of measurement 2243 data that are trusted. Untrusted location information is acquired 2244 using measurement data provided from untrusted sources, which might 2245 include the Device. These two locations are compared. If the 2246 untrusted location agrees with the trusted location, the untrusted 2247 location information is used. 2249 Algorithms for the comparison of location information are not 2250 included in this document. However, a simple comparison for 2251 agreement might require that the untrusted location be entirely 2252 contained within the uncertainty region of the trusted location. 2254 There is little point in using a less accurate, less trusted 2255 location. Untrusted location information that has worse accuracy 2256 than trusted information can be immediately discarded. There are 2257 multiple factors that affect accuracy, uncertainty and currency being 2258 the most important. How location information is compared for 2259 accuracy is not defined in this document. 2261 8.2.2.1. Effectiveness 2263 Location validation limits the extent to which falsified - or 2264 erroneous - measurement data can cause an incorrect location to be 2265 reported. 2267 Location validation can be more efficient than validation of inputs, 2268 particularly for a unique observer (Section 8.2.1.2). 2270 Validating location ensures that the Device is at or near the 2271 resulting location. Location validation can be used to limit or 2272 prevent all of the attacks identified in this document. 2274 8.2.2.2. Limitations 2276 The trusted location that is used for validation is always less 2277 accurate than the location that is being checked. The amount by 2278 which the untrusted location is more accurate, is the same amount 2279 that an attacker can exploit. 2281 For example, a trusted location might indicate a five kilometer 2282 radius uncertainty region. An untrusted location that describes a 2283 100 meter uncertainty within the larger region might be accepted as 2284 more accurate. An attacker might still falsify measurement data to 2285 select any location within the larger uncertainty region. While the 2286 100 meter uncertainty that is reported seems more accurate, a 2287 falsified location could be anywhere in the five kilometer region. 2289 Where measurement data might have been falsified, the actual 2290 uncertainty is effectively much higher. Local policy might allow 2291 differing degrees of trust to location information derived from 2292 untrusted measurement data. This might not be a boolean operation 2293 with only two possible outcomes: untrusted location information might 2294 be used entirely or not at all, or it could be combined with trusted 2295 location information with the degree to which each contributes based 2296 on a value set in local policy. 2298 8.2.3. Supporting Observations 2300 Replay attacks using previously acquired measurement data are 2301 particularly hard to detect without independent validation. Rather 2302 than validate the measurement data directly, supplementary data might 2303 be used to validate measurements or the location information derived 2304 from those measurements. 2306 These supporting observations could be used to convey information 2307 that provides additional assurance that the Device was acquired at a 2308 specific time and place. In effect, the Device is requested to 2309 provide proof of its presence at the resulting location. 2311 For instance, a Device that measures attributes of a radio signal 2312 could also be asked to provide a sample of the measured radio signal. 2313 If the LIS is able to observe the same signal, the two observations 2314 could be compared. Providing that the signal cannot be predicted in 2315 advance by the Device, this could be used to support the claim that 2316 the Device is able to receive the signal. Thus, the Device is likely 2317 to be within the range that the signal is transmitted. A LIS could 2318 use this to attribute a higher level of trust in the associated 2319 measurement data or resulting location. 2321 8.2.3.1. Effectiveness 2323 The use of supporting observations is limited by the ability of the 2324 LIS to acquire and validate these observations. The advantage of 2325 selecting observations independent of measurement data is that 2326 observations can be selected based on how readily available the data 2327 is for both LIS and Device. The amount and quality of the data can 2328 be selected based on the degree of assurance that is desired. 2330 Use of supporting observations is similar to both measurement 2331 validation and location validation. All three methods rely on 2332 independent validation of one or more properties. Applicability of 2333 each method is similar. 2335 Use of supporting observations can be used to limit or prevent all of 2336 the attacks identified in this document. 2338 8.2.3.2. Limitations 2340 The effectiveness of the validation method depends on the quality of 2341 the supporting observation: how hard it is to obtain at a different 2342 time or place, how difficult it is to guess and what other costs 2343 might be involved in acquiring this data. 2345 In the example of an observed radio signal, requesting a sample of 2346 the signal only provides an assurance that the Device is able to 2347 receive the signal transmitted by the measured radio transmitter. 2348 This only provides some assurance that the Device is within range of 2349 the transmitter. 2351 As with location validation, a Device might still be able to provide 2352 falsified measurements that could alter the value of the location 2353 information as long as the result is within this region. 2355 Requesting additional supporting observations can reduce the size of 2356 the region over which location information can be altered by an 2357 attacker, or increase trust in the result, but each additional has a 2358 cost. Supporting observations contribute little or nothing toward 2359 the primary goal of determining the location of the Device. Any 2360 costs in acquiring supporting observations are balanced against the 2361 degree of integrity desired of the resulting location information. 2363 8.2.4. Attribution 2365 Lying by proxy (Section 8.1.3) relies on the location recipient being 2366 able to attribute location information to a LIS. The effectiveness 2367 of this attack is negated if location information is explicitly 2368 attributed to a particular source. 2370 This requires an extension to the location object that explicitly 2371 identifies the source (or sources) of each item of location 2372 information. 2374 Rather than relying on a process that seeks to ensure that location 2375 information is accurate, this approach instead provides a location 2376 recipient with the information necessary to reach their own 2377 conclusion about the trustworthiness of the location information. 2379 Including an authenticated identity for all sources of measurement 2380 data is presents a number of technical and operational challenges. 2381 It is possible that the LIS has a transient relationship with a 2382 Device. A Device is not expected to share authentication information 2383 with a LIS. There is no assurance that Device identification is 2384 usable by a potential location recipient. Privacy concerns might 2385 also prevent the sharing identification information, even if it were 2386 available and usable. 2388 Identifying the type of measurement source allows a location 2389 recipient to make a decision about the trustworthiness of location 2390 information without depending on having authenticated identity 2391 information for each source. An element for this purpose is defined 2392 in Section 4.4. 2394 When including location information that is based on measurement data 2395 from sources that might be untrusted, a LIS SHOULD include 2396 alternative location information that is derived from trusted sources 2397 of measurement data. Each item of location information can then be 2398 labelled with the source of that data. 2400 A location recipient that is able to identify a specific source of 2401 measurement data (whether it be LIS or Device) can use this 2402 information to attribute location information to either or both 2403 entity. The location recipient is then better able to make decisions 2404 about trustworthiness based on the source of the data. 2406 A location recipient that does not understand the "source" element is 2407 unable to make this distinction. When constructing a PIDF-LO 2408 document, trusted location information MUST be placed in the PIDF-LO 2409 so that it is given higher priority to any untrusted location 2410 information according to Rule #8 of [RFC5491]. 2412 8.2.5. Stateful Correlation of Location Requests 2414 Stateful examination of requests can be used to prevent a Device from 2415 attempting to map network topology using requests for location 2416 information (Section 8.1.2). 2418 Simply limiting the rate of requests from a single Device reduces the 2419 amount of data that a Device can acquire about network topology. 2421 9. IANA Considerations 2423 This section creates a registry for GNSS types (Section 5.5) and 2424 registers the namespaces and schema defined in Section 6. 2426 9.1. IANA Registry for GNSS Types 2428 This document establishes a new IANA registry for Global Navigation 2429 Satellite System (GNSS) types. The registry includes tokens for the 2430 GNSS type and for each of the signals within that type. Referring to 2431 [RFC5226], this registry operates under "Specification Required" 2432 rules. The IESG will appoint an Expert Reviewer who will advise IANA 2433 promptly on each request for a new or updated GNSS type. 2435 Each entry in the registry requires the following information: 2437 GNSS name: the name and a brief description of the GNSS 2439 Brief description: the name and a brief description of the GNSS 2441 GNSS token: a token that can be used to identify the GNSS 2443 Signals: a set of tokens that represent each of the signals that the 2444 system provides 2446 Documentation reference: a reference to one or more stable, public 2447 specifications that outline usage of the GNSS, including (but not 2448 limited to) signal specifications and time systems 2450 The registry initially includes two registrations: 2452 GNSS name: Global Positioning System (GPS) 2454 Brief description: a system of satellites that use spread-spectrum 2455 transmission, operated by the US military for commercial and 2456 military applications 2458 GNSS token: gps 2460 Signals: L1, L2, L1C, L2C, L5 2462 Documentation reference: Navstar GPS Space Segment/Navigation User 2463 Interface [GPS.ICD] 2465 GNSS name: Galileo 2467 Brief description: a system of satellites that operate in the same 2468 spectrum as GPS, operated by the European Union for commercial 2469 applications 2471 GNSS Token: galileo 2473 Signals: L1, E5A, E5B, E5A+B, E6 2475 Documentation Reference: Galileo Open Service Signal In Space 2476 Interface Control Document (SIS ICD) [Galileo.ICD] 2478 9.2. URN Sub-Namespace Registration for 2479 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc 2481 This section registers a new XML namespace, 2482 "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines 2483 in [RFC3688]. 2485 URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc 2487 Registrant Contact: IETF, GEOPRIV working group, 2488 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2490 XML: 2492 BEGIN 2493 2494 2496 2497 2498 Measurement Source for PIDF-LO 2499 2500 2501

Namespace for Location Measurement Source

2502

urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc

2503 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2504 with the RFC number for this specification.]] 2505

See RFCXXXX.

2506 2507 2508 END 2510 9.3. URN Sub-Namespace Registration for 2511 urn:ietf:params:xml:ns:geopriv:lm 2513 This section registers a new XML namespace, 2514 "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in 2515 [RFC3688]. 2517 URI: urn:ietf:params:xml:ns:geopriv:lm 2519 Registrant Contact: IETF, GEOPRIV working group, 2520 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2522 XML: 2524 BEGIN 2525 2526 2528 2529 2530 Measurement Container 2531 2532 2533

Namespace for Location Measurement Container

2534

urn:ietf:params:xml:ns:geopriv:lm

2535 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2536 with the RFC number for this specification.]] 2537

See RFCXXXX.

2538 2539 2541 END 2543 9.4. URN Sub-Namespace Registration for 2544 urn:ietf:params:xml:ns:geopriv:lm:basetypes 2546 This section registers a new XML namespace, 2547 "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines 2548 in [RFC3688]. 2550 URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes 2552 Registrant Contact: IETF, GEOPRIV working group, 2553 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2555 XML: 2557 BEGIN 2558 2559 2561 2562 2563 Base Device Types 2564 2565 2566

Namespace for Base Types

2567

urn:ietf:params:xml:ns:geopriv:lm:basetypes

2568 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2569 with the RFC number for this specification.]] 2570

See RFCXXXX.

2571 2572 2573 END 2575 9.5. URN Sub-Namespace Registration for 2576 urn:ietf:params:xml:ns:geopriv:lm:lldp 2578 This section registers a new XML namespace, 2579 "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in 2580 [RFC3688]. 2582 URI: urn:ietf:params:xml:ns:geopriv:lm:lldp 2584 Registrant Contact: IETF, GEOPRIV working group, 2585 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2587 XML: 2589 BEGIN 2590 2591 2593 2594 2595 LLDP Measurement Set 2596 2597 2598

Namespace for LLDP Measurement Set

2599

urn:ietf:params:xml:ns:geopriv:lm:lldp

2600 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2601 with the RFC number for this specification.]] 2602

See RFCXXXX.

2603 2604 2605 END 2607 9.6. URN Sub-Namespace Registration for 2608 urn:ietf:params:xml:ns:geopriv:lm:dhcp 2610 This section registers a new XML namespace, 2611 "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in 2612 [RFC3688]. 2614 URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp 2616 Registrant Contact: IETF, GEOPRIV working group, 2617 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2619 XML: 2621 BEGIN 2622 2623 2625 2626 2627 DHCP Measurement Set 2628 2629 2630

Namespace for DHCP Measurement Set

2631

urn:ietf:params:xml:ns:geopriv:lm:dhcp

2632 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2633 with the RFC number for this specification.]] 2634

See RFCXXXX.

2635 2636 2638 END 2640 9.7. URN Sub-Namespace Registration for 2641 urn:ietf:params:xml:ns:geopriv:lm:wifi 2643 This section registers a new XML namespace, 2644 "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in 2645 [RFC3688]. 2647 URI: urn:ietf:params:xml:ns:geopriv:lm:wifi 2649 Registrant Contact: IETF, GEOPRIV working group, 2650 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2652 XML: 2654 BEGIN 2655 2656 2658 2659 2660 WiFi Measurement Set 2661 2662 2663

Namespace for WiFi Measurement Set

2664

urn:ietf:params:xml:ns:geopriv:lm:wifi

2665 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2666 with the RFC number for this specification.]] 2667

See RFCXXXX.

2668 2669 2670 END 2672 9.8. URN Sub-Namespace Registration for 2673 urn:ietf:params:xml:ns:geopriv:lm:cell 2675 This section registers a new XML namespace, 2676 "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in 2677 [RFC3688]. 2679 URI: urn:ietf:params:xml:ns:geopriv:lm:cell 2681 Registrant Contact: IETF, GEOPRIV working group, 2682 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2684 XML: 2686 BEGIN 2687 2688 2690 2691 2692 Cellular Measurement Set 2693 2694 2695

Namespace for Cellular Measurement Set

2696

urn:ietf:params:xml:ns:geopriv:lm:cell

2697 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2698 with the RFC number for this specification.]] 2699

See RFCXXXX.

2700 2701 2702 END 2704 9.9. URN Sub-Namespace Registration for 2705 urn:ietf:params:xml:ns:geopriv:lm:gnss 2707 This section registers a new XML namespace, 2708 "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in 2709 [RFC3688]. 2711 URI: urn:ietf:params:xml:ns:geopriv:lm:gnss 2713 Registrant Contact: IETF, GEOPRIV working group, 2714 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2716 XML: 2718 BEGIN 2719 2720 2722 2723 2724 GNSS Measurement Set 2725 2726 2727

Namespace for GNSS Measurement Set

2728

urn:ietf:params:xml:ns:geopriv:lm:gnss

2729 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2730 with the RFC number for this specification.]] 2731

See RFCXXXX.

2732 2733 2735 END 2737 9.10. URN Sub-Namespace Registration for 2738 urn:ietf:params:xml:ns:geopriv:lm:dsl 2740 This section registers a new XML namespace, 2741 "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in 2742 [RFC3688]. 2744 URI: urn:ietf:params:xml:ns:geopriv:lm:dsl 2746 Registrant Contact: IETF, GEOPRIV working group, 2747 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2749 XML: 2751 BEGIN 2752 2753 2755 2756 2757 DSL Measurement Set 2758 2759 2760

Namespace for DSL Measurement Set

2761

urn:ietf:params:xml:ns:geopriv:lm:dsl

2762 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2763 with the RFC number for this specification.]] 2764

See RFCXXXX.

2765 2766 2767 END 2769 9.11. XML Schema Registration for Measurement Source Schema 2771 This section registers an XML schema as per the guidelines in 2772 [RFC3688]. 2774 URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc 2776 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2777 Martin Thomson (martin.thomson@andrew.com). 2779 Schema: The XML for this schema can be found in Section 6.2 of this 2780 document. 2782 9.12. XML Schema Registration for Measurement Container Schema 2784 This section registers an XML schema as per the guidelines in 2785 [RFC3688]. 2787 URI: urn:ietf:params:xml:schema:lm 2789 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2790 Martin Thomson (martin.thomson@andrew.com). 2792 Schema: The XML for this schema can be found in Section 6.1 of this 2793 document. 2795 9.13. XML Schema Registration for Base Types Schema 2797 This section registers an XML schema as per the guidelines in 2798 [RFC3688]. 2800 URI: urn:ietf:params:xml:schema:lm:basetypes 2802 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2803 Martin Thomson (martin.thomson@andrew.com). 2805 Schema: The XML for this schema can be found in Section 6.3 of this 2806 document. 2808 9.14. XML Schema Registration for LLDP Schema 2810 This section registers an XML schema as per the guidelines in 2811 [RFC3688]. 2813 URI: urn:ietf:params:xml:schema:lm:lldp 2815 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2816 Martin Thomson (martin.thomson@andrew.com). 2818 Schema: The XML for this schema can be found in Section 6.4 of this 2819 document. 2821 9.15. XML Schema Registration for DHCP Schema 2823 This section registers an XML schema as per the guidelines in 2824 [RFC3688]. 2826 URI: urn:ietf:params:xml:schema:lm:dhcp 2827 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2828 Martin Thomson (martin.thomson@andrew.com). 2830 Schema: The XML for this schema can be found in Section 6.5 of this 2831 document. 2833 9.16. XML Schema Registration for WiFi Schema 2835 This section registers an XML schema as per the guidelines in 2836 [RFC3688]. 2838 URI: urn:ietf:params:xml:schema:lm:wifi 2840 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2841 Martin Thomson (martin.thomson@andrew.com). 2843 Schema: The XML for this schema can be found in Section 6.6 of this 2844 document. 2846 9.17. XML Schema Registration for Cellular Schema 2848 This section registers an XML schema as per the guidelines in 2849 [RFC3688]. 2851 URI: urn:ietf:params:xml:schema:lm:cellular 2853 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2854 Martin Thomson (martin.thomson@andrew.com). 2856 Schema: The XML for this schema can be found in Section 6.7 of this 2857 document. 2859 9.18. XML Schema Registration for GNSS Schema 2861 This section registers an XML schema as per the guidelines in 2862 [RFC3688]. 2864 URI: urn:ietf:params:xml:schema:lm:gnss 2866 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2867 Martin Thomson (martin.thomson@andrew.com). 2869 Schema: The XML for this schema can be found in Section 6.8 of this 2870 document. 2872 9.19. XML Schema Registration for DSL Schema 2874 This section registers an XML schema as per the guidelines in 2875 [RFC3688]. 2877 URI: urn:ietf:params:xml:schema:lm:dsl 2879 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2880 Martin Thomson (martin.thomson@andrew.com). 2882 Schema: The XML for this schema can be found in Section 6.9 of this 2883 document. 2885 10. Acknowledgements 2887 Thanks go to Simon Cox for his comments relating to terminology that 2888 have helped ensure that this document is aligns with ongoing work in 2889 the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his 2890 review and comments on the GNSS sections of this document. Thanks to 2891 Noor-E-Gagan Singh and Gabor Bajko for independent suggestions for 2892 improving the parameters associated with 802.11 measurements. Thanks 2893 to Cullen Jennings for feedback and suggestions. 2895 11. References 2897 11.1. Normative References 2899 [DSL.TR025] 2900 Wang, R., "Core Network Architecture Recommendations for 2901 Access to Legacy Data Networks over ADSL", September 1999. 2903 [DSL.TR101] 2904 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL 2905 Aggregation", April 2006. 2907 [GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface", 2908 ICD GPS-200, Apr 2000. 2910 [Galileo.ICD] 2911 GJU, "Galileo Open Service Signal In Space Interface 2912 Control Document (SIS ICD)", May 2006. 2914 [I-D.ietf-geopriv-http-location-delivery] 2915 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 2916 "HTTP Enabled Location Delivery (HELD)", 2917 draft-ietf-geopriv-http-location-delivery-16 (work in 2918 progress), August 2009. 2920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2921 Requirement Levels", BCP 14, RFC 2119, March 1997. 2923 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 2924 Format", RFC 4119, December 2005. 2926 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2927 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2928 May 2008. 2930 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 2931 Presence Information Data Format Location Object (PIDF-LO) 2932 Usage Clarification, Considerations, and Recommendations", 2933 RFC 5491, March 2009. 2935 11.2. Informative References 2937 [HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side 2938 spoofing and detection for Assisted-GPS", Proceedings of 2939 International Global Navigation Satellite Systems Society 2940 (IGNSS) Symposium 2009 16, December 2009, 2941 . 2943 [I-D.ietf-geopriv-held-identity-extensions] 2944 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 2945 Barnes, "Use of Device Identity in HTTP-Enabled Location 2946 Delivery (HELD)", 2947 draft-ietf-geopriv-held-identity-extensions-03 (work in 2948 progress), February 2010. 2950 [I-D.thomson-geopriv-uncertainty] 2951 Thomson, M. and J. Winterbottom, "Representation of 2952 Uncertainty and Confidence in PIDF-LO", 2953 draft-thomson-geopriv-uncertainty-04 (work in progress), 2954 November 2009. 2956 [IANA.enterprise] 2957 IANA, "Private Enterprise Numbers", 2958 . 2960 [IEEE.8021AB] 2961 IEEE, "IEEE Standard for Local and Metropolitan area 2962 networks, Station and Media Access Control Connectivity 2963 Discovery", 802.1AB, June 2005. 2965 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2966 "Remote Authentication Dial In User Service (RADIUS)", 2967 RFC 2865, June 2000. 2969 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 2970 RFC 3046, January 2001. 2972 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2973 January 2004. 2975 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 2976 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 2978 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID 2979 Suboption for the Dynamic Host Configuration Protocol 2980 (DHCP) Relay Agent Option", RFC 3993, March 2005. 2982 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2983 Architecture", RFC 4291, February 2006. 2985 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 2986 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, 2987 June 2006. 2989 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 2990 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 2991 August 2006. 2993 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 2994 Mechanism", RFC 5808, May 2010. 2996 Authors' Addresses 2998 Martin Thomson 2999 Andrew 3000 Andrew Building (39) 3001 University of Wollongong 3002 Northfields Avenue 3003 Wollongong, NSW 2522 3004 AU 3006 Phone: +61 2 4221 2915 3007 Email: martin.thomson@andrew.com 3008 URI: http://www.andrew.com/ 3009 James Winterbottom 3010 Andrew 3011 Andrew Building (39) 3012 University of Wollongong 3013 Northfields Avenue 3014 NSW 2522 3015 AU 3017 Phone: +61 2 4221 2938 3018 Email: james.winterbottom@andrew.com 3019 URI: http://www.andrew.com/