idnits 2.17.1 draft-ietf-geopriv-held-measurements-00.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, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (July 5, 2010) is 5043 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 1399, but not defined == Missing Reference: '0-4' is mentioned on line 1399, but not defined == Missing Reference: '0-9' is mentioned on line 1399, but not defined == Missing Reference: '0-1' is mentioned on line 1399, but not defined == Unused Reference: 'I-D.thomson-geopriv-uncertainty' is defined on line 3051, but no explicit reference was found in the text == Unused Reference: 'RFC5808' is defined on line 3099, 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-04 == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-05 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 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: January 6, 2011 July 5, 2010 7 Using Device-provided Location-Related Measurements in Location 8 Configuration Protocols 9 draft-ietf-geopriv-held-measurements-00 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 January 6, 2011. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2. Conventions used in this document . . . . . . . . . . . . . . 6 72 3. Location-Related Measurements in LCPs . . . . . . . . . . . . 7 73 4. Location-Related Measurement Data Types . . . . . . . . . . . 8 74 4.1. Measurement Container . . . . . . . . . . . . . . . . . . 9 75 4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 9 76 4.1.2. Expiry Time on Location-Related Measurement Data . . . 9 77 4.2. RMS Error and Number of Samples . . . . . . . . . . . . . 10 78 4.2.1. Time RMS Error . . . . . . . . . . . . . . . . . . . . 10 79 4.3. Measurement Request . . . . . . . . . . . . . . . . . . . 11 80 4.4. Identifying Location Provenance . . . . . . . . . . . . . 12 81 5. Location-Related Measurement Data Types . . . . . . . . . . . 14 82 5.1. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 14 83 5.2. DHCP Relay Agent Information Measurements . . . . . . . . 15 84 5.3. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 15 85 5.3.1. Wifi Measurement Requests . . . . . . . . . . . . . . 18 86 5.4. Cellular Measurements . . . . . . . . . . . . . . . . . . 18 87 5.4.1. Cellular Measurement Requests . . . . . . . . . . . . 21 88 5.5. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 21 89 5.5.1. GNSS System and Signal . . . . . . . . . . . . . . . . 23 90 5.5.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 5.5.3. Per-Satellite Measurement Data . . . . . . . . . . . . 24 92 5.5.4. GNSS Measurement Requests . . . . . . . . . . . . . . 25 93 5.6. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 25 94 5.6.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 26 95 5.6.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 26 96 5.6.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 27 97 5.6.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 27 98 6. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 27 99 6.1. Measurement Container Schema . . . . . . . . . . . . . . . 28 100 6.2. Measurement Source Schema . . . . . . . . . . . . . . . . 30 101 6.3. Base Type Schema . . . . . . . . . . . . . . . . . . . . . 30 102 6.4. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 33 103 6.5. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 34 104 6.6. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 36 105 6.7. Cellular Measurement Schema . . . . . . . . . . . . . . . 39 106 6.8. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 41 107 6.9. DSL Measurement Schema . . . . . . . . . . . . . . . . . . 43 108 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 45 109 7.1. Measurement Data Privacy Model . . . . . . . . . . . . . . 45 110 7.2. LIS Privacy Requirements . . . . . . . . . . . . . . . . . 46 111 7.3. Measurement Data and Location URIs . . . . . . . . . . . . 46 112 7.4. Third-Party-Provided Measurement Data . . . . . . . . . . 46 113 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 114 8.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 47 115 8.1.1. Acquiring Location Information Without 116 Authorization . . . . . . . . . . . . . . . . . . . . 47 117 8.1.2. Extracting Network Topology Data . . . . . . . . . . . 48 118 8.1.3. Lying By Proxy . . . . . . . . . . . . . . . . . . . . 49 119 8.1.4. Measurement Replay . . . . . . . . . . . . . . . . . . 50 120 8.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 50 121 8.2.1. Measurement Validation . . . . . . . . . . . . . . . . 51 122 8.2.1.1. Effectiveness . . . . . . . . . . . . . . . . . . 51 123 8.2.1.2. Limitations (Unique Observer) . . . . . . . . . . 51 124 8.2.2. Location Validation . . . . . . . . . . . . . . . . . 52 125 8.2.2.1. Effectiveness . . . . . . . . . . . . . . . . . . 53 126 8.2.2.2. Limitations . . . . . . . . . . . . . . . . . . . 53 127 8.2.3. Supporting Observations . . . . . . . . . . . . . . . 53 128 8.2.3.1. Effectiveness . . . . . . . . . . . . . . . . . . 54 129 8.2.3.2. Limitations . . . . . . . . . . . . . . . . . . . 54 130 8.2.4. Attribution . . . . . . . . . . . . . . . . . . . . . 55 131 8.2.5. Stateful Correlation of Location Requests . . . . . . 56 132 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 133 9.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 56 134 9.2. URN Sub-Namespace Registration for 135 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc . . . . . . . 57 136 9.3. URN Sub-Namespace Registration for 137 urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 58 138 9.4. URN Sub-Namespace Registration for 139 urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 59 140 9.5. URN Sub-Namespace Registration for 141 urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . . 59 142 9.6. URN Sub-Namespace Registration for 143 urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . . 60 144 9.7. URN Sub-Namespace Registration for 145 urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . . 61 146 9.8. URN Sub-Namespace Registration for 147 urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . . 61 148 9.9. URN Sub-Namespace Registration for 149 urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . . 62 150 9.10. URN Sub-Namespace Registration for 151 urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 63 152 9.11. XML Schema Registration for Measurement Source Schema . . 63 153 9.12. XML Schema Registration for Measurement Container 154 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 64 155 9.13. XML Schema Registration for Base Types Schema . . . . . . 64 156 9.14. XML Schema Registration for LLDP Schema . . . . . . . . . 64 157 9.15. XML Schema Registration for DHCP Schema . . . . . . . . . 64 158 9.16. XML Schema Registration for WiFi Schema . . . . . . . . . 65 159 9.17. XML Schema Registration for Cellular Schema . . . . . . . 65 160 9.18. XML Schema Registration for GNSS Schema . . . . . . . . . 65 161 9.19. XML Schema Registration for DSL Schema . . . . . . . . . . 66 162 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66 163 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 164 11.1. Normative References . . . . . . . . . . . . . . . . . . . 66 165 11.2. Informative References . . . . . . . . . . . . . . . . . . 67 166 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 168 1. Introduction 170 A location configuration protocol (LCP) provides a means for a Device 171 to request information about its physical location from an access 172 network. A location information server (LIS) is the server that 173 provides location information; information that is available due to 174 the knowledge about the network and physical environment that is 175 available to the LIS. 177 As a part of the access network, the LIS is able to acquire 178 measurement results from network Devices within the network that are 179 related to Device location. The LIS also has access to information 180 about the network topology that can be used to turn measurement data 181 into location information. However, this information can be enhanced 182 with information acquired from the Device itself. 184 A Device is able to make observations about its network attachment, 185 or its physical environment. The location-related measurement data 186 might be unavailable to the LIS; alternatively, the LIS might be able 187 to acquire the data, but at a higher cost in time or otherwise. 188 Providing measurement data gives the LIS more options in determining 189 location, which could improve the quality of the service provided by 190 the LIS. Improvements in accuracy are one potential gain, but 191 improved response times and lower error rates are also possible. 193 This document describes a means for a Device to report location- 194 related measurement data to the LIS. Examples based on the HELD 195 [I-D.ietf-geopriv-http-location-delivery] location configuration 196 protocol are provided. 198 2. Conventions used in this document 200 The terms LIS and Device are used in this document in a manner 201 consistent with the usage in 202 [I-D.ietf-geopriv-http-location-delivery]. 204 This document also uses the following definitions: 206 Location Measurement: An observation about the physical properties 207 of a particular Device's network access. The result of a location 208 measurement--"location-related measurement data", or simply 209 "measurement data" given sufficient context--can be used to 210 determine the location of a Device. Location-related measurement 211 data does not identify a Device; measurement data can change with 212 time if the location of the Device also changes. 214 Location-related measurement data does not necessarily contain 215 location information directly, but it can be used in combination 216 with contextual knowledge of the network, or algorithms to derive 217 location information. Examples of location-related measurement 218 data are: radio signal strength or timing measurements, Ethernet 219 switch and port identifiers. 221 Location-related measurement data can be considered sighting 222 information, based on the definition in [RFC3693]. 224 Location Estimate: The result of location determination, a location 225 estimate is an approximation of where the Device is located. 226 Location estimates are subject to uncertainty, which arise from 227 errors in measurement results. 229 GNSS: Global Navigation Satellite System. A satellite-based system 230 that provides positioning and time information. For example, the 231 US Global Positioning System (GPS) or the European Galileo system. 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in [RFC2119]. 237 3. Location-Related Measurements in LCPs 239 This document defines a standard container for the conveyance of 240 location-related measurement parameters in location configuration 241 protocols. This is an XML container that identifies parameters by 242 type and allows the Device to provide the results of any measurement 243 it is able to perform. A set of measurement schemas are also defined 244 that can be carried in the generic container. 246 The simplest example of measurement data conveyance is illustrated by 247 the example message in Figure 1. This shows a HELD location request 248 message with an Ethernet switch and port measurement taken using LLDP 249 [IEEE.8021AB]. 251 252 civic 253 255 256 0a01003c 257 c2 258 259 260 261 Figure 1: HELD Location Request with Measurement Data 263 Measurement data that the LIS does not support or understand can be 264 ignored. The measurements defined in this document follow this rule; 265 extensions that could result in backward incompatibility MUST be 266 added as new measurement definitions rather than extensions to 267 existing types. 269 Multiple sets of measurement data, either of the same type or from 270 different sources can be included in the "measurements" element. See 271 Section 4.1.1 for details on repetition of this element. 273 Use of location-related measurement data is at the discretion of the 274 LIS, but the "method" parameter in the PIDF-LO SHOULD be adjusted to 275 reflect the method used. 277 Location-related measurement data need not be provided exclusively by 278 Devices. A third party location requester can request location 279 information using measurement data, if they are able and authorized. 280 There are privacy considerations relating to the use of measurements 281 by third parties, which are discussed in Section 7.4. 283 Location-related measurement data and its use presents a number of 284 security challenges. These are described in more detail in 285 Section 8. 287 4. Location-Related Measurement Data Types 289 A common container is defined for the expression of location 290 measurement data, as well as a simple means of identifying specific 291 types of measurement data for the purposes of requesting them. 293 The following example shows a measurement container with measurement 294 time and expiration time included. A WiFi measurement is enclosed. 296 299 300 301 wlan-home 302 00-12-F0-A0-80-EF 303 304 305 307 Figure 2: Measurement Example 309 4.1. Measurement Container 311 The "measurement" element is used to encapsulate measurement data 312 that is collected at a certain point in time. It contains time-based 313 attributes that are common to all forms of measurement data, and 314 permits the inclusion of arbitrary measurement data. 316 This container can be added to any request for location information, 317 such as a HELD location request 318 [I-D.ietf-geopriv-http-location-delivery]. 320 4.1.1. Time of Measurement 322 The "time" attribute records the time that the measurement or 323 observation was made. This time can be different to the time that 324 the measurement information was reported. Time information can be 325 used to populate a timestamp on the location result, or to determine 326 if the measurement information is used. 328 The "time" attribute is optional to avoid forcing an arbitrary choice 329 of timestamp for relatively static types of measurement (for 330 instance, the DSL measurements in Section 5.6) and for legacy Devices 331 that don't record time information (such as the Home Location 332 Register/Home Subscriber Server for cellular). However, time SHOULD 333 be provided whenever possible. 335 The "time" attribute is attached to the root "measurement" element. 336 If it is necessary to provide multiple sets of measurement data with 337 different times, multiple "measurement" elements SHOULD be provided. 339 4.1.2. Expiry Time on Location-Related Measurement Data 341 A Device is able to indicate an expiry time in the location 342 measurement using the "expires" attribute. Nominally, this attribute 343 indicates how long information is expected to be valid for, but it 344 can also indicate a time limit on the retention and use of the 345 measurement data. A Device can use this attribute to prevent the LIS 346 from retaining measurement data or limit the time that a LIS retains 347 this information. 349 Note: Movement of a Device might result in the measurement data 350 being invalidated before the expiry time. 352 The LIS MUST NOT keep location-related measurement data beyond the 353 time indicated in the "expires" attribute. 355 4.2. RMS Error and Number of Samples 357 Often a measurement is taken more than once over a period of time. 358 Reporting the average of a number of measurement results mitigates 359 the effects of random errors that occur in the measurement process. 360 Typically, a mean value is reported at the end of the measurement 361 interval, but additional information about the distribution of the 362 results can be useful in determining location uncertainty. 364 Two optional attributes are provided for certain measurement values: 366 rmsError: The root-mean-squared (RMS) error of the set of 367 measurement values used in calculating the result. RMS error is 368 expressed in the same units as the measurement, unless otherwise 369 stated. If an accurate value for RMS error is not known, this 370 value can be used to indicate an upper bound for the RMS error. 372 samples: The number of samples that were taken in determining the 373 measurement value. If omitted, this value can be assumed to be a 374 very large value, so that the RMS error is an indication of the 375 standard deviation of the sample set. 377 For some measurement techniques, measurement error is largely 378 dependent on the measurement technique employed. In these cases, 379 measurement error is largely a product of the measurement technique 380 and not the specific circumstances, so RMS error does not need to be 381 actively measured. A fixed value MAY be provided for RMS error where 382 appropriate. 384 The "rmsError" and "samples" elements are added as attributes of 385 specific measurement data types. 387 4.2.1. Time RMS Error 389 Measurement of time can be significant in certain circumstances. The 390 GNSS measurements included in this document are one such case where a 391 small error in time can result in a large error in location. Factors 392 such as clock drift and errors in time sychronization can result in 393 small, but significant, time errors. Including an indication of the 394 quality of the time can be helpful. 396 An optional "timeError" attribute can be added to the "measurement" 397 element to indicate the RMS error in time. "timeError" indicates an 398 upper bound on the time RMS error in seconds. 400 The "timeError" attribute does not apply where multiple samples of a 401 measurement is taken over time. If multiple samples are taken, each 402 SHOULD be included in a different "measurement" element. 404 4.3. Measurement Request 406 A measurement request is used by a protocol peer to describe a set of 407 measurement data that it desires. A "measurementRequest" element is 408 defined that can be included in a protocol exchange. 410 For instance, a LIS can use a measurement request in HELD responses. 411 If the LIS is unable to provide location information, but it believes 412 that a particular measurement type would enable it to provide a 413 location, it can include a measurement request in an error response. 415 The "measurement" element of the measurement request identifies the 416 type of measurement that is requested. The "type" attribute of this 417 element indicates the type of measurement, as identified by an XML 418 qualified name. An optional "samples" attribute indicates how many 419 samples of the identified measurement are requested. 421 The "measurement" element can be repeated to request multiple (or 422 alternative) measurement types. 424 Additional XML content might be defined for a particular measurement 425 type that is used to further refine a request. These elements either 426 constrain what is requested or specify optional components of the 427 measurement data that are needed. These are defined along with the 428 specific measurement type. 430 In the HELD protocol, the inclusion of a measurement request in a 431 error response with a code of "locationUnknown" indicates that the 432 LIS believes that providing the indicated measurements would increase 433 the likelihood of a subsequent request being successful. 435 The following example shows a HELD error response that indicates that 436 WiFi measurement data would be useful if a later request were made. 437 Additional elements indicate that received signal strength for an 438 802.11n access point is requested. 440 442 Insufficient measurement data 443 446 447 n 448 wifi:rcpi 449 450 451 452 Figure 3 454 A measurement request that is included in other HELD messages has 455 undefined semantics and can be safely ignored. Other specifications 456 might define semantics for measurement requests under other 457 conditions. 459 4.4. Identifying Location Provenance 461 An extension is made to the PIDF-LO [RFC4119] that allows a location 462 recipient to identify the source (or sources) of location information 463 and the measurement data that was used to determine that location 464 information. 466 The "source" element is added to the "geopriv" element of the 467 PIDF-LO. This element does not identify specific entities. Instead, 468 it identifies the type of source. 470 The following types of measurement source are identified: 472 lis: Location information is based on measurement data that the LIS 473 or sources that it trusts have acquired. This label might be used 474 if measurement data provided by the Device has been completely 475 validated by the LIS. 477 device: Location information is based on measurement data that the 478 Device has provided to the LIS. 480 other: Location information is based on measurement data that a 481 third party has provided. This might be an authorized third party 482 that uses identity parameters 483 [I-D.ietf-geopriv-held-identity-extensions] or any other entity. 485 No assertion is made about the veracity of the measurement data from 486 sources other than the LIS. A combination of tags MAY be included to 487 indicate that measurement data from both sources was used. 489 For example, the first tuple of the following PIDF-LO indicates that 490 measurement data from a LIS and a device was combined to produce the 491 result, the second tuple was produced by the LIS alone. 493 499 500 501 502 503 504 7.34324 134.47162 505 506 850.24 507 508 509 510 511 OTDOA 512 lis device 513 514 515 516 517 518 519 520 521 7.34379 134.46484 522 523 9000 524 525 526 527 528 Cell 529 lis 530 531 532 533 535 5. Location-Related Measurement Data Types 537 This document defines location-related measurement data types for a 538 range of common network types. 540 All included measurement data definitions allow for arbitrary 541 extension in the corresponding schema. As new parameters that are 542 applicable to location determination are added, these can be added as 543 new XML elements in a unique namespace. Though many of the 544 underlying protocols support extension, creation of specific XML- 545 based extensions to the measurement format is favored over 546 accomodating protocol-specific extensions in generic containers. 548 5.1. LLDP Measurements 550 Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages are sent 551 between adjacent nodes in an IEEE 802 network (e.g. wired Ethernet, 552 WiFi, 802.16). These messages all contain identification information 553 for the sending node, which can be used to determine location 554 information. A Device that receives LLDP messages can report this 555 information as a location-related measurement to the LIS, which is 556 then able to use the measurement data in determining the location of 557 the Device. 559 Note: The LLDP extensions defined in LLDP Media Endpoint Discovery 560 (LLDP-MED) [ANSI/TIA-1057] provide the ability to acquire location 561 information directly from an LLDP endpoint. Where this 562 information is available, it might be unnecessary to use any other 563 form of location configuration. 565 The Device MUST report the values directly as they were provided by 566 the adjacent node. Attempting to adjust or translate the type of 567 identifier is likely to cause the measurement data to be useless. 569 Where a Device has received LLDP messages from multiple adjacent 570 nodes, it should provide information extracted from those messages by 571 repeating the "lldp" element. 573 An example of an LLDP measurement is shown in Figure 4. This shows 574 an adjacent node (chassis) that is identified by the IP address 575 192.0.2.45 (hexadecimal c000022d) and the port on that node is 576 numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2). 578 580 581 c000022d 582 a2 583 584 586 Figure 4: LLDP Measurement Example 588 IEEE 802 Devices that are able to obtain information about adjacent 589 network switches and their attachment to them by other means MAY use 590 this data type to convey this information. 592 5.2. DHCP Relay Agent Information Measurements 594 The DHCP Relay Agent Information option [RFC3046] provides 595 measurement data about the network attachment of a Device. This 596 measurement data can be included in the "dhcp-rai" element. 598 The elements in the DHCP relay agent information options are opaque 599 data types assigned by the DHCP relay agent. The three items are all 600 optional: circuit identifier ("circuit", [RFC3046]), remote 601 identifier ("remote", [RFC3046], [RFC4649]) and subscriber identifier 602 ("subscriber", [RFC3993], [RFC4580]). The DHCPv6 remote identifier 603 has an associated enterprise number [IANA.enterprise] as an XML 604 attribute. 606 608 609 ::ffff:192.0.2.158 610 108b 611 612 614 Figure 5: DHCP Relay Agent Information Measurement Example 616 The "giaddr" is specified as a dotted quad IPv4 address or an RFC 617 4291 [RFC4291] IPv6 address. The enterprise number is specified as a 618 decimal integer. All other information is included verbatim from the 619 DHCP request in hexadecimal format. 621 5.3. 802.11 WLAN Measurements 623 In WiFi, or 802.11, networks a Device might be able to provide 624 information about the wireless access point (WAP) that it is attached 625 to, or other WiFi points it is able to see. This is provided using 626 the "wifi" element, as shown in Figure 6. 628 630 631 Intel(r)PRO/Wireless 2200BG 632 633 wlan-home 634 00-12-F0-A0-80-EF 635 95 636 637 638 wlan-home 639 00-12-F0-A0-80-F0 640 15 641 642 643 wlan-home 644 00-12-F0-A0-80-F1 645 12 646 647 648 wlan-home 649 00-12-F0-A0-80-F2 650 5 651 652 653 655 Figure 6: 802.11 WLAN Measurement Example 657 A wifi element is made up of a serving WAP, zero or more neighbouring 658 WAPs, and an optional "nicType" element. Each WAP element is 659 comprised of the following fields: 661 ssid: The service set identifier for the wireless network. This 662 parameter MAY be provided. 664 bssid: The basic service set identifier. In an Infrastructure BSS 665 network, the bssid is the 48 bit MAC address of the wireless 666 access point, and it MUST be provided. 668 wapname: The broadcast name for the wireless access point. 670 location: The location of the wireless access point, as reported 671 using by the wireless access point. This element contains GML 672 geometry, following the restrictions described in [RFC5491]. 674 type: The network type for the network access. This element 675 includes the alphabetic suffix of the 802.11 specification that 676 defines the radio interface; e.g. "a", "b", "g", or "n". 678 channel: The channel number (frequency) that the wireless access 679 point operates on. 681 regclass: The regulatory domain and class. The "country" attribute 682 optionally includes the applicable three character country 683 identifier (assuming US-ASCII encoding). The element text content 684 includes the value of the regulatory class: an 8-bit integer. 686 wap: Measurement information for the WAP, as observed by the Device. 687 Some of these values are derived from 802.11v [IEEE.80211V] 688 messages exchanged between Device and WAP. The contents of this 689 element include: 691 transmit: The transmit power reported by the WAP, in dB. 693 gain: The gain of the WAP antenna reported by the WAP, in dB. 695 rcpi: The received channel power indicator, as measured by the 696 Device. This value SHOULD be in units of dBm (with RMS error 697 in dB). If the units are unknown, the "dBm" attribute MUST be 698 set to "false". Signal strength reporting on current hardware 699 uses a range of different units; therefore, the value of the 700 "nicType" element SHOULD be included if the units are not known 701 to be in dBm and the value reported by the hardware should be 702 included without modification. This element includes optional 703 "rmsError" and "samples" attributes. 705 rsni: The received signal to noise indicator in dBm. This 706 element includes optional "rmsError" and "samples" attributes. 708 rtd: The total round trip delay from the time that a message is 709 sent by the Device to the time that it receives an 710 acknowledgement from the access point. This measurement 711 includes any delays that might occur between the time that the 712 access point receives the message and the time that it sends 713 the response. If the delay at an access point is known, this 714 value can be used to calculate an approximate distance between 715 device and access point. This element includes optional 716 "rmsError" and "samples" attributes. 718 device: Measurement information for the device, as reported by the 719 WAP. This element contains the same child elements as the "wap" 720 element, with the WAP and Device roles reversed. 722 All elements are optional except for "bssid". 724 The "nicType" element is used to specify the make and model of the 725 wireless network interface in the Device. Different 802.11 chipsets 726 report measurements in different ways, so knowing the network 727 interface type aids the LIS in determining how to use the provided 728 measurement data. The content of this field is unconstrained and no 729 mechanisms are specified to ensure uniqueness. 731 5.3.1. Wifi Measurement Requests 733 Two elements are defined for requesting WiFi measurements in a 734 measurement request: 736 type: The "type" element identifies the desired type (or types that 737 are requested. 739 parameter: The "parameter" element identifies an optional 740 measurements are requested for each measured access point. An 741 element is identified by its qualified name. The optional 742 "context" parameter can be used to specify if an element is 743 included as a child of the "wap" or "device" elements; omission 744 indicates that it applies to both. 746 Multiple types or parameters can be requested by repeating either 747 element. 749 5.4. Cellular Measurements 751 Cellular Devices are common throughout the world and base station 752 identifiers can provide a good source of coarse location information. 753 This information can be provided to a LIS run by the cellar operator, 754 or may be provided to an alternative LIS operator that has access to 755 one of several global cell-id to location mapping databases. 757 A number of advanced location determination methods have been 758 developed for cellular networks. For these methods a range of 759 measurement parameters can be collected by the network, Device, or 760 both in cooperation. This document includes a basic identifier for 761 the wireless transmitter only; future efforts might define additional 762 parameters that enable more accurate methods of location 763 determination. 765 The cellular measurement set allows a Device to report to a LIS any 766 LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9) or CDMA (Figure 10) 767 cells that it is able to observe. Cells are reported using their 768 global identifiers. All 3GPP cells are identified by public land 769 mobile network (PLMN), which is formed of mobile country code (MCC) 770 and mobile network code (MNC); specific fields are added for each 771 network type. All other values are decimal integers. 773 775 776 777 46520 778 80936424 779 780 781 46506 782 10736789 783 784 785 787 Long term evolution (LTE) cells are identified by a 28-bit cell 788 identifier (eucid). 790 Figure 7: Example LTE Cellular Measurement 792 794 795 796 46520 797 200065000 798 799 800 46506 801 1638332767 802 803 804 806 Universal mobile telephony service (UMTS) cells are identified by 807 radio network controller (rnc) and cell id (cid). 809 Figure 8: Example UMTS Cellular Measurement 811 813 814 815 46506 816 1638332767 817 818 819 821 Global System for Mobile communication (GSM) cells are identified by 822 local radio network controller (rnc) and cell id (cid). 824 Figure 9: Example GSM Cellular Measurement 826 828 829 830 47231589212 831 832 833 47231589213 834 835 836 838 Code division multiple access (CDMA) cells are not identified by 839 PLMN, instead these use network id (nid), system id (sid) and base 840 station id (baseid). 842 Figure 10: Example CDMA Cellular Measurement 844 In general a cellular Device will be attached to the cellular network 845 and so the notion of a serving cell exists. Cellular network also 846 provide overlap between neighbouring sites, so a mobile Device can 847 hear more than one cell. The measurement schema supports sending 848 both the serving cell and any other cells that the mobile might be 849 able to hear. In some cases, the Device may simply be listening to 850 cell information without actually attaching to the network, mobiles 851 without a SIM are an example of this. In this case the Device may 852 simply report cells it can hear without flagging one as a serving 853 cell. An example of this is shown in Figure 11. 855 857 858 859 46520 860 200065000 861 862 863 46506 864 1638332767 865 866 867 869 Figure 11: Example Observed Cellular Measurement 871 5.4.1. Cellular Measurement Requests 873 Two elements can be used in measurement requests for cellular 874 measurements: 876 type: A label indicating the type of identifier to provide: one of 877 "gsm", "umts", "lte", or "cdma". 879 network: The network portion of the cell identifier. For 3GPP 880 networks, this is the combination of MCC and MNC; for CDMA, this 881 is the network identifier. 883 Multiple identifier types or networks can be identified by repeating 884 either element. 886 5.5. GNSS Measurements 888 GNSS use orbiting satellites to transmit signals. A Device with a 889 GNSS receiver is able to take measurements from the satellite 890 signals. The results of these measurements can be used to determine 891 time and the location of the Device. 893 Determining location and time in autonomous GNSS receivers follows 894 three steps: 896 Signal acquisition: During the signal acquisition stage, the 897 receiver searches for the repeating code that is sent by each GNSS 898 satellite. Successful operation typically requires measurement 899 data for a minimum of 5 satellites. At this stage, measurement 900 data is available to the Device. 902 Navigation message decode: Once the signal has been acquired, the 903 receiver then receives information about the configuration of the 904 satellite constellation. This information is broadcast by each 905 satellite and is modulated with the base signal at a low rate; for 906 instance, GPS sends this information at about 50 bits per second. 908 Calculation: The measurement data is combined with the data on the 909 satellite constellation to determine the location of the receiver 910 and the current time. 912 A Device that uses a GNSS receiver is able to report measurements 913 after the first stage of this process. A LIS can use the results of 914 these measurements to determine a location. In the case where there 915 are fewer results available than the optimal minimum, the LIS might 916 be able to use other sources of measurement information and combine 917 these with the available measurement data to determine a position. 919 Note: The use of different sets of GNSS _assistance data_ can 920 reduce the amount of time required for the signal acquisition 921 stage and obviate the need for the receiver to extract data on the 922 satellite constellation. Provision of assistance data is outside 923 the scope of this document. 925 Figure 12 shows an example of GNSS measurement data. The measurement 926 shown is for the GPS system and includes measurement data for three 927 satellites only. 929 931 933 934 499.9395 935 0.87595747 936 45 937 938 939 378.2657 940 0.56639479 941 52 942 943 944 -633.0309 945 0.57016835 946 48 947 948 949 951 Figure 12: Example GNSS Measurement 953 Each "gnss" element represents a single set of GNSS measurement data, 954 taken at a single point in time. Measurements taken at different 955 times can be included in different "gnss" elements to enable 956 iterative refinement of results. 958 GNSS measurement parameters are described in more detail in the 959 following sections. 961 5.5.1. GNSS System and Signal 963 The GNSS measurement structure is designed to be generic and to apply 964 to different GNSS types. Different signals within those systems are 965 also accounted for and can be measured separately. 967 The GNSS type determines the time system that is used. An indication 968 of the type of system and signal can ensure that the LIS is able to 969 correctly use measurements. 971 Measurements for multiple GNSS types and signals can be included by 972 repeating the "gnss" element. 974 This document creates an IANA registry for GNSS types. Two satellite 975 systems are registered by this document: GPS and Galileo. Details 976 for the registry are included in Section 9.1. 978 5.5.2. Time 980 Each set of GNSS measurements is taken at a specific point in time. 981 The "time" attribute is used to indicate the time that the 982 measurement was acquired, if the receiver knows how the time system 983 used by the GNSS relates to UTC time. 985 Alternative to (or in addition to) the measurement time, the 986 "gnssTime" element MAY be included. The "gnssTime" element includes 987 a relative time in milliseconds using the time system native to the 988 satellite system. For the GPS satellite system, the "gnssTime" 989 element includes the time of week in milliseconds. For the Galileo 990 system, the "gnssTime" element includes the time of day in 991 milliseconds. 993 The accuracy of the time measurement provided is critical in 994 determining the accuracy of the location information derived from 995 GNSS measurements. The receiver SHOULD indicate an estimated time 996 error for any time that is provided. An RMS error can be included 997 for the "gnssTime" element, with a value in milliseconds. 999 5.5.3. Per-Satellite Measurement Data 1001 Multiple satellites are included in each set of GNSS measurements 1002 using the "sat" element. Each satellite is identified by a number in 1003 the "num" attribute. The satellite number is consistent with the 1004 identifier used in the given GNSS. 1006 Both the GPS and Galileo systems use satellite numbers between 1 and 1007 64. 1009 The GNSS receiver measures the following parameters for each 1010 satellite: 1012 doppler: The observed Doppler shift of the satellite signal, 1013 measured in meters per second. This is converted from a value in 1014 Hertz by the receiver to allow the measurement to be used without 1015 knowledge of the carrier frequency of the satellite system. This 1016 value includes an optional RMS error attribute, also measured in 1017 meters per second. 1019 codephase: The observed code phase for the satellite signal, 1020 measured in milliseconds. This is converted from a value in chips 1021 or wavelengths. Increasing values indicate increasing 1022 pseudoranges. This value includes an optional RMS error 1023 attribute, also measured in milliseconds. 1025 cn0: The signal to noise ratio for the satellite signal, measured in 1026 decibel-Hertz (dB-Hz). The expected range is between 20 and 50 1027 dB-Hz. 1029 mp: An estimation of the amount of error that multipath signals 1030 contribute in metres. This parameter is optional. 1032 cq: An indication of the carrier quality. Two attributes are 1033 included: "continuous" may be either "true" or "false"; direct may 1034 be either "direct" or "inverted". This parameter is optional. 1036 adr: The accumulated Doppler range, measured in metres. This 1037 parameter is optional and is not necessary unless multiple sets of 1038 GNSS measurements are provided. 1040 All values are converted from measures native to the satellite system 1041 to generic measures to ensure consistency of interpretation. Unless 1042 necessary, the schema does not constrain these values. 1044 5.5.4. GNSS Measurement Requests 1046 Measurement requests can include a "gnss" element, which includes the 1047 "system" and "signal" attributes. Multiple elements can be included 1048 to indicate a requests for GNSS measurements from multiple systems or 1049 signals. 1051 5.6. DSL Measurements 1053 Digital Subscriber Line (DSL) networks rely on a range of network 1054 technology. DSL deployments regularly require cooperation between 1055 multiple organizations. These fall into two broad categories: 1056 infrastructure providers and Internet service providers (ISPs). 1057 Infrastructure providers manage the bulk of the physical 1058 infrastructure including cabling. End users obtain their service 1059 from an ISP, which manages all aspects visible to the end user 1060 including IP address allocation and operation of a LIS. See 1061 [DSL.TR025] and [DSL.TR101] for further information on DSL network 1062 deployments. 1064 Exchange of measurement information between these organizations is 1065 necessary for location information to be correctly generated. The 1066 ISP LIS needs to acquire location information from the infrastructure 1067 provider. However, the infrastructure provider has no knowledge of 1068 Device identifiers, it can only identify a stream of data that is 1069 sent to the ISP. This is resolved by passing measurement data 1070 relating to the Device to a LIS operated by the infrastructure 1071 provider. 1073 5.6.1. L2TP Measurements 1075 Layer 2 Tunneling Protocol (L2TP) is a common means of linking the 1076 infrastructure provider and the ISP. The infrastructure provider LIS 1077 requires measurement data that identifies a single L2TP tunnel, from 1078 which it can generate location information. Figure 13 shows an 1079 example L2TP measurement. 1081 1083 1084 1085 192.0.2.10 1086 192.0.2.61 1087 528 1088 1089 1090 1092 Figure 13: Example DSL L2TP Measurement 1094 5.6.2. RADIUS Measurements 1096 When authenticating network access, the infrastructure provider might 1097 employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or 1098 Access Node (AN). These messages provide the ISP RADIUS server with 1099 an identifier for the DSLAM or AN, plus the slot and port that the 1100 Device is attached on. These data can be provided as a measurement, 1101 which allows the infrastructure provider LIS to generate location 1102 information. 1104 The format of the AN, slot and port identifiers are not defined in 1105 the RADIUS protocol. Slot and port together identify a circuit on 1106 the AN, analogous to the circuit identifier in [RFC3046]. These 1107 items are provided directly, as they were in the RADIUS message. An 1108 example is shown in Figure 14. 1110 1112 1113 AN-7692 1114 3 1115 06 1116 1117 1119 Figure 14: Example DSL RADIUS Measurement 1121 5.6.3. Ethernet VLAN Tag Measurements 1123 For Ethernet-based DSL access networks, the DSL Access Module (DSLAM) 1124 or Access Node (AN) provide two VLAN tags on packets. A C-TAG is 1125 used to identify the incoming residential circuit, while the S-TAG is 1126 used to identify the DSLAM or AN. The C-TAG and S-TAG together can 1127 be used to identify a single point of network attachment. An example 1128 is shown in Figure 15. 1130 1132 1133 613 1134 1097 1135 1136 1138 Figure 15: Example DSL VLAN Tag Measurement 1140 Alternatively, the C-TAG can be replaced by data on the slot and port 1141 that the Device is attached to. This information might be included 1142 in RADIUS requests that are proxied from the infrastructure provider 1143 to the ISP RADIUS server. 1145 5.6.4. ATM Virtual Circuit Measurements 1147 An ATM virtual circuit can be employed between the ISP and 1148 infrastructure provider. Providing the virtual port ID (VPI) and 1149 virtual circuit ID (VCI) for the virtual circuit gives the 1150 infrastructure provider LIS the ability to identify a single data 1151 stream. A sample measurement is shown in Figure 16. 1153 1155 1156 55 1157 6323 1158 1159 1161 Figure 16: Example DSL ATM Measurement 1163 6. Measurement Schemas 1165 The schema are broken up into their respective functions. There is a 1166 base container schema into which all measurements are placed, plus 1167 definitions for a measurement request (Section 6.1). A PIDF-LO 1168 extension is defined in a separate schema (Section 6.2). There is a 1169 basic types schema, that contains various base type definitions for 1170 things such as the "rmsError" and "samples" attributes IPv4, IPv6 and 1171 MAC addresses (Section 6.3). Then each of the specific measurement 1172 types is defined in its own schema. 1174 6.1. Measurement Container Schema 1176 1177 1185 1186 1188 1189 1190 1192 This schema defines a framework for location measurements. 1193 1194 1196 1198 1199 1200 1201 1202 1203 1205 1206 1207 1208 1209 1210 1211 1212 1213 1215 1217 1218 1219 1220 1221 1223 1225 1226 1227 1228 1230 1231 1232 1233 1234 1236 1237 1238 1239 1240 1241 1243 Measurement Container Schema 1245 6.2. Measurement Source Schema 1247 1248 1255 1256 1258 1259 1260 1262 This schema defines an extension to PIDF-LO that indicates the 1263 type of source that produced the measurement data used in 1264 generating the associated location information. 1265 1266 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1282 Measurement Source PIDF-LO Extension Schema 1284 6.3. Base Type Schema 1286 Note that the pattern rules in the following schema wrap due to 1287 length constraints. None of the patterns contain whitespace. 1289 1290 1297 1298 1300 1301 1302 1304 This schema defines a set of base type elements. 1305 1306 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1348 1349 1350 1352 1353 1354 1355 1356 An IP version 6 address, based on RFC 4291. 1357 1358 1359 1360 1361 1362 1363 1364 1365 1367 1369 1371 1373 1375 1377 1378 1379 1380 1388 1389 1390 1391 1393 1394 1395 1396 1400 1401 1403 1405 1406 1407 1408 1409 1411 1413 Base Type Schema 1415 6.4. LLDP Measurement Schema 1417 1418 1426 1427 1429 1430 1431 1433 This schema defines a set of LLDP location measurements. 1434 1435 1436 1438 1439 1440 1441 1442 1443 1444 1445 1447 1448 1449 1450 1451 1453 1454 1455 1456 1458 1459 1460 1462 1463 1464 1465 1466 1467 1469 1471 LLDP measurement schema 1473 6.5. DHCP Measurement Schema 1475 1476 1484 1485 1487 1488 1489 1491 This schema defines a set of DHCP location measurements. 1492 1493 1495 1497 1498 1499 1500 1501 1502 1503 1504 1506 1508 1510 1512 1513 1514 1515 1516 1518 1519 1520 1521 1523 1524 1525 1527 1529 DHCP measurement schema 1531 6.6. WiFi Measurement Schema 1532 1533 1542 1543 1545 WiFi location measurements 1546 1547 1548 1550 This schema defines a basic set of WiFi location measurements. 1551 1552 1554 1555 1557 1559 1560 1561 1562 1563 1565 1566 1567 1568 1569 1571 1572 1573 1574 1575 1577 1578 1579 1580 1581 1583 1584 1586 1588 1590 1592 1594 1595 1596 1598 1599 1600 1601 1602 1604 1605 1606 1607 1608 1610 1611 1612 1613 1614 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1629 1631 1632 1633 1634 1635 1637 1638 1639 1640 1641 1642 1643 1645 1647 1649 1651 1652 1653 1654 1656 1657 1658 1659 1660 1661 1662 1664 1665 1666 1668 1669 1670 1671 1672 1673 1674 1675 1676 1678 1679 1680 1681 1682 1684 1686 WiFi measurement schema 1688 6.7. Cellular Measurement Schema 1690 1691 1698 1699 1701 1702 1703 1705 This schema defines a set of cellular location measurements. 1706 1707 1709 1711 1712 1713 1714 1715 1716 1717 1718 1719 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1745 1746 1747 1748 1749 1750 1752 1753 1755 1756 1757 1758 1760 1761 1762 1763 1764 1766 1767 1768 1769 1770 1772 1773 1774 1775 1776 1778 1780 1781 1782 1783 1784 1785 1786 1787 1788 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1805 1807 Cellular measurement schema 1809 6.8. GNSS Measurement Schema 1811 1812 1820 1821 1823 1824 1825 1827 This schema defines a set of GNSS location measurements 1828 1829 1831 1833 1834 1835 1836 1837 1838 1839 1841 1842 1843 1844 1845 1847 1849 1851 1852 1853 1854 1855 1856 1857 1859 1860 1861 1862 1863 1864 1865 1866 1868 1871 1872 1873 1875 1876 1877 1879 1880 1881 1882 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1897 GNSS measurement Schema 1899 6.9. DSL Measurement Schema 1901 1902 1910 1911 1913 DSL measurement definitions 1914 1915 1916 1918 This schema defines a basic set of DSL location measurements. 1920 1921 1923 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1964 1965 1966 1967 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1982 1984 DSL measurement schema 1986 7. Privacy Considerations 1988 Location-related measurement data can be as privacy sensitive as 1989 location information. 1991 Measurement data is effectively equivalent to location information if 1992 the contextual knowledge necessary to generate one from the other is 1993 readily accessible. Even where contextual knowledge is difficult to 1994 acquire, there can be no assurance that an authorized recipient of 1995 the contextual knowledge is also authorized to receive location 1996 information. 1998 In order to protect the privacy of the subject of location-related 1999 measurement data, this implies that measurement data is protected 2000 with the same degree of protection as location information. 2002 7.1. Measurement Data Privacy Model 2004 It is less desirable to distribute measurement data in the same 2005 fashion as location information. Measurement data is less useful to 2006 location recipients than location information. Therefore, a simple 2007 distribution model is desirable. 2009 In this simple model, the Device is the only entity that is able to 2010 distribute measurement data. To use an analogy from the GEOPRIV 2011 architecture, the Device - as the Location Generator (or the 2012 Measurement Data Generator) - is the sole entity that can assume the 2013 roles of Rule Maker and Location Server. 2015 No entity can redistribute measurement data. The Device directs 2016 other entities in how measurement data is used and retained. 2018 7.2. LIS Privacy Requirements 2020 A LIS MUST NOT reveal location-related measurement data or location 2021 information based on measurement data to any other entity unless 2022 directed to do so by the Device. 2024 By adding measurement data to a request for location information, the 2025 Device implicitly grants permission for the LIS to generate the 2026 requested location information using the measurement data. 2027 Permission to use this data for any other purpose is not implied. 2029 As long as measurement data is only used in serving the request that 2030 contains it, rules regarding data retention are not necessary. A LIS 2031 MUST discard location-related measurement data after servicing a 2032 request, unless the Device grants permission to use that information 2033 for other purposes. 2035 7.3. Measurement Data and Location URIs 2037 A LIS MAY use measurement data provided by the Device to serve 2038 requests to location URIs, if the Device permits it. A Device 2039 permits this by including measurement data in a request that 2040 explcitly requests a location URI. By requesting a location URI, the 2041 Device grants permission for the LIS to use the measurement data in 2042 serving requests to that URI. 2044 Note: In HELD, the "any" type is not an explicit request for a 2045 location URI, though a location URI might be provided. 2047 The usefulness of measurement data that is provided in this fashion 2048 is limited. The measurement data is only valid at the time that it 2049 was acquired by the Device. At the time that a request is made to a 2050 location URI, the Device might have moved, rendering the measurement 2051 data incorrect. 2053 A Device is able to explicitly limit the time that a LIS retains 2054 measurement data by adding an expiry time to the measurement data, 2055 see Section 4.1.2. 2057 7.4. Third-Party-Provided Measurement Data 2059 An authorized third-party request for the location of a Device (see 2060 [I-D.ietf-geopriv-held-identity-extensions]) can include location- 2061 related measurement data. This is possible where the third-party is 2062 able to make observations about the Device. 2064 A third-party that provides measurement data MUST be authorized to 2065 provide the specific measurement for the identified device. A third- 2066 party MUST either be trusted by the LIS for the purposes of providing 2067 measurement data of the provided type, or the measurement data MUST 2068 be validated (see Section 8.2.1) before being used. 2070 How a third-party authenticates its identity or gains authorization 2071 to use measurement data is not covered by this document. 2073 8. Security Considerations 2075 Use of location-related measurement data has privacy considerations 2076 that are discussed in Section 7. 2078 8.1. Threat Model 2080 The threat model for location-related measurement data concentrates 2081 on the Device providing falsified, stolen or incorrect measurement 2082 data. 2084 A Device that provides location location-related measurement data 2085 might use data to: 2087 o acquire the location of another Device, without authorization; 2089 o extract information about network topology; or 2091 o coerce the LIS into providing falsified location information based 2092 on the measurement data. 2094 8.1.1. Acquiring Location Information Without Authorization 2096 Requiring authorization for location requests is an important part of 2097 privacy protections of a location protocol. A location configuration 2098 protocol usually operates under a restricted policy that allows a 2099 requester to obtain their own location. HELD identity extensions 2100 [I-D.ietf-geopriv-held-identity-extensions] allows other entities to 2101 be authorized, conditional on a Rule Maker providing sufficient 2102 authorization. 2104 The intent of these protections is to ensure that a location 2105 recipient is authorized to acquire location information. Location- 2106 related measurement data could be used by an attacker to circumvent 2107 such authorization checks if the association between measurement data 2108 and Target Device is not validated by a LIS. 2110 A LIS can be coerced into providing location information for a Device 2111 that a location recipient is not authorized to receive. A request 2112 identifies one Device (implicitly or explicitly), but measurement 2113 data is provided for another Device. If the LIS does not check that 2114 the measurement data is for the identified Device, it could 2115 incorrectly authorize the request. 2117 By using unvalidated measurement data to generate a response, the LIS 2118 provides information about a Device without appropriate 2119 authorization. 2121 The feasibility of this attack depends on the availability of 2122 information that links a Device with measurement data. In some 2123 cases, measurement data that is correlated with a target is readily 2124 available. For instance, LLDP measurements (Section 5.1) are 2125 broadcast to all nodes on the same network segment. An attacker on 2126 that network segment can easily gain measurement data that relates a 2127 Device with measurements. 2129 For some types of measurement data, it's necessary for an attacker to 2130 know the location of the target in order to determine what 2131 measurements to use. This attack is meaningless for types of 2132 measurement data that require that the attacker first know the 2133 location of the target before measurement data can be acquired or 2134 fabricated. GNSS measurements (Section 5.5) share this trait with 2135 many wireless location determination methods. 2137 8.1.2. Extracting Network Topology Data 2139 Allowing requests with measurements might be used to collect 2140 information about a network topology. This is possible if requests 2141 containing measurements are permitted. 2143 Network topology can be considered sensitive information by a network 2144 operator for commercial or security reasons. While it is impossible 2145 to completely prevent a Device from acquiring some knowledge of 2146 network topology if a location service is provided, a network 2147 operator might desire to limit how much of this information is made 2148 available. 2150 Mapping a network topology does not require that an attacker be able 2151 to associate measurement data with a particular Device. If a 2152 requester is able to try a number of measurements, it is possible to 2153 acquire information about network topology. 2155 It is not even necessary that the measurements are valid; random 2156 guesses are sufficient, provided that there is no penalty or cost 2157 associated with attempting to use the measurements. 2159 8.1.3. Lying By Proxy 2161 Location information is a function of its inputs, which includes 2162 measurement data. Thus, falsified measurement data can be used to 2163 alter the location information that is provided by a LIS. 2165 Some types of measurement data are relatively easy to falsify in a 2166 way that the resulting location information to be selected with 2167 little or no error. For instance, GNSS measurements are easy to use 2168 for this purpose because all the contextual information necessary to 2169 calculate a position using measurements is broadcast by the 2170 satellites [HARPER]. 2172 An attacker that falsifies measurement data gains little if they are 2173 the only recipients of the result. The attacker knows that the 2174 location information is bad. The attacker only gains if the 2175 information can somehow be attributed to the LIS by another location 2176 recipient. 2178 A recipient might evaluate the trustworthiness of the location 2179 information based on the credibility of its source. By coercing the 2180 LIS into providing falsified location information, any credibility 2181 that the LIS might have - that the attacker does not - is gained by 2182 the attacker. 2184 A third-party that is reliant on the integrity of the location 2185 information might base an evaluation of the credibility of the 2186 information on the source of the information. If that third party is 2187 able to attribute location information to the LIS, then an attacker 2188 might gain. 2190 Location information that is provided to the Device without any means 2191 to identify the LIS as its source is not subject to this attack. The 2192 Device is identified as the source of the data when it distributes 2193 the location information to location recipients. 2195 An attacker gains if they are able to coerce the LIS into providing 2196 location information based on falsified measurement data and that 2197 information can be attributed to the LIS. 2199 Location information is attributed to the LIS either through the use 2200 of digital signatures or by having the location recipient directly 2201 interact with the LIS. A LIS that digitally signs location 2202 information becomes identifiable as the source of the data. 2203 Similarly, the LIS is identified as a source of data if a location 2204 recipient acquires information directly from a LIS using a location 2205 URI. 2207 8.1.4. Measurement Replay 2209 The value of some measured properties do not change over time for a 2210 single location. This allows for simple replay attacks, where an 2211 attacker acquires measurements that can later be used without being 2212 detected as being invalid. 2214 Measurement data is frequently an observation of an time-invariant 2215 property of the environment at the subject location. For 2216 measurements of this nature, nothing in the measurement itself is 2217 sufficient proof that the Device is present at the resulting 2218 location. Measurement data might have been previously acquired and 2219 reused. 2221 For instance, the identity of a radio transmitter, if broadcast by 2222 that transmitter, can be collected and stored. An attacker that 2223 wishes it known that they exist at a particular location, can claim 2224 to observe this transmitter at any time. Nothing inherent in the 2225 claim reveals it to be false. 2227 For properties of a network, time-invariance is often directly as a 2228 result of the practicalities of operating the network. Limiting the 2229 changes to a network ensures greater consistency of service. A 2230 largely static network also greatly simplifies the data management 2231 tasks involved with providing a location service. 2233 8.2. Mitigation 2235 The following measures can be applied to limit or prevent attacks. 2236 The effectiveness of each depends on the type of measurement data and 2237 how that measurement data is acquired. 2239 Two general approaches are identified for dealing with untrusted 2240 measurement data: 2242 1. Require independent validation of measurement data or the 2243 location information that is produced. 2245 2. Identify the types of sources that provided the measurement data 2246 that location information was derived from. 2248 This section goes into more detail on the different forms of 2249 validation in Section 8.2.1, Section 8.2.2, and Section 8.2.3. The 2250 impact of attributing location information to sources is discussed in 2251 more detail in Section 8.2.4. 2253 8.2.1. Measurement Validation 2255 Detecting that measurement data has been falsified is difficult in 2256 the absence of integrity mechanisms. 2258 Independent confirmation of the veracity of measurement data ensures 2259 that the measurement is accurate and that it applies to the correct 2260 Device. By gathering the same measurement data from a trusted and 2261 independent source, the LIS is able to check that the measurement 2262 data is correct. 2264 Measurement information might contain no inherent indication that it 2265 is falsified. On the contrary, it can be difficult to obtain 2266 information that would provide any degree of assurance that the 2267 measurement device is physically at any particular location. 2268 Measurements that are difficult to verify require other forms of 2269 assurance before they can be used. 2271 8.2.1.1. Effectiveness 2273 Measurement validation MUST be used if measurement data for a 2274 particular Device can be easily acquired by unauthorized location 2275 recipients, as described in Section 8.1.1. This prevents 2276 unauthorized access to location information using measurement data. 2278 Validation of measurement data can be significantly more effective 2279 than independent acquisition of the same. For instance, a Device in 2280 a large Ethernet network could provide a measurement indicating its 2281 point of attachment using LLDP measurements. For a LIS, acquiring 2282 the same measurement data might require a request to all switches in 2283 that network. With the measurement data, validation can target the 2284 identified switch with a specific query. 2286 Validation is effective in identifying falsified measurement data 2287 (Section 8.1.3), including attacks involving replay of measurement 2288 data (Section 8.1.4). Validation also limits the amount of network 2289 topology information (Section 8.1.2) made available to Devices to 2290 that portion of the network topology that they are directly attached. 2292 8.2.1.2. Limitations (Unique Observer) 2294 A Device is often in a unique position to make a measurement. It 2295 alone occupies the point in space-time that the location 2296 determination process seeks to determine. The Device becomes a 2297 unique observer for a particular property. 2299 The ability of the Device to become a unique observer makes the 2300 Device invaluable to the location determination process. As a unique 2301 observer, it also makes the claims of a Device difficult to validate 2302 and easily to spoof. 2304 As long as no other entity is capable of making the same 2305 measurements, there is also no other entity that can independently 2306 check that the measurements are correct and applicable to the Device. 2307 A LIS might be unable to validate all or part of the measurement data 2308 it receives from a unique observer. For instance, a signal strength 2309 measurement of the signal from a radio tower cannot be validated 2310 directly. 2312 Some portion of the measurement data might still be independently 2313 verified, even if all information cannot. In the previous example, 2314 the radio tower might be able to provide verification that the Device 2315 is present if it is able to observe a radio signal sent by the 2316 Device. 2318 If measurement data can only be partially validated, the extent to 2319 which it can be validated determines the effectiveness of validation 2320 against these attacks. 2322 The advantage of having the Device as a unique observer is that it 2323 makes it difficult for an attacker to acquire measurements without 2324 the assistance of the Device. Attempts to use measurements to gain 2325 unauthorized access to measurement data (Section 8.1.1) are largely 2326 ineffectual against a unique observer. 2328 8.2.2. Location Validation 2330 Location information that is derived from location-related 2331 measurement data can also be verified against trusted location 2332 information. Rather than validating inputs to the location 2333 determination process, suspect locations are identified at the output 2334 of the process. 2336 Trusted location information is acquired using sources of measurement 2337 data that are trusted. Untrusted location information is acquired 2338 using measurement data provided from untrusted sources, which might 2339 include the Device. These two locations are compared. If the 2340 untrusted location agrees with the trusted location, the untrusted 2341 location information is used. 2343 Algorithms for the comparison of location information are not 2344 included in this document. However, a simple comparison for 2345 agreement might require that the untrusted location be entirely 2346 contained within the uncertainty region of the trusted location. 2348 There is little point in using a less accurate, less trusted 2349 location. Untrusted location information that has worse accuracy 2350 than trusted information can be immediately discarded. There are 2351 multiple factors that affect accuracy, uncertainty and currency being 2352 the most important. How location information is compared for 2353 accuracy is not defined in this document. 2355 8.2.2.1. Effectiveness 2357 Location validation limits the extent to which falsified - or 2358 erroneous - measurement data can cause an incorrect location to be 2359 reported. 2361 Location validation can be more efficient than validation of inputs, 2362 particularly for a unique observer (Section 8.2.1.2). 2364 Validating location ensures that the Device is at or near the 2365 resulting location. Location validation can be used to limit or 2366 prevent all of the attacks identified in this document. 2368 8.2.2.2. Limitations 2370 The trusted location that is used for validation is always less 2371 accurate than the location that is being checked. The amount by 2372 which the untrusted location is more accurate, is the same amount 2373 that an attacker can exploit. 2375 For example, a trusted location might indicate a five kilometer 2376 radius uncertainty region. An untrusted location that describes a 2377 100 meter uncertainty within the larger region might be accepted as 2378 more accurate. An attacker might still falsify measurement data to 2379 select any location within the larger uncertainty region. While the 2380 100 meter uncertainty that is reported seems more accurate, a 2381 falsified location could be anywhere in the five kilometer region. 2383 Where measurement data might have been falsified, the actual 2384 uncertainty is effectively much higher. Local policy might allow 2385 differing degrees of trust to location information derived from 2386 untrusted measurement data. This might not be a boolean operation 2387 with only two possible outcomes: untrusted location information might 2388 be used entirely or not at all, or it could be combined with trusted 2389 location information with the degree to which each contributes based 2390 on a value set in local policy. 2392 8.2.3. Supporting Observations 2394 Replay attacks using previously acquired measurement data are 2395 particularly hard to detect without independent validation. Rather 2396 than validate the measurement data directly, supplementary data might 2397 be used to validate measurements or the location information derived 2398 from those measurements. 2400 These supporting observations could be used to convey information 2401 that provides additional assurance that the Device was acquired at a 2402 specific time and place. In effect, the Device is requested to 2403 provide proof of its presence at the resulting location. 2405 For instance, a Device that measures attributes of a radio signal 2406 could also be asked to provide a sample of the measured radio signal. 2407 If the LIS is able to observe the same signal, the two observations 2408 could be compared. Providing that the signal cannot be predicted in 2409 advance by the Device, this could be used to support the claim that 2410 the Device is able to receive the signal. Thus, the Device is likely 2411 to be within the range that the signal is transmitted. A LIS could 2412 use this to attribute a higher level of trust in the associated 2413 measurement data or resulting location. 2415 8.2.3.1. Effectiveness 2417 The use of supporting observations is limited by the ability of the 2418 LIS to acquire and validate these observations. The advantage of 2419 selecting observations independent of measurement data is that 2420 observations can be selected based on how readily available the data 2421 is for both LIS and Device. The amount and quality of the data can 2422 be selected based on the degree of assurance that is desired. 2424 Use of supporting observations is similar to both measurement 2425 validation and location validation. All three methods rely on 2426 independent validation of one or more properties. Applicability of 2427 each method is similar. 2429 Use of supporting observations can be used to limit or prevent all of 2430 the attacks identified in this document. 2432 8.2.3.2. Limitations 2434 The effectiveness of the validation method depends on the quality of 2435 the supporting observation: how hard it is to obtain at a different 2436 time or place, how difficult it is to guess and what other costs 2437 might be involved in acquiring this data. 2439 In the example of an observed radio signal, requesting a sample of 2440 the signal only provides an assurance that the Device is able to 2441 receive the signal transmitted by the measured radio transmitter. 2442 This only provides some assurance that the Device is within range of 2443 the transmitter. 2445 As with location validation, a Device might still be able to provide 2446 falsified measurements that could alter the value of the location 2447 information as long as the result is within this region. 2449 Requesting additional supporting observations can reduce the size of 2450 the region over which location information can be altered by an 2451 attacker, or increase trust in the result, but each additional has a 2452 cost. Supporting observations contribute little or nothing toward 2453 the primary goal of determining the location of the Device. Any 2454 costs in acquiring supporting observations are balanced against the 2455 degree of integrity desired of the resulting location information. 2457 8.2.4. Attribution 2459 Lying by proxy (Section 8.1.3) relies on the location recipient being 2460 able to attribute location information to a LIS. The effectiveness 2461 of this attack is negated if location information is explicitly 2462 attributed to a particular source. 2464 This requires an extension to the location object that explicitly 2465 identifies the source (or sources) of each item of location 2466 information. 2468 Rather than relying on a process that seeks to ensure that location 2469 information is accurate, this approach instead provides a location 2470 recipient with the information necessary to reach their own 2471 conclusion about the trustworthiness of the location information. 2473 Including an authenticated identity for all sources of measurement 2474 data is presents a number of technical and operational challenges. 2475 It is possible that the LIS has a transient relationship with a 2476 Device. A Device is not expected to share authentication information 2477 with a LIS. There is no assurance that Device identification is 2478 usable by a potential location recipient. Privacy concerns might 2479 also prevent the sharing identification information, even if it were 2480 available and usable. 2482 Identifying the type of measurement source allows a location 2483 recipient to make a decision about the trustworthiness of location 2484 information without depending on having authenticated identity 2485 information for each source. An element for this purpose is defined 2486 in Section 4.4. 2488 When including location information that is based on measurement data 2489 from sources that might be untrusted, a LIS SHOULD include 2490 alternative location information that is derived from trusted sources 2491 of measurement data. Each item of location information can then be 2492 labelled with the source of that data. 2494 A location recipient that is able to identify a specific source of 2495 measurement data (whether it be LIS or Device) can use this 2496 information to attribute location information to either or both 2497 entity. The location recipient is then better able to make decisions 2498 about trustworthiness based on the source of the data. 2500 A location recipient that does not understand the "source" element is 2501 unable to make this distinction. When constructing a PIDF-LO 2502 document, trusted location information MUST be placed in the PIDF-LO 2503 so that it is given higher priority to any untrusted location 2504 information according to Rule #8 of [RFC5491]. 2506 8.2.5. Stateful Correlation of Location Requests 2508 Stateful examination of requests can be used to prevent a Device from 2509 attempting to map network topology using requests for location 2510 information (Section 8.1.2). 2512 Simply limiting the rate of requests from a single Device reduces the 2513 amount of data that a Device can acquire about network topology. 2515 9. IANA Considerations 2517 This section creates a registry for GNSS types (Section 5.5) and 2518 registers the namespaces and schema defined in Section 6. 2520 9.1. IANA Registry for GNSS Types 2522 This document establishes a new IANA registry for Global Navigation 2523 Satellite System (GNSS) types. The registry includes tokens for the 2524 GNSS type and for each of the signals within that type. Referring to 2525 [RFC5226], this registry operates under "Specification Required" 2526 rules. The IESG will appoint an Expert Reviewer who will advise IANA 2527 promptly on each request for a new or updated GNSS type. 2529 Each entry in the registry requires the following information: 2531 GNSS name: the name and a brief description of the GNSS 2533 Brief description: the name and a brief description of the GNSS 2535 GNSS token: a token that can be used to identify the GNSS 2537 Signals: a set of tokens that represent each of the signals that the 2538 system provides 2540 Documentation reference: a reference to one or more stable, public 2541 specifications that outline usage of the GNSS, including (but not 2542 limited to) signal specifications and time systems 2544 The registry initially includes two registrations: 2546 GNSS name: Global Positioning System (GPS) 2548 Brief description: a system of satellites that use spread-spectrum 2549 transmission, operated by the US military for commercial and 2550 military applications 2552 GNSS token: gps 2554 Signals: L1, L2, L1C, L2C, L5 2556 Documentation reference: Navstar GPS Space Segment/Navigation User 2557 Interface [GPS.ICD] 2559 GNSS name: Galileo 2561 Brief description: a system of satellites that operate in the same 2562 spectrum as GPS, operated by the European Union for commercial 2563 applications 2565 GNSS Token: galileo 2567 Signals: L1, E5A, E5B, E5A+B, E6 2569 Documentation Reference: Galileo Open Service Signal In Space 2570 Interface Control Document (SIS ICD) [Galileo.ICD] 2572 9.2. URN Sub-Namespace Registration for 2573 urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc 2575 This section registers a new XML namespace, 2576 "urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc", as per the guidelines 2577 in [RFC3688]. 2579 URI: urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc 2581 Registrant Contact: IETF, GEOPRIV working group, 2582 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2584 XML: 2586 BEGIN 2587 2588 2590 2591 2592 Measurement Source for PIDF-LO 2593 2594 2595

