idnits 2.17.1 draft-thomson-geopriv-held-measurements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2130. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2143. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 29, 2008) is 5658 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 1067, but not defined == Missing Reference: '0-4' is mentioned on line 1067, but not defined == Missing Reference: '0-9' is mentioned on line 1067, but not defined == Missing Reference: '0-1' is mentioned on line 1067, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-09 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 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: May 2, 2009 October 29, 2008 7 Using Device-provided Location-Related Measurements in Location 8 Configuration Protocols 9 draft-thomson-geopriv-held-measurements-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 2, 2009. 36 Abstract 38 A method is described by which a Device is able to provide location- 39 related measurement data to a LIS within a request for location 40 information. Location-related measurement information are 41 observations concerning properties related to the position of a 42 Device, which could be data about network attachment or about the 43 physical environment. When a LIS generates location information for 44 a Device, information from the Device can improve the accuracy of the 45 location estimate. A basic set of location-related measurements are 46 defined, including common modes of network attachment as well as 47 assisted Global Navigation Satellite System (GNSS) parameters. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Conventions used in this document . . . . . . . . . . . . . . 5 53 3. Location-Related Measurements in LCPs . . . . . . . . . . . . 6 54 3.1. Using Location-Releated Measurement Data . . . . . . . . . 6 55 4. Location-Related Measurement Data Types . . . . . . . . . . . 8 56 4.1. Common Location-Related Measurement Fields . . . . . . . . 8 57 4.1.1. Time of Measurement . . . . . . . . . . . . . . . . . 8 58 4.1.2. Expiry Time on Location-Related Measurement Data . . . 8 59 4.1.3. RMS Error and Number of Samples . . . . . . . . . . . 9 60 4.1.4. Time RMS Error . . . . . . . . . . . . . . . . . . . . 10 61 4.2. LLDP Measurements . . . . . . . . . . . . . . . . . . . . 10 62 4.3. DHCP Relay Agent Information Measurements . . . . . . . . 11 63 4.4. 802.11 WLAN Measurements . . . . . . . . . . . . . . . . . 11 64 4.5. Cellular Measurements . . . . . . . . . . . . . . . . . . 13 65 4.6. GNSS Measurements . . . . . . . . . . . . . . . . . . . . 16 66 4.6.1. GNSS System and Signal . . . . . . . . . . . . . . . . 17 67 4.6.2. Time . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 4.6.3. Per-Satellite Measurement Data . . . . . . . . . . . . 18 69 4.7. DSL Measurements . . . . . . . . . . . . . . . . . . . . . 19 70 4.7.1. L2TP Measurements . . . . . . . . . . . . . . . . . . 19 71 4.7.2. RADIUS Measurements . . . . . . . . . . . . . . . . . 20 72 4.7.3. Ethernet VLAN Tag Measurements . . . . . . . . . . . . 20 73 4.7.4. ATM Virtual Circuit Measurements . . . . . . . . . . . 21 74 5. Measurement Schemas . . . . . . . . . . . . . . . . . . . . . 22 75 5.1. Measurement Container Schema . . . . . . . . . . . . . . . 23 76 5.2. Base Type Schema . . . . . . . . . . . . . . . . . . . . . 24 77 5.3. LLDP Measurement Schema . . . . . . . . . . . . . . . . . 26 78 5.4. DHCP Measurement Schema . . . . . . . . . . . . . . . . . 27 79 5.5. WiFi Measurement Schema . . . . . . . . . . . . . . . . . 29 80 5.6. Cellular Measurement Schema . . . . . . . . . . . . . . . 30 81 5.7. GNSS Measurement Schema . . . . . . . . . . . . . . . . . 33 82 5.8. DSL Measurement Schema . . . . . . . . . . . . . . . . . . 34 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 86 7.1. IANA Registry for GNSS Types . . . . . . . . . . . . . . . 38 87 7.2. URN Sub-Namespace Registration for 88 urn:ietf:params:xml:ns:geopriv:lm . . . . . . . . . . . . 39 89 7.3. URN Sub-Namespace Registration for 90 urn:ietf:params:xml:ns:geopriv:lm:basetypes . . . . . . . 40 91 7.4. URN Sub-Namespace Registration for 92 urn:ietf:params:xml:ns:geopriv:lm:lldp . . . . . . . . . . 40 93 7.5. URN Sub-Namespace Registration for 94 urn:ietf:params:xml:ns:geopriv:lm:dhcp . . . . . . . . . . 41 95 7.6. URN Sub-Namespace Registration for 96 urn:ietf:params:xml:ns:geopriv:lm:wifi . . . . . . . . . . 42 97 7.7. URN Sub-Namespace Registration for 98 urn:ietf:params:xml:ns:geopriv:lm:cell . . . . . . . . . . 42 99 7.8. URN Sub-Namespace Registration for 100 urn:ietf:params:xml:ns:geopriv:lm:gnss . . . . . . . . . . 43 101 7.9. URN Sub-Namespace Registration for 102 urn:ietf:params:xml:ns:geopriv:lm:dsl . . . . . . . . . . 44 103 7.10. XML Schema Registration for Measurement Container 104 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 44 105 7.11. XML Schema Registration for Base Types Schema . . . . . . 45 106 7.12. XML Schema Registration for LLDP Schema . . . . . . . . . 45 107 7.13. XML Schema Registration for DHCP Schema . . . . . . . . . 45 108 7.14. XML Schema Registration for WiFi Schema . . . . . . . . . 45 109 7.15. XML Schema Registration for Cellular Schema . . . . . . . 46 110 7.16. XML Schema Registration for GNSS Schema . . . . . . . . . 46 111 7.17. XML Schema Registration for DSL Schema . . . . . . . . . . 46 112 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 114 9.1. Normative References . . . . . . . . . . . . . . . . . . . 48 115 9.2. Informative References . . . . . . . . . . . . . . . . . . 48 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 117 Intellectual Property and Copyright Statements . . . . . . . . . . 51 119 1. Introduction 121 A location configuration protocol (LCP) provides a means for a Device 122 to request information about its physical location from an access 123 network. A location information server (LIS) is the server that 124 provides location information; information that is available due to 125 the knowledge about the network and physical environment that is 126 available to the LIS. 128 As a part of the access network, the LIS is able to acquire 129 measurement results from network Devices within the network that are 130 related to Device location. The LIS also has access to information 131 about the network topology that can be used to turn measurement data 132 into location information. However, this information can be enhanced 133 with information acquired from the Device itself. 135 A Device is able to make observations about its network attachment, 136 or its physical environment. The location-related measurement data 137 might be unavailable to the LIS; alternatively, the LIS might be able 138 to acquire the data, but at a higher cost in time or otherwise. 139 Providing measurement data gives the LIS more options in determining 140 location, which could improve the quality of the service provided by 141 the LIS. Improvements in accuracy are one potential gain, but 142 improved response times and lower error rates are also possible. 144 This document describes a means for a Device to report location- 145 related measurement data to the LIS. Examples based on the HELD 146 [I-D.ietf-geopriv-http-location-delivery] location configuration 147 protocol are provided. 149 2. Conventions used in this document 151 The terms LIS and Device are used in this document in a manner 152 consistent with the usage in 153 [I-D.ietf-geopriv-http-location-delivery]. 155 This document also uses the following definitions: 157 Location Measurement: An observation about the physical properties 158 of a particular Device's network access. The result of a location 159 measurement--"location-related measurement data", or simply 160 "measurement data" given sufficient context--can be used to 161 determine the location of a Device. Location-related measurement 162 data does not identify a Device; measurement data can change with 163 time if the location of the Device also changes. 165 Location-related measurement data does not necessarily contain 166 location information directly, but it can be used in combination 167 with contextual knowledge of the network, or algorithms to derive 168 location information. Examples of location-related measurement 169 data are: radio signal strength or timing measurements, Ethernet 170 switch and port identifiers. 172 Location-related measurement data can be considered sighting 173 information, based on the definition in [RFC3693]. 175 Location Estimate: The result of location determination, a location 176 estimate is an approximation of where the Device is located. 177 Location estimates are subject to uncertainty, which arise from 178 errors in measurement results. 180 GNSS: Global Navigation Satellite System. A satellite-based system 181 that provides positioning and time information. For example, the 182 US Global Positioning System (GPS) or the European Galileo system. 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 3. Location-Related Measurements in LCPs 190 This document defines a standard container for the conveyance of 191 location-related measurement parameters in LCPs. This is an XML 192 container that identifies parameters by type and allows the Device to 193 provide the results of any measurement it is able to perform. A set 194 of measurement schemas are also defined that can be carried in the 195 generic container. 197 The simplest example of measurement data conveyance is illustrated by 198 the example message in Figure 1. This shows a HELD location request 199 message with an Ethernet switch and port measurement taken using LLDP 200 [IEEE.8021AB]. 202 203 civic 204 206 207 0a01003c 208 c2 209 210 211 213 Figure 1: HELD Location Request with Measurement Data 215 Location-related measurement data need not be provided exclusively by 216 Devices. Intermediaries involved in cooperative location 217 determination, such as a the second LIS in 218 [I-D.winterbottom-geopriv-lis2lis-req], might provide a LIS with 219 measurement data. 221 Measurement data that the LIS does not support or understand can be 222 ignored. The measurements defined in this document follow this rule; 223 extensions that could result in backward incompatibility MUST be 224 added as new measurement definitions rather than extensions to 225 existing types. 227 Multiple sets of measurement data, either of the same type or from 228 different sources can be included in the "measurements" element. See 229 Section 4.1.1 for details on repetition of this element. 231 3.1. Using Location-Releated Measurement Data 233 Using location-related measurement data is at the discretion of the 234 LIS, but the "method" parameter in the PIDF-LO SHOULD be adjusted to 235 reflect the method used. 237 Location-related measurement data provides an attack vector for 238 malicious Devices. If it is in the interest of the Device to induce 239 the LIS to provide false information about its location, measurement 240 data can be indirectly used to influence the result that the LIS 241 provides. This is particularly important where the LIS provides 242 certitude on the location information, either through digital 243 signature or simply by serving a location reference. 245 To prevent the propagation of indirectly falsified location 246 information, the LIS SHOULD validate location-related measurements. 247 The amount of verification might depend on the expected use of that 248 data. Any measurement data that is determined to be suspect is 249 discarded. 251 In one potential solution, the LIS validates any location information 252 that is derived from Device-provided measurement data. The resulting 253 location information is compared against location information that 254 the LIS is able to generate independently. If the two results differ 255 significantly, the measurement data is regarded as suspect and the 256 results derived from that are discarded. The allowable degree of 257 difference is left to local configuration or implementation. 259 Different degrees of trust can be assigned to location-related 260 measurement data based on the source of the data. Unauthenticated 261 Devices might be subjected to rigorous checking before being 262 accepted, if the data is accepted at all. Conversely, measurement 263 data from trusted intermediaries might not be validated at all. 265 Given that the output of location determination is probabilistic, it 266 could be that accepting a finite probability of falsified measurement 267 data is acceptable. A decision on how much risk is accepted is left 268 to local policy. 270 If absolute certitude of the resulting location information is 271 required, then the LIS MUST NOT use unverified information. In this 272 case, Device-provided measurement data is only of benefit if 273 verification of that data is more efficient than collection. 275 4. Location-Related Measurement Data Types 277 This document defines location-related measurement data types for a 278 range of common network types. 280 4.1. Common Location-Related Measurement Fields 282 This section describes metadata that is common to a wide range of 283 measurement data. Time of measurement and expiry time apply to all 284 measurements; RMS error and number of samples apply to selected 285 measurement types. 287 4.1.1. Time of Measurement 289 The "time" attribute records the time that the measurement or 290 observation was made. This time can be different to the time that 291 the measurement information was reported. Time information can be 292 used to populate a timestamp on the location result, or to determine 293 if the measurement information is used. 295 The "time" attribute is optional to avoid forcing an arbitrary choice 296 of timestamp for relatively static types of measurement (for 297 instance, the DSL measurements in Section 4.7) and for legacy Devices 298 that don't record time information (such as the Home Location 299 Register/Home Subscriber Server for cellular). However, time SHOULD 300 be provided whenever possible. 302 The "time" attribute is attached to the root "measurement" element. 303 If it is necessary to provide multiple sets of measurement data with 304 different times, multiple "measurement" elements SHOULD be provided. 306 4.1.2. Expiry Time on Location-Related Measurement Data 308 A Device is able to indicate an expiry time in the location 309 measurement using the "expires" attribute. Nominally, this attribute 310 indicates how long information is expected to be valid for, but it 311 can also indicate a time limit on the retention and use of the 312 measurement data. A Device can use this attribute to prevent the LIS 313 from retaining measurement data or limit the time that a LIS retains 314 this information. 316 Note: Movement of a Device might result in the measurement data 317 being invalidated before the expiry time. 319 The LIS MUST NOT keep location-related measurement data beyond the 320 time indicated in the "expires" attribute. Where the "expires" 321 attribute is not provided, the LIS MUST only use the location-related 322 measurement data in serving the request that contained the data. 324 Figure 2 shows an example of a measurement that includes an expiry 325 attribute. 327 330 331 332 wlan-home 333 00-12-F0-A0-80-EF 334 335 336 338 Figure 2: Expiry Time Example 340 4.1.3. RMS Error and Number of Samples 342 Often a measurement is taken more than once over a period of time. 343 Reporting the average of a number of measurement results mitigates 344 the effects of random errors that occur in the measurement process. 345 Typically, a mean value is reported at the end of the measurement 346 interval, but additional information about the distribution of the 347 results can be useful in determining location uncertainty. 349 Two optional attributes are provided for certain measurement values: 351 rmsError: The root-mean-squared (RMS) error of the set of 352 measurement values used in calculating the result. RMS error is 353 expressed in the same units as the measurement, unless otherwise 354 stated. If an accurate value for RMS error is not known, this 355 value can be used to indicate an upper bound for the RMS error. 357 samples: The number of samples that were taken in determining the 358 measurement value. If omitted, this value can be assumed to be a 359 very large value, so that the RMS error is an indication of the 360 standard deviation of the sample set. 362 For some measurement techniques, measurement error is determined for 363 the specific measurement technique. In these cases, measurement 364 error is largely a product of the measurement technique and not the 365 specific circumstances, so RMS error does not need to be actively 366 measured. A fixed value MAY be provided for RMS error where 367 appropriate. 369 4.1.4. Time RMS Error 371 Measurement of time can be significant in certain circumstances. The 372 GNSS measurements included in this document are one such case where a 373 small error in time can result in a large error in location. Factors 374 such as clock drift and errors in time sychronization can result in 375 small, but significant, time errors. Including an indication of the 376 quality of the time can be helpful. 378 An optional "timeError" attribute can be added to the "measurement" 379 element to indicate the RMS error in time. "timeError" indicates an 380 upper bound on the time RMS error in seconds. 382 The "timeError" attribute does not apply where multiple samples of a 383 measurement is taken over time. If multiple samples are taken, each 384 SHOULD be included in a different "measurement" element. 386 4.2. LLDP Measurements 388 LLDP messages are sent between adjacent nodes in an IEEE 802 network 389 (e.g. wired Ethernet, WiFi, 802.16). These messages all contain 390 identification information for the sending node, which can be used to 391 determine location information. A Device that receives LLDP messages 392 can report this information as a location-related measurement to the 393 LIS, which is then able to use the measurement data in determining 394 the location of the Device. 396 The Device MUST report the values directly as they were provided by 397 the adjacent node. Attempting to adjust or translate the type of 398 identifier is likely to cause the measurement data to be useless. 400 Where a Device has received LLDP messages from multiple adjacent 401 nodes, it should provide information extracted from those messages by 402 repeating the "lldp" element. 404 An example of an LLDP measurement is shown in Figure 3. This shows 405 an adjacent node (chassis) that is identified by the IP address 406 192.0.2.45 (hexadecimal c000022d) and the port on that node is 407 numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2). 409 411 412 c000022d 413 a2 414 415 416 Figure 3: LLDP Measurement Example 418 IEEE 802 Devices that are able to obtain information about adjacent 419 network switches and their attachment to them by other means MAY use 420 this data type to convey this information. 422 4.3. DHCP Relay Agent Information Measurements 424 The DHCP Relay Agent Information option [RFC3046] provides 425 measurement data about the network attachment of a Device. This 426 measurement data can be included in the "dhcp-rai" element. 428 The elements in the DHCP relay agent information options are opaque 429 data types assigned by the DHCP relay agent. The three items are all 430 optional: circuit identifier ("circuit", [RFC3046]), remote 431 identifier ("remote", [RFC3046], [RFC4649]) and subscriber identifier 432 ("subscriber", [RFC3993], [RFC4580]). The DHCPv6 remote identifier 433 has an associated enterprise number [IANA.enterprise] as an XML 434 attribute. 436 438 439 ::ffff:192.0.2.158 440 108b 441 442 444 Figure 4: DHCP Relay Agent Information Measurement Example 446 The "giaddr" is specified as a dotted quad IPv4 address or an RFC 447 4291 [RFC4291] IPv6 address. The enterprise number is specified as a 448 decimal integer. All other information is included verbatim from the 449 DHCP request in hexadecimal format. 451 4.4. 802.11 WLAN Measurements 453 In WiFi, or 802.11, networks a Device might be able to provide 454 information about the wireless access point (WAP) that it is attached 455 to, or other WiFi points it is able to see. This is provided using 456 the "wifi" element, as shown in Figure 5. 458 460 461 Intel(r)PRO/Wireless 2200BG 462 463 wlan-home 464 00-12-F0-A0-80-EF 465 95 466 467 468 wlan-home 469 00-12-F0-A0-80-F0 470 15 471 472 473 wlan-home 474 00-12-F0-A0-80-F1 475 12 476 477 478 wlan-home 479 00-12-F0-A0-80-F2 480 5 481 482 483 485 Figure 5: 802.11 WLAN Measurement Example 487 A wifi element is made up of a serving WAP, zero or more neighbouring 488 WAPs, and an optional "nicType" element. Each WAP element is 489 comprised of the following fields: 491 ssid: The service set identifier for the wireless network. This 492 parameter must be provided. 494 bssid: The basic service set identifier. This is the 48 bit 495 Ethernet MAC address of the wireless access point and it must be 496 provided. 498 wapname: The broadcast name for the wireless access point. This 499 element is optional. 501 rssi: The received signal strength indicator of the WAP as seen by 502 the wireless receiver. This value SHOULD be in units of dBm (with 503 RMS error in dB). If the units are unknown, the "dBm" attribute 504 MUST be set to "false". Signal strength reporting on current 505 hardware uses a range of different units; therefore, the value of 506 the "nicType" element SHOULD be included if the units are not 507 known to be in dBm and the value reported by the hardware should 508 be included without modification. This element is optional and 509 includes optional "rmsError" and "samples" attributes. 511 The "nicType" element is used to specify the make and model of the 512 wireless network interface in the Device. Different 802.11 chipsets 513 report the signal strength in different ways, so the nic type must be 514 specified in order for the LIS to use signal strength indicators as 515 part of its location determination process. The content of this 516 field is unconstrained and no mechanisms are specified to ensure 517 uniqueness. 519 4.5. Cellular Measurements 521 Cellular Devices are common throughout the world and base station 522 identifiers can provide a good source of coarse location information. 523 This information can be provided to a LIS run by the cellar operator, 524 or may be provided to an alternative LIS operator that has access to 525 one of several global cell-id to location mapping databases. 527 The cellular measurement set allows a Device to report to a LIS any 528 LTE (Figure 6), UMTS (Figure 7), GSM (Figure 8) or CDMA (Figure 9) 529 cells that it is able to hear. Cells are reported using their global 530 identifiers. All 3GPP cells are identified by public land mobile 531 network (PLMN), which is formed of mobile country code (MCC) and 532 mobile network code (MNC); specific fields are added for each network 533 type. All other values are decimal integers. 535 537 538 539 46520 540 123465000 541 542 543 46506 544 1638332767 545 546 547 549 Long term evolution (LTE) cells are identified by group id (gid) and 550 cell broadcast id (cbid), or by closed subscription group (csg) and 551 local cell id (lcid). 553 Figure 6: Example LTE Cellular Measurement 555 557 558 559 46520 560 200065000 561 562 563 46506 564 1638332767 565 566 567 569 Universal mobile telephony service (UMTS) cells are identified by 570 radio network controller (rnc) and cell id (cid). 572 Figure 7: Example UMTS Cellular Measurement 574 576 577 578 46506 579 1638332767 580 581 582 584 Groupe Spe'ciale Mobile (GSM) cells are identified by local radio 585 network controller (rnc) and cell id (cid). 587 Figure 8: Example GSM Cellular Measurement 589 591 592 593 47231589212 594 595 596 47231589213 597 598 599 601 Code division multiple access (CDMA) cells are not identified by 602 PLMN, network id (nid), system id (sid) and base station id (baseid). 604 Figure 9: Example CDMA Cellular Measurement 606 In general a cellular Device will be attached to the cellular network 607 and so the notion of a serving cell exists. Cellular network also 608 provide overlap between neighbouring sites, so a mobile Device can 609 hear more than one cell. The measurement schema supports sending 610 both the serving cell and any other cells that the mobile might be 611 able to hear. In some cases, the Device may simply be listening to 612 cell information without actually attaching to the network, mobiles 613 without a SIM are an example of this. In this case the Device may 614 simply report cells it can hear without flagging one as a serving 615 cell. An example of this is shown in Figure 10. 617 619 620 621 46520 622 200065000 623 624 625 46506 626 1638332767 627 628 629 631 Figure 10: Example Observed Cellular Measurement 633 4.6. GNSS Measurements 635 GNSS use orbiting satellites to transmit signals. A Device with a 636 GNSS receiver is able to take measurements from the satellite 637 signals. The results of these measurements can be used to determine 638 time and the location of the Device. 640 Determining location and time in autonomous GNSS receivers follows 641 three steps: 643 Signal acquisition: During the signal acquisition stage, the 644 receiver searches for the repeating code that is sent by each GNSS 645 satellite. Successful operation typically requires measurement 646 data for a minimum of 5 satellites. At this stage, measurement 647 data is available to the Device. 649 Navigation message decode: Once the signal has been acquired, the 650 receiver then receives information about the configuration of the 651 satellite constellation. This information is broadcast by each 652 satellite and is modulated with the base signal at a low rate; for 653 instance, GPS sends this information at about 50 bits per second. 655 Calculation: The measurement data is combined with the data on the 656 satellite constellation to determine the location of the receiver 657 and the current time. 659 A Device that uses a GNSS receiver is able to report measurements 660 after the first stage of this process. A LIS can use the results of 661 these measurements to determine a location. In the case where there 662 are fewer results available than the optimal minimum, the LIS might 663 be able to use other sources of measurement information and combine 664 these with the available measurement data to determine a position. 666 Note: The use of different sets of GNSS _assistance data_ can 667 reduce the amount of time required for the signal acquisition 668 stage and obviate the need for the receiver to extract data on the 669 satellite constellation. Provision of assistance data is outside 670 the scope of this document. 672 Figure 11 shows an example of GNSS measurement data. The measurement 673 shown is for the GPS system and includes measurement data for three 674 satellites only. 676 678 680 681 499.9395 682 0.87595747 683 45 684 685 686 378.2657 687 0.56639479 688 52 689 690 691 -633.0309 692 0.57016835 693 48 694 695 696 698 Figure 11: Example GNSS Measurement 700 Each "gnss" element represents a single set of GNSS measurement data, 701 taken at a single point in time. Measurements taken at different 702 times can be included in different "gnss" elements to enable 703 iterative refinement of results. 705 GNSS measurement parameters are described in more detail in the 706 following sections. 708 4.6.1. GNSS System and Signal 710 The GNSS measurement structure is designed to be generic and to apply 711 to different GNSS types. Different signals within those systems are 712 also accounted for and can be measured separately. 714 The GNSS type determines the time system that is used. An indication 715 of the type of system and signal can ensure that the LIS is able to 716 correctly use measurements. 718 Measurements for multiple GNSS types and signals can be included by 719 repeating the "gnss" element. 721 This document creates an IANA registry for GNSS types. Two satellite 722 systems are registered by this document: GPS and Galileo. Details 723 for the registry are included in Section 7.1. 725 4.6.2. Time 727 Each set of GNSS measurements is taken at a specific point in time. 728 The "time" attribute is used to indicate the time that the 729 measurement was acquired, if the receiver knows how the time system 730 used by the GNSS relates to UTC time. 732 Alternative to (or in addition to) the measurement time, the 733 "gnssTime" element MAY be included. The "gnssTime" element includes 734 a relative time in milliseconds using the time system native to the 735 satellite system. For the GPS satellite system, the "gnssTime" 736 element includes the time of week in milliseconds. For the Galileo 737 system, the "gnssTime" element includes the time of day in 738 milliseconds. 740 The accuracy of the time measurement provided is critical in 741 determining the accuracy of the location information derived from 742 GNSS measurements. The receiver SHOULD indicate an estimated time 743 error for any time that is provided. An RMS error can be included 744 for the "gnssTime" element, with a value in milliseconds. 746 4.6.3. Per-Satellite Measurement Data 748 Multiple satellites are included in each set of GNSS measurements 749 using the "sat" element. Each satellite is identified by a number in 750 the "num" attribute. The satellite number is consistent with the 751 identifier used in the given GNSS. 753 Both the GPS and Galileo systems use satellite numbers between 1 and 754 64. 756 The GNSS receiver measures the following parameters for each 757 satellite: 759 doppler: The observed Doppler shift of the satellite signal, 760 measured in metres per second. This is converted from a value in 761 Hertz. 763 codephase: The observed code phase for the satellite signal, 764 measured in milliseconds. This is converted from a value in chips 765 or wavelengths. Increasing values indicate increasing 766 pseudoranges. This value includes an optional RMS error 767 attribute, also measured in milliseconds. 769 cn0: The signal to noise ratio for the satellite signal, measured in 770 decibel-Hertz (dB-Hz). The expected range is between 20 and 50 771 dB-Hz. 773 mp: An estimation of the amount of error that multipath signals 774 contribute in metres. This parameter is optional. 776 cq: An indication of the carrier quality. Two attributes are 777 included: "continuous" may be either "true" or "false"; direct may 778 be either "direct" or "inverted". This parameter is optional. 780 adr: The accumulated Doppler range, measured in metres. This 781 parameter is optional and is not necessary unless multiple sets of 782 GNSS measurements are provided. 784 All values are converted from measures native to the satellite system 785 to generic measures to ensure consistency of interpretation. Unless 786 necessary, the schema does not constrain these values. 788 4.7. DSL Measurements 790 Digital Subscriber Line (DSL) networks rely on a range of network 791 technology. DSL deployments regularly require cooperation between 792 multiple organizations. These fall into two broad categories: 793 infrastructure providers and Internet service providers (ISPs). 794 Infrastructure providers manage the bulk of the physical 795 infrastructure including cabling. End users obtain their service 796 from an ISP, which manages all aspects visible to the end user 797 including IP address allocation and operation of a LIS. See 798 [DSL.TR025] and [DSL.TR101] for further information on DSL network 799 deployments. 801 Exchange of measurement information between these organizations is 802 necessary for location information to be correctly generated. The 803 ISP LIS needs to acquire location information from the infrastructure 804 provider. However, the infrastructure provider has no knowledge of 805 Device identifiers, it can only identify a stream of data that is 806 sent to the ISP. This is resolved by passing measurement data 807 relating to the Device to a LIS operated by the infrastructure 808 provider. 810 4.7.1. L2TP Measurements 812 Layer 2 Tunneling Protocol (L2TP) is a common means of linking the 813 infrastructure provider and the ISP. The infrastructure provider LIS 814 requires measurement data that identifies a single L2TP tunnel, from 815 which it can generate location information. Figure 12 shows an 816 example L2TP measurement. 818 820 821 822 192.0.2.10 823 192.0.2.61 824 528 825 826 827 829 Figure 12: Example DSL L2TP Measurement 831 4.7.2. RADIUS Measurements 833 When authenticating network access, the infrastructure provider might 834 employ a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or 835 Access Node (AN). These messages provide the ISP RADIUS server with 836 an identifier for the DSLAM or AN, plus the slot and port that the 837 Device is attached on. These data can be provided as a measurement, 838 which allows the infrastructure provider LIS to generate location 839 information. 841 The format of the AN, slot and port identifiers are not defined in 842 the RADIUS protocol. Slot and port together identify a circuit on 843 the AN, analogous to the circuit identifier in [RFC3046]. These 844 items are provided directly, as they were in the RADIUS message. An 845 example is shown in Figure 13. 847 849 850 AN-7692 851 3 852 06 853 854 856 Figure 13: Example DSL RADIUS Measurement 858 4.7.3. Ethernet VLAN Tag Measurements 860 For Ethernet-based DSL access networks, the DSL Access Module (DSLAM) 861 or Access Node (AN) provide two VLAN tags on packets. A C-TAG is 862 used to identify the incoming residential circuit, while the S-TAG is 863 used to identify the DSLAM or AN. The C-TAG and S-TAG together can 864 be used to identify a single point of network attachment. An example 865 is shown in Figure 14. 867 869 870 613 871 1097 872 873 875 Figure 14: Example DSL VLAN Tag Measurement 877 Alternatively, the C-TAG can be replaced by data on the slot and port 878 that the Device is attached to. This information might be included 879 in RADIUS requests that are proxied from the infrastructure provider 880 to the ISP RADIUS server. 882 4.7.4. ATM Virtual Circuit Measurements 884 An ATM virtual circuit can be employed between the ISP and 885 infrastructure provider. Providing the virtual port ID (VPI) and 886 virtual circuit ID (VCI) for the virtual circuit gives the 887 infrastructure provider LIS the ability to identify a single data 888 stream. A sample measurement is shown in Figure 15. 890 892 893 55 894 6323 895 896 898 Figure 15: Example DSL ATM Measurement 900 5. Measurement Schemas 902 The schema are broken up into their relative functions. There is a 903 base container schema into which all measurements are placed. There 904 is a basic types schema, that contains various base type definitions 905 for things such as the "rmsError" and "samples" attributes IPv4, IPv6 906 and MAC addresses. Then each of the specific measurement types is 907 defined in its own schema. 909 5.1. Measurement Container Schema 911 912 919 920 922 923 924 926 This schema defines a framework for location measurements. 927 928 930 932 933 934 935 936 937 939 940 941 942 943 944 945 946 947 949 951 Measurement Containment Schema 953 5.2. Base Type Schema 955 Note that the pattern rules in the following schema wrap due to 956 length constraints. None of the patterns contain whitespace. 958 959 966 967 969 970 971 973 This schema defines a set of base type elements. 974 975 977 978 979 980 981 982 983 984 985 986 987 988 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1016 1017 1018 1020 1021 1022 1023 1024 An IP version 6 address, based on RFC 4291. 1025 1026 1027 1028 1029 1030 1031 1032 1033 1035 1037 1039 1041 1043 1045 1046 1047 1048 1056 1057 1058 1059 1061 1062 1063 1064 1068 1069 1071 1073 1074 1075 1076 1077 1079 1081 Base Type Schema 1083 5.3. LLDP Measurement Schema 1085 1086 1094 1095 1097 1098 1099 1101 This schema defines a set of LLDP location measurements. 1102 1103 1105 1107 1108 1109 1110 1111 1112 1113 1114 1116 1117 1118 1119 1120 1122 1123 1124 1125 1127 1128 1129 1131 1132 1133 1134 1135 1136 1138 1140 LLDP measurement schema 1142 5.4. DHCP Measurement Schema 1143 1144 1152 1153 1155 1156 1157 1159 This schema defines a set of DHCP location measurements. 1160 1161 1163 1165 1166 1167 1168 1169 1170 1171 1172 1174 1176 1178 1180 1181 1182 1183 1184 1186 1187 1188 1189 1192 1193 1194 1196 1198 DHCP measurement schema 1200 5.5. WiFi Measurement Schema 1202 1203 1211 1212 1214 WiFi location measurements 1215 1216 1217 1219 This schema defines a basic set of WiFi location measurements. 1220 1221 1223 1225 1227 1228 1229 1230 1231 1233 1234 1235 1236 1237 1239 1240 1241 1242 1243 1245 1246 1247 1248 1249 1250 1251 1253 1255 1257 1258 1259 1260 1261 1263 1264 1265 1266 1267 1269 1270 1271 1272 1273 1274 1275 1277 1279 WiFi measurement schema 1281 5.6. Cellular Measurement Schema 1283 1284 1291 1292 1294 1295 1296 1298 This schema defines a set of cellular location measurements. 1299 1300 1302 1304 1305 1306 1307 1308 1309 1310 1311 1312 1314 1315 1316 1317 1318 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1346 1347 1348 1349 1350 1351 1353 1354 1356 1357 1358 1359 1361 1362 1363 1364 1365 1367 1368 1369 1370 1371 1373 1374 1375 1376 1377 1379 1381 Cellular measurement schema 1383 5.7. GNSS Measurement Schema 1384 1385 1393 1394 1396 1397 1398 1400 This schema defines a set of GNSS location measurements 1401 1402 1404 1406 1407 1408 1409 1410 1411 1412 1414 1415 1416 1417 1418 1420 1422 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1440 1442 1443 1444 1446 1447 1448 1450 1451 1452 1453 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1468 GNSS measurement Schema 1470 5.8. DSL Measurement Schema 1472 1473 1481 1482 1484 DSL measurement definitions 1485 1486 1487 1489 This schema defines a basic set of DSL location measurements. 1490 1491 1493 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1528 1529 1530 1531 1532 1533 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1552 1554 DSL measurement schema 1556 6. Security Considerations 1558 Location-related measurement data are provided by the Device for the 1559 sole purpose of generating more accurate location information. The 1560 LIS SHOULD NOT retain location-related measurement data for any 1561 longer than is necessary to generate location information. 1563 A LIS MUST NOT reveal location-related measurement data to any other 1564 entity unless given explicit permission by the Device. This document 1565 does not include any means to indicate such permission. 1567 A Device is able to explicitly limit the time that a LIS stores 1568 measurement data by adding an expiry time to the measurement data, 1569 see Section 4.1.2. 1571 Use of measurement data provides an opportunity for a malicious 1572 Device to include falsified information in the hopes of causing the 1573 LIS to provide a fake, or spoofed, location. If any degree of 1574 certitude is assigned to the location provided by the LIS--above that 1575 assigned to location provided by the device--the LIS SHOULD verify 1576 that the measurement data is correct. Section 3.1 discusses the 1577 risks and limitations involved in the use of measurement data. 1579 7. IANA Considerations 1581 This section creates a registry for GNSS types (Section 4.6) and 1582 registers the schema from Section 5. 1584 7.1. IANA Registry for GNSS Types 1586 This document establishes a new IANA registry for Global Navigation 1587 Satellite System (GNSS) types. The registry includes tokens for the 1588 GNSS type and for each of the signals within that type. Referring to 1589 [RFC2434], this registry operates under both "Expert Review" and 1590 "Specification Required" rules. The IESG will appoint an Expert 1591 Reviewer who will advise IANA promptly on each request for a new or 1592 updated GNSS type. 1594 Each entry in the registry requires the following information: 1596 GNSS name: the name and a brief description of the GNSS 1598 Brief description: the name and a brief description of the GNSS 1600 GNSS token: a token that can be used to identify the GNSS 1602 Signals: a set of tokens that represent each of the signals that the 1603 system provides 1605 Documentation reference: a reference to one or more stable, public 1606 specifications that outline usage of the GNSS, including (but not 1607 limited to) signal specifications and time systems 1609 The registry initially includes two registrations: 1611 GNSS name: Global Positioning System (GPS) 1613 Brief description: a system of satellites that use spread-spectrum 1614 transmission, operated by the US military for commercial and 1615 military applications 1617 GNSS token: gps 1619 Signals: L1, L2, L1C, L2C, L5 1621 Documentation reference: Navstar GPS Space Segment/Navigation User 1622 Interface [GPS.ICD] 1624 GNSS name: Galileo 1626 Brief description: a system of satellites that operate in the same 1627 spectrum as GPS, operated by the European Union for commercial 1628 applications 1630 GNSS Token: galileo 1632 Signals: L1, E5A, E5B, E5A+B, E6 1634 Documentation Reference: Galileo Open Service Signal In Space 1635 Interface Control Document (SIS ICD) [Galileo.ICD] 1637 7.2. URN Sub-Namespace Registration for 1638 urn:ietf:params:xml:ns:geopriv:lm 1640 This section registers a new XML namespace, 1641 "urn:ietf:params:xml:ns:geopriv:lm", as per the guidelines in 1642 [RFC3688]. 1644 URI: urn:ietf:params:xml:ns:geopriv:lm 1646 Registrant Contact: IETF, GEOPRIV working group, 1647 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 1649 XML: 1651 BEGIN 1652 1653 1655 1656 1657 Measurement Container 1658 1659 1660

