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.