Namespace for Location Measurement Source

2596

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

2597 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2598 with the RFC number for this specification.]] 2599

See RFCXXXX.

2600 2601 2602 END 2604 9.3. URN Sub-Namespace Registration for 2605 urn:ietf:params:xml:ns:geopriv:lm 2607 This section registers a new XML namespace, 2608 "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in 2609 [RFC3688]. 2611 URI: urn:ietf:params:xml:ns:geopriv:lm 2613 Registrant Contact: IETF, GEOPRIV working group, 2614 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2616 XML: 2618 BEGIN 2619 2620 2622 2623 2624 Measurement Container 2625 2626 2627

Namespace for Location Measurement Container

2628

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

2629 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2630 with the RFC number for this specification.]] 2631

See RFCXXXX.

2632 2633 2635 END 2637 9.4. URN Sub-Namespace Registration for 2638 urn:ietf:params:xml:ns:geopriv:lm:basetypes 2640 This section registers a new XML namespace, 2641 "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines 2642 in [RFC3688]. 2644 URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes 2646 Registrant Contact: IETF, GEOPRIV working group, 2647 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2649 XML: 2651 BEGIN 2652 2653 2655 2656 2657 Base Device Types 2658 2659 2660

Namespace for Base Types

2661

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

2662 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2663 with the RFC number for this specification.]] 2664