Namespace for Location Measurement Container

1661

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

1662 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1663 with the RFC number for this specification.]] 1664

See RFCXXXX.

1665 1666 1667 END 1669 7.3. URN Sub-Namespace Registration for 1670 urn:ietf:params:xml:ns:geopriv:lm:basetypes 1672 This section registers a new XML namespace, 1673 "urn:ietf:params:xml:ns:geopriv:lm:basetypes", as per the guidelines 1674 in [RFC3688]. 1676 URI: urn:ietf:params:xml:ns:geopriv:lm:basetypes 1678 Registrant Contact: IETF, GEOPRIV working group, 1679 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 1681 XML: 1683 BEGIN 1684 1685 1687 1688 1689 Base Device Types 1690 1691 1692

Namespace for Base Types

1693

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

1694 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1695 with the RFC number for this specification.]] 1696

See RFCXXXX.

1697 1698 1699 END 1701 7.4. URN Sub-Namespace Registration for 1702 urn:ietf:params:xml:ns:geopriv:lm:lldp 1704 This section registers a new XML namespace, 1705 "urn:ietf:params:xml:ns:geopriv:lm:lldp", as per the guidelines in 1706 [RFC3688]. 1708 URI: urn:ietf:params:xml:ns:geopriv:lm:lldp 1710 Registrant Contact: IETF, GEOPRIV working group, 1711 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 1713 XML: 1715 BEGIN 1716 1717 1719 1720 1721 LLDP Measurement Set 1722 1723 1724