See RFCXXXX.

2665 2666 2667 END 2669 9.5. URN Sub-Namespace Registration for 2670 urn:ietf:params:xml:ns:geopriv:lm:lldp 2672 This section registers a new XML namespace, 2673 "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in 2674 [RFC3688]. 2676 URI: urn:ietf:params:xml:ns:geopriv:lm:lldp 2678 Registrant Contact: IETF, GEOPRIV working group, 2679 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2681 XML: 2683 BEGIN 2684 2685 2687 2688 2689 LLDP Measurement Set 2690 2691 2692

Namespace for LLDP Measurement Set

2693

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

2694 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2695 with the RFC number for this specification.]] 2696

See RFCXXXX.

2697 2698 2699 END 2701 9.6. URN Sub-Namespace Registration for 2702 urn:ietf:params:xml:ns:geopriv:lm:dhcp 2704 This section registers a new XML namespace, 2705 "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in 2706 [RFC3688]. 2708 URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp 2710 Registrant Contact: IETF, GEOPRIV working group, 2711 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2713 XML: 2715 BEGIN 2716 2717 2719 2720 2721 DHCP Measurement Set 2722 2723 2724

Namespace for DHCP Measurement Set

2725

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

2726 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2727 with the RFC number for this specification.]] 2728

See RFCXXXX.

2729 2730 2732 END 2734 9.7. URN Sub-Namespace Registration for 2735 urn:ietf:params:xml:ns:geopriv:lm:wifi 2737 This section registers a new XML namespace, 2738 "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in 2739 [RFC3688]. 2741 URI: urn:ietf:params:xml:ns:geopriv:lm:wifi 2743 Registrant Contact: IETF, GEOPRIV working group, 2744 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2746 XML: 2748 BEGIN 2749 2750 2752 2753 2754 WiFi Measurement Set 2755 2756 2757

Namespace for WiFi Measurement Set

2758

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

2759 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2760 with the RFC number for this specification.]] 2761

See RFCXXXX.

2762 2763 2764 END 2766 9.8. URN Sub-Namespace Registration for 2767 urn:ietf:params:xml:ns:geopriv:lm:cell 2769 This section registers a new XML namespace, 2770 "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in 2771 [RFC3688]. 2773 URI: urn:ietf:params:xml:ns:geopriv:lm:cell 2775 Registrant Contact: IETF, GEOPRIV working group, 2776 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2778 XML: 2780 BEGIN 2781 2782 2784 2785 2786 Cellular Measurement Set 2787 2788 2789

Namespace for Cellular Measurement Set

2790

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

2791 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2792 with the RFC number for this specification.]] 2793