Namespace for LLDP Measurement Set

1725

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

1726 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1727 with the RFC number for this specification.]] 1728

See RFCXXXX.

1729 1730 1731 END 1733 7.5. URN Sub-Namespace Registration for 1734 urn:ietf:params:xml:ns:geopriv:lm:dhcp 1736 This section registers a new XML namespace, 1737 "urn:ietf:params:xml:ns:geopriv:lm:dhcp", as per the guidelines in 1738 [RFC3688]. 1740 URI: urn:ietf:params:xml:ns:geopriv:lm:dhcp 1742 Registrant Contact: IETF, GEOPRIV working group, 1743 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 1745 XML: 1747 BEGIN 1748 1749 1751 1752 1753 DHCP Measurement Set 1754 1755 1756

Namespace for DHCP Measurement Set

1757

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

1758 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1759 with the RFC number for this specification.]] 1760

See RFCXXXX.

1761 1762 1764 END 1766 7.6. URN Sub-Namespace Registration for 1767 urn:ietf:params:xml:ns:geopriv:lm:wifi 1769 This section registers a new XML namespace, 1770 "urn:ietf:params:xml:ns:geopriv:lm:wifi", as per the guidelines in 1771 [RFC3688]. 1773 URI: urn:ietf:params:xml:ns:geopriv:lm:wifi 1775 Registrant Contact: IETF, GEOPRIV working group, 1776 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 1778 XML: 1780 BEGIN 1781 1782 1784 1785 1786 WiFi Measurement Set 1787 1788 1789