See RFCXXXX.

2794 2795 2796 END 2798 9.9. URN Sub-Namespace Registration for 2799 urn:ietf:params:xml:ns:geopriv:lm:gnss 2801 This section registers a new XML namespace, 2802 "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in 2803 [RFC3688]. 2805 URI: urn:ietf:params:xml:ns:geopriv:lm:gnss 2807 Registrant Contact: IETF, GEOPRIV working group, 2808 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2810 XML: 2812 BEGIN 2813 2814 2816 2817 2818 GNSS Measurement Set 2819 2820 2821

Namespace for GNSS Measurement Set

2822

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

2823 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2824 with the RFC number for this specification.]] 2825

See RFCXXXX.

2826 2827 2829 END 2831 9.10. URN Sub-Namespace Registration for 2832 urn:ietf:params:xml:ns:geopriv:lm:dsl 2834 This section registers a new XML namespace, 2835 "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in 2836 [RFC3688]. 2838 URI: urn:ietf:params:xml:ns:geopriv:lm:dsl 2840 Registrant Contact: IETF, GEOPRIV working group, 2841 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 2843 XML: 2845 BEGIN 2846 2847 2849 2850 2851 DSL Measurement Set 2852 2853 2854

Namespace for DSL Measurement Set

2855

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

2856 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2857 with the RFC number for this specification.]] 2858

See RFCXXXX.

2859 2860 2861 END 2863 9.11. XML Schema Registration for Measurement Source Schema 2865 This section registers an XML schema as per the guidelines in 2866 [RFC3688]. 2868 URI: urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc 2870 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2871 Martin Thomson (martin.thomson@andrew.com). 2873 Schema: The XML for this schema can be found in Section 6.2 of this 2874 document. 2876 9.12. XML Schema Registration for Measurement Container Schema 2878 This section registers an XML schema as per the guidelines in 2879 [RFC3688]. 2881 URI: urn:ietf:params:xml:schema:lm 2883 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2884 Martin Thomson (martin.thomson@andrew.com). 2886 Schema: The XML for this schema can be found in Section 6.1 of this 2887 document. 2889 9.13. XML Schema Registration for Base Types Schema 2891 This section registers an XML schema as per the guidelines in 2892 [RFC3688]. 2894 URI: urn:ietf:params:xml:schema:lm:basetypes 2896 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2897 Martin Thomson (martin.thomson@andrew.com). 2899 Schema: The XML for this schema can be found in Section 6.3 of this 2900 document. 2902 9.14. XML Schema Registration for LLDP Schema 2904 This section registers an XML schema as per the guidelines in 2905 [RFC3688]. 2907 URI: urn:ietf:params:xml:schema:lm:lldp 2909 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2910 Martin Thomson (martin.thomson@andrew.com). 2912 Schema: The XML for this schema can be found in Section 6.4 of this 2913 document. 2915 9.15. XML Schema Registration for DHCP Schema 2917 This section registers an XML schema as per the guidelines in 2918 [RFC3688]. 2920 URI: urn:ietf:params:xml:schema:lm:dhcp 2921 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2922 Martin Thomson (martin.thomson@andrew.com). 2924 Schema: The XML for this schema can be found in Section 6.5 of this 2925 document. 2927 9.16. XML Schema Registration for WiFi Schema 2929 This section registers an XML schema as per the guidelines in 2930 [RFC3688]. 2932 URI: urn:ietf:params:xml:schema:lm:wifi 2934 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2935 Martin Thomson (martin.thomson@andrew.com). 2937 Schema: The XML for this schema can be found in Section 6.6 of this 2938 document. 2940 9.17. XML Schema Registration for Cellular Schema 2942 This section registers an XML schema as per the guidelines in 2943 [RFC3688]. 2945 URI: urn:ietf:params:xml:schema:lm:cellular 2947 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2948 Martin Thomson (martin.thomson@andrew.com). 2950 Schema: The XML for this schema can be found in Section 6.7 of this 2951 document. 2953 9.18. XML Schema Registration for GNSS Schema 2955 This section registers an XML schema as per the guidelines in 2956 [RFC3688]. 2958 URI: urn:ietf:params:xml:schema:lm:gnss 2960 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2961 Martin Thomson (martin.thomson@andrew.com). 2963 Schema: The XML for this schema can be found in Section 6.8 of this 2964 document. 2966 9.19. XML Schema Registration for DSL Schema 2968 This section registers an XML schema as per the guidelines in 2969 [RFC3688]. 2971 URI: urn:ietf:params:xml:schema:lm:dsl 2973 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 2974 Martin Thomson (martin.thomson@andrew.com). 2976 Schema: The XML for this schema can be found in Section 6.9 of this 2977 document. 2979 10. Acknowledgements 2981 Thanks go to Simon Cox for his comments relating to terminology that 2982 have helped ensure that this document is aligns with ongoing work in 2983 the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his 2984 review and comments on the GNSS sections of this document. Thanks to 2985 Noor-E-Gagan Singh, Gabor Bajko and Russell Priebe for independent 2986 suggestions for improving the parameters associated with 802.11 2987 measurements. Thanks to Cullen Jennings for feedback and 2988 suggestions. Bernard Aboba provided review and feedback on a range 2989 of measurement data definitions. Mary Barnes provided a review and 2990 corrections. 2992 11. References 2994 11.1. Normative References 2996 [DSL.TR025] 2997 Wang, R., "Core Network Architecture Recommendations for 2998 Access to Legacy Data Networks over ADSL", September 1999. 3000 [DSL.TR101] 3001 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL 3002 Aggregation", April 2006. 3004 [GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface", 3005 ICD GPS-200, Apr 2000. 3007 [Galileo.ICD] 3008 GJU, "Galileo Open Service Signal In Space Interface 3009 Control Document (SIS ICD)", May 2006. 3011 [I-D.ietf-geopriv-http-location-delivery] 3012 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 3013 "HTTP Enabled Location Delivery (HELD)", 3014 draft-ietf-geopriv-http-location-delivery-16 (work in 3015 progress), August 2009. 3017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3018 Requirement Levels", BCP 14, RFC 2119, March 1997. 3020 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 3021 Format", RFC 4119, December 2005. 3023 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3024 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3025 May 2008. 3027 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 3028 Presence Information Data Format Location Object (PIDF-LO) 3029 Usage Clarification, Considerations, and Recommendations", 3030 RFC 5491, March 2009. 3032 11.2. Informative References 3034 [ANSI/TIA-1057] 3035 ANSI/TIA, "Link Layer Discovery Protocol for Media 3036 Endpoint Devices", TIA 1057, April 2006. 3038 [HARPER] Harper, N., Dawson, M., and D. Evans, "Server-side 3039 spoofing and detection for Assisted-GPS", Proceedings of 3040 International Global Navigation Satellite Systems Society 3041 (IGNSS) Symposium 2009 16, December 2009, 3042 . 3044 [I-D.ietf-geopriv-held-identity-extensions] 3045 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 3046 Barnes, "Use of Device Identity in HTTP-Enabled Location 3047 Delivery (HELD)", 3048 draft-ietf-geopriv-held-identity-extensions-04 (work in 3049 progress), June 2010. 3051 [I-D.thomson-geopriv-uncertainty] 3052 Thomson, M. and J. Winterbottom, "Representation of 3053 Uncertainty and Confidence in PIDF-LO", 3054 draft-thomson-geopriv-uncertainty-05 (work in progress), 3055 May 2010. 3057 [IANA.enterprise] 3058 IANA, "Private Enterprise Numbers", 3059 . 3061 [IEEE.80211V] 3062 IEEE, "Wireless LAN Medium Access Control (MAC) and 3063 Physical Layer (PHY) specifications - IEEE 802.11 Wireless 3064 Network Management (Draft)", P802.11v D12.0, June 2010. 3066 [IEEE.8021AB] 3067 IEEE, "IEEE Standard for Local and Metropolitan area 3068 networks, Station and Media Access Control Connectivity 3069 Discovery", 802.1AB, June 2005. 3071 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 3072 "Remote Authentication Dial In User Service (RADIUS)", 3073 RFC 2865, June 2000. 3075 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 3076 RFC 3046, January 2001. 3078 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3079 January 2004. 3081 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 3082 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 3084 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID 3085 Suboption for the Dynamic Host Configuration Protocol 3086 (DHCP) Relay Agent Option", RFC 3993, March 2005. 3088 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3089 Architecture", RFC 4291, February 2006. 3091 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 3092 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, 3093 June 2006. 3095 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 3096 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 3097 August 2006. 3099 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 3100 Mechanism", RFC 5808, May 2010. 3102 Authors' Addresses 3104 Martin Thomson 3105 Andrew 3106 Andrew Building (39) 3107 University of Wollongong 3108 Northfields Avenue 3109 Wollongong, NSW 2522 3110 AU 3112 Phone: +61 2 4221 2915 3113 Email: martin.thomson@andrew.com 3114 URI: http://www.andrew.com/ 3116 James Winterbottom 3117 Andrew 3118 Andrew Building (39) 3119 University of Wollongong 3120 Northfields Avenue 3121 NSW 2522 3122 AU 3124 Phone: +61 2 4221 2938 3125 Email: james.winterbottom@andrew.com 3126 URI: http://www.andrew.com/