Namespace for WiFi Measurement Set

1790

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

1791 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1792 with the RFC number for this specification.]] 1793

See RFCXXXX.

1794 1795 1796 END 1798 7.7. URN Sub-Namespace Registration for 1799 urn:ietf:params:xml:ns:geopriv:lm:cell 1801 This section registers a new XML namespace, 1802 "urn:ietf:params:xml:ns:geopriv:lm:cell", as per the guidelines in 1803 [RFC3688]. 1805 URI: urn:ietf:params:xml:ns:geopriv:lm:cell 1807 Registrant Contact: IETF, GEOPRIV working group, 1808 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 1810 XML: 1812 BEGIN 1813 1814 1816 1817 1818 Cellular Measurement Set 1819 1820 1821

Namespace for Cellular Measurement Set

1822

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

1823 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1824 with the RFC number for this specification.]] 1825

See RFCXXXX.

1826 1827 1828 END 1830 7.8. URN Sub-Namespace Registration for 1831 urn:ietf:params:xml:ns:geopriv:lm:gnss 1833 This section registers a new XML namespace, 1834 "urn:ietf:params:xml:ns:geopriv:lm:gnss", as per the guidelines in 1835 [RFC3688]. 1837 URI: urn:ietf:params:xml:ns:geopriv:lm:gnss 1839 Registrant Contact: IETF, GEOPRIV working group, 1840 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 1842 XML: 1844 BEGIN 1845 1846 1848 1849 1850 GNSS Measurement Set 1851 1852 1853

Namespace for GNSS Measurement Set

1854

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

1855 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1856 with the RFC number for this specification.]] 1857

See RFCXXXX.

1858 1859 1861 END 1863 7.9. URN Sub-Namespace Registration for 1864 urn:ietf:params:xml:ns:geopriv:lm:dsl 1866 This section registers a new XML namespace, 1867 "urn:ietf:params:xml:ns:geopriv:lm:dsl", as per the guidelines in 1868 [RFC3688]. 1870 URI: urn:ietf:params:xml:ns:geopriv:lm:dsl 1872 Registrant Contact: IETF, GEOPRIV working group, 1873 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 1875 XML: 1877 BEGIN 1878 1879 1881 1882 1883 DSL Measurement Set 1884 1885 1886

Namespace for DSL Measurement Set

1887

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

1888 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 1889 with the RFC number for this specification.]] 1890

See RFCXXXX.

1891 1892 1893 END 1895 7.10. XML Schema Registration for Measurement Container Schema 1897 This section registers an XML schema as per the guidelines in 1898 [RFC3688]. 1900 URI: urn:ietf:params:xml:schema:lm 1902 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1903 Martin Thomson (martin.thomson@andrew.com). 1905 Schema: The XML for this schema can be found in Section 5.1 of this 1906 document. 1908 7.11. XML Schema Registration for Base Types Schema 1910 This section registers an XML schema as per the guidelines in 1911 [RFC3688]. 1913 URI: urn:ietf:params:xml:schema:lm:basetypes 1915 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1916 Martin Thomson (martin.thomson@andrew.com). 1918 Schema: The XML for this schema can be found in Section 5.2 of this 1919 document. 1921 7.12. XML Schema Registration for LLDP Schema 1923 This section registers an XML schema as per the guidelines in 1924 [RFC3688]. 1926 URI: urn:ietf:params:xml:schema:lm:lldp 1928 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1929 Martin Thomson (martin.thomson@andrew.com). 1931 Schema: The XML for this schema can be found in Section 5.3 of this 1932 document. 1934 7.13. XML Schema Registration for DHCP Schema 1936 This section registers an XML schema as per the guidelines in 1937 [RFC3688]. 1939 URI: urn:ietf:params:xml:schema:lm:dhcp 1941 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1942 Martin Thomson (martin.thomson@andrew.com). 1944 Schema: The XML for this schema can be found in Section 5.4 of this 1945 document. 1947 7.14. XML Schema Registration for WiFi Schema 1949 This section registers an XML schema as per the guidelines in 1950 [RFC3688]. 1952 URI: urn:ietf:params:xml:schema:lm:wifi 1953 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1954 Martin Thomson (martin.thomson@andrew.com). 1956 Schema: The XML for this schema can be found in Section 5.5 of this 1957 document. 1959 7.15. XML Schema Registration for Cellular Schema 1961 This section registers an XML schema as per the guidelines in 1962 [RFC3688]. 1964 URI: urn:ietf:params:xml:schema:lm:cellular 1966 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1967 Martin Thomson (martin.thomson@andrew.com). 1969 Schema: The XML for this schema can be found in Section 5.6 of this 1970 document. 1972 7.16. XML Schema Registration for GNSS Schema 1974 This section registers an XML schema as per the guidelines in 1975 [RFC3688]. 1977 URI: urn:ietf:params:xml:schema:lm:gnss 1979 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1980 Martin Thomson (martin.thomson@andrew.com). 1982 Schema: The XML for this schema can be found in Section 5.7 of this 1983 document. 1985 7.17. XML Schema Registration for DSL Schema 1987 This section registers an XML schema as per the guidelines in 1988 [RFC3688]. 1990 URI: urn:ietf:params:xml:schema:lm:dsl 1992 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1993 Martin Thomson (martin.thomson@andrew.com). 1995 Schema: The XML for this schema can be found in Section 5.8 of this 1996 document. 1998 8. Acknowledgements 2000 Thanks go to Simon Cox for his comments relating to terminology that 2001 have helped ensure that this document is aligns with ongoing work in 2002 the Open Geospatial Consortium (OGC). Thanks to Neil Harper for his 2003 review and comments on the GNSS sections of this document. Thanks to 2004 Noor-E-Gagan Singh for his suggestions relating to the WiFi section 2005 of this document. 2007 9. References 2009 9.1. Normative References 2011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2012 Requirement Levels", BCP 14, RFC 2119, March 1997. 2014 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2015 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2016 October 1998. 2018 [I-D.ietf-geopriv-http-location-delivery] 2019 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 2020 "HTTP Enabled Location Delivery (HELD)", 2021 draft-ietf-geopriv-http-location-delivery-09 (work in 2022 progress), September 2008. 2024 9.2. Informative References 2026 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 2027 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 2029 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 2030 RFC 3046, January 2001. 2032 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 2033 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 2034 August 2006. 2036 [IANA.enterprise] 2037 IANA, "Private Enterprise Numbers", 2038 . 2040 [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID 2041 Suboption for the Dynamic Host Configuration Protocol 2042 (DHCP) Relay Agent Option", RFC 3993, March 2005. 2044 [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 2045 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, 2046 June 2006. 2048 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2049 January 2004. 2051 [IEEE.8021AB] 2052 IEEE, "IEEE Standard for Local and Metropolitan area 2053 networks, Station and Media Access Control Connectivity 2054 Discovery", 802.1AB, June 2005. 2056 [GPS.ICD] "Navstar GPS Space Segment/Navigation User Interface", 2057 ICD GPS-200, Apr 2000. 2059 [Galileo.ICD] 2060 GJU, "Galileo Open Service Signal In Space Interface 2061 Control Document (SIS ICD)", May 2006. 2063 [I-D.winterbottom-geopriv-lis2lis-req] 2064 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 2065 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 2066 (work in progress), November 2007. 2068 [DSL.TR025] 2069 Wang, R., "Core Network Architecture Recommendations for 2070 Access to Legacy Data Networks over ADSL", September 1999. 2072 [DSL.TR101] 2073 Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSl 2074 Aggregation", April 2006. 2076 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2077 "Remote Authentication Dial In User Service (RADIUS)", 2078 RFC 2865, June 2000. 2080 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2081 Architecture", RFC 4291, February 2006. 2083 Authors' Addresses 2085 Martin Thomson 2086 Andrew 2087 PO Box U40 2088 Wollongong University Campus, NSW 2500 2089 AU 2091 Phone: +61 2 4221 2915 2092 Email: martin.thomson@andrew.com 2093 URI: http://www.andrew.com/ 2095 James Winterbottom 2096 Andrew 2097 PO Box U40 2098 Wollongong University Campus, NSW 2500 2099 AU 2101 Phone: +61 2 4221 2938 2102 Email: james.winterbottom@andrew.com 2103 URI: http://www.andrew.com/ 2105 Full Copyright Statement 2107 Copyright (C) The IETF Trust (2008). 2109 This document is subject to the rights, licenses and restrictions 2110 contained in BCP 78, and except as set forth therein, the authors 2111 retain all their rights. 2113 This document and the information contained herein are provided on an 2114 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2115 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2116 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2117 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2118 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2119 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2121 Intellectual Property 2123 The IETF takes no position regarding the validity or scope of any 2124 Intellectual Property Rights or other rights that might be claimed to 2125 pertain to the implementation or use of the technology described in 2126 this document or the extent to which any license under such rights 2127 might or might not be available; nor does it represent that it has 2128 made any independent effort to identify any such rights. Information 2129 on the procedures with respect to rights in RFC documents can be 2130 found in BCP 78 and BCP 79. 2132 Copies of IPR disclosures made to the IETF Secretariat and any 2133 assurances of licenses to be made available, or the result of an 2134 attempt made to obtain a general license or permission for the use of 2135 such proprietary rights by implementers or users of this 2136 specification can be obtained from the IETF on-line IPR repository at 2137 http://www.ietf.org/ipr. 2139 The IETF invites any interested party to bring to its attention any 2140 copyrights, patents or patent applications, or other proprietary 2141 rights that may cover technology that may be required to implement 2142 this standard. Please address the information to the IETF at 2143 ietf-ipr@ietf.org.