idnits 2.17.1
draft-thomson-held-grip-00.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 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 1115.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1126.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1133.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1139.
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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- 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 (June 16, 2008) is 5786 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Outdated reference: A later version (-16) exists of
draft-ietf-geopriv-http-location-delivery-07
-- Obsolete informational reference (is this intentional?): RFC 1305
(Obsoleted by RFC 5905)
-- Obsolete informational reference (is this intentional?): RFC 4330
(Obsoleted by RFC 5905)
-- Obsolete informational reference (is this intentional?): RFC 3315
(Obsoleted by RFC 8415)
-- Obsolete informational reference (is this intentional?): RFC 4346
(Obsoleted by RFC 5246)
== Outdated reference: A later version (-06) exists of
draft-thomson-geopriv-held-measurements-02
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 11 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: Experimental Andrew Corporation
5 Expires: December 18, 2008 June 16, 2008
7 Providing Satellite Navigation Assistance Data using HELD
8 draft-thomson-held-grip-00
10 Status of This Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on December 18, 2008.
35 Abstract
37 This document describes a method for providing Global Navigation
38 Satellite System (GNSS) assistance data using the HTTP-Enabled
39 Location Delivery (HELD) protocol. An assistance data request is
40 included with the HELD location request and the Location Information
41 Server (LIS) provides assistance data along with location
42 information.
44 Table of Contents
46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
47 1.1. Advantages of Assistance Data . . . . . . . . . . . . . . 4
48 2. Conventions used in this document . . . . . . . . . . . . . . 4
49 3. The GNSS Reference Information Protocol . . . . . . . . . . . 5
50 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
51 4.1. Assistance Data Types . . . . . . . . . . . . . . . . . . 8
52 4.2. Identifying Assistance Data Types . . . . . . . . . . . . 9
53 4.3. Time Assistance . . . . . . . . . . . . . . . . . . . . . 9
54 5. GPS Assistance Data Types . . . . . . . . . . . . . . . . . . 10
55 5.1. UTC Model . . . . . . . . . . . . . . . . . . . . . . . . 11
56 5.2. Ionosphere Model . . . . . . . . . . . . . . . . . . . . . 11
57 5.3. Almanac . . . . . . . . . . . . . . . . . . . . . . . . . 11
58 5.4. Real Time Integrity . . . . . . . . . . . . . . . . . . . 11
59 5.5. Navigation Model . . . . . . . . . . . . . . . . . . . . . 11
60 5.5.1. Issue of Data Ephemeris . . . . . . . . . . . . . . . 12
61 5.6. Time of Week Assistance . . . . . . . . . . . . . . . . . 13
62 5.7. Acquisition Assistance . . . . . . . . . . . . . . . . . . 13
63 5.8. Differential GPS Corrections . . . . . . . . . . . . . . . 14
64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
69 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
70 Appendix A. GRIP Schema . . . . . . . . . . . . . . . . . . . . . 17
71 Appendix B. GRIP GPS Data Schema . . . . . . . . . . . . . . . . 19
73 1. Introduction
75 A Global Navigation Satellite System (GNSS) provides a signal that
76 enables accurate determination of the position of a receiver in space
77 and time. A constellation of satellites transmit radio signals that
78 the receiver is able to measure. From these measurements, the
79 location of the receiver and the time of measurement can be
80 determined using knowledge about the position and velocity of the
81 satellites and signal information.
83 Acquisition of satellite signals requires searching for the extremely
84 weak signal transmitted by each satellite. Each satellite transmits
85 a repeating signal. Acquiring the signal is done by synchronizing
86 with the received signal in both frequency and time. In order to
87 synchronize, the receiver searches in two dimensions:
89 time/code phase: The distance between the satellite and receiver
90 means that the receiver sees a signal that is offset in time. The
91 amount of time shift is known as code phase since it is measured
92 within the window of the repeated code sequence. Code phase forms
93 the primary measurement used in calculating a position.
95 frequency: The relative speed of satellite and receiver causes
96 Doppler shift of the satellite signal.
98 Satellite signals are typically modulated at a low rate with a
99 navigation message. The navigation message provides information that
100 is used in the final calculation phase including information on
101 satellite orbit, satellite health, time model, atmospheric effects on
102 the signal. This data is transmitted at very low rates to avoid
103 hampering the acquisition process, therefore acquiring this
104 information can take a signficant amount of time.
106 Once satellite signals have been acquired and measured, the
107 measurement information is combined with the information from the
108 navigation message and a position (and time) can be calculated.
109 Successful calculation of a position typically requires measurement
110 data for a minimum of 5 satellites unless otherwise supplemented.
112 If a receiver has to perform all these steps independently, satellite
113 acquisition and receipt of the navigation message can take
114 significant amounts of time. Improvements in receiver design have
115 increased receiver sensitivity and the speed that signals are
116 acquired. Use of assistance data provides a dramatic improvement in
117 the time taken to acquire signals and produce a result.
119 This document provides a means of combining a request for GNSS
120 assistance data with a HELD [I-D.ietf-geopriv-http-location-delivery]
121 request.
123 1.1. Advantages of Assistance Data
125 GNSS assistance data is information provided to a receiver that is
126 provided to improve the quality and timeliness of GNSS measurements
127 or positioning. The most basic set of assistance data includes the
128 same information provided in the navigation message. Additional
129 forms of assistance data include information customized to a
130 particular receiver to assist it in acquiring signals, or information
131 about satellite ephemerides (orbits) that is useful over a longer
132 period of time.
134 Acquiring assistance data from the network completely removes the
135 need to receive the navigation message. Navigation message content
136 can be transmitted to the receiver using the vastly more efficient
137 communication paths provided by a data network. This removes a
138 significant step from the process of determining a position.
140 Knowing what satellites to search for can reduce signal acquisition
141 time. One of the most basic pieces of information provided by
142 assistance data is knowledge of which satellites are above the
143 horizon and can therefore be measured. Concentrating on "visible"
144 satellites ensures that less time is wasted where signals could not
145 possibly be found.
147 Assistance data can provide information about where in the frequency/
148 code phase space to search for a particular satellite signal. This
149 reduces the time required to acquire a satellite signal. Since an
150 approximate frequency and code phase can be known, it becomes
151 feasible to spend more time searching for weaker signals, improving
152 receiver sensitivity. Improved sensitivity ensures that GNSS can be
153 used in areas where signal penetration is poor, like buildings and
154 other areas with poor sky visibility, and increases the likelihood of
155 getting sufficient satellite measurements to calculate a position.
157 Assistance data also enables compensation for the effects of the
158 navigation message. Knowing the content of the navigation message
159 ahead of time means that the receiver is able to anticipate the
160 effect of its modulation on the signal and compensate accordingly.
161 This increases the sensitivity of the receiver and allows for faster
162 signal acquisition.
164 2. Conventions used in this document
166 The key words "must", "must not", "required", "shall", "shall not",
167 "should", "should not", "recommended", "may", and "optional" in this
168 document are to be interpreted as described in [RFC2119].
170 3. The GNSS Reference Information Protocol
172 The GNSS Reference Information Protocol (GRIP) is a protocol that is
173 used for the acquisition of GNSS assistance data. This document
174 describes how to use GRIP in conjunction with HELD to enable the use
175 of assisted GNSS positioning.
177 GRIP response message provides a set of several different types of
178 assistance data. A set of assistance data types for GPS is shown in
179 Table 1. The scope of each field is also included to shown whether
180 the data applies globally, to a specific area only (local), or could
181 apply to either.
183 +-----------------+--------+----------------------------------------+
184 | Type | Scope | Description |
185 +-----------------+--------+----------------------------------------+
186 | UTC Model | Global | models the difference between GPS time |
187 | | | and UTC time |
188 | Ionospheric | Global | models the propagation delay on |
189 | Model | | satellite signals caused by the |
190 | | | ionosphere |
191 | Almanac | Either | a low-detail, long-term model of |
192 | | | satellite orbits and clocks |
193 | Real Time | Either | identifies satellites that should not |
194 | Integrity | | be used |
195 | Navigation | Either | models the orbit of the satellite over |
196 | Model | | time |
197 | TOW Assist | Either | aids in signal acquisition |
198 | Acquisition | Local | for fast signal acquisition |
199 | Assistance | | |
200 | Differential | Local | parameters for fine tuning calculated |
201 | GPS Corrections | | results |
202 +-----------------+--------+----------------------------------------+
204 Table 1: Assistance Data Types for GPS
206 Data marked as either global or specific to a particular location
207 contains information about individual satellites. This information
208 is localized by constraining the information to the set of satellites
209 that are expected to be visible from that location. Information on
210 satellites that are on the other side of the Earth or below the
211 horizon is omitted. This ensures that a receiver is immediately able
212 to restrict the set of satellites that it searches for.
214 Acquisition assistance and differential GPS corrections always
215 contain localized information. Acquisition assistance contains a
216 prediction about the satellite signal for the given location that
217 narrows the size of the code phase and frequency space that needs to
218 be searched. Differential GPS is information on signal errors
219 provided by another receiver that is near the specified location.
220 Differential GPS corrections aids in the calculation of results by
221 providing fine tuning of the measurement data.
223 A GRIP request can include two parts, a request for global assistance
224 data and a request for localized assistance data. Each part
225 identifies the assistance data types that are required; a request for
226 localized data must also include location information. Location
227 information can be provided by-value or by-reference.
229 Note: GRIP, as reproduced in this document, is an incomplete
230 protocol that has the goal of providing a means for requesting
231 assistance data. Only the Global Position System (GPS)
232 constellation is supported in the messages that are included in
233 this document. This protocol does not fall within the scope of
234 the work performed by the target working group (GEOPRIV) and the
235 IETF in general. It is intended that this work find a more
236 appropriate home before this draft progresses. The information is
237 included as a temporary measure to ensure that it can be reliably
238 referenced from this document.
240 4. Operation
242 A Device that includes a GNSS receiver is able to request assistance
243 data as part of a HELD location request to a Location Information
244 Server (LIS). The request is included as an extension to the
245 location request and is ignored by a LIS that does not support this
246 specification, or cannot provide assistance data. The receiver
247 includes a GRIP assistance data request in a HELD location request.
249
250
252
253
254
255 urn:x-grip:location:requester
256
257
258
259
261 The assistance data request contains two parts, identifying the
262 global and local assistance data types that are requested. Global
263 assistance data can be provided without any extra information, but
264 localized assistance data requires that a location estimate for the
265 requester be known. Any request for localized assistance data must
266 include location information. Location information can be provided
267 by value, preferably using a geodetic form, or by reference.
269 GRIP requires location information when localized assistance data is
270 requested because a GRIP server cannot be assumed to have the ability
271 to locate requesters. However, in the case where the GRIP request is
272 placed in a HELD request, the LIS is certainly able to locate the
273 requester. To indicate that the LIS should generate the location
274 information necessary to generate localized assistance data a special
275 URN is used in place of the location reference. The
276 "urn:x-grip:location:requester" URN indicates that the server is
277 expected to generate location information for the requester and use
278 that in generating localized assistance data. The LIS MAY choose to
279 generate location information for any request and ignore the location
280 information provided.
282 The location response, along with the location information, includes
283 the requested assistance data. (Note: the "hexBinary" navigation
284 data is wrapped due to document constraints.)
285
286
288
289
290
292
293 00001F0000000890970E4B070E
294 0602FFFE2906FFF8
295 3 6 8 24
296
297
298
299
300 8B065C8CA0A465D0010045A5905BABDA135662BEDBA56B3A0000190E
301 FA448B065C8CA12AA5091B3176377C8F1907A6047F5A5E1653A10CCCA86B3A7E8B
302 065C8CA1AC0079F86A32C9FFF0269127BC14675EF1C04CFFAB23A5E094
303
304
305 8B065C8CA0A465D0000045A5905BABDA135662BEF4876B3A00FFF801
306 43D38B065C8CA12A870A2130D3A088963508A103EB9A411787A10C990D6B3A7E8B
307 065C8CA1ACFFFBF9331B37FFA6268B1C9813770AD0980CFFAB4C87E6B3
308
309
310
311
312 407 1 0 0
313 407 1 0 0
314
315
316
317
318
320 The response includes the information that was available to the LIS.
321 Unsupported or unavailable pieces of information are indicated using
322 the "unsupported" or "unavailable" attributes.
324 4.1. Assistance Data Types
326 Each assistance data type is specified as an XML element that is
327 included in either the "global" or "local" element of the assistance
328 data response. Assistance data formats for each different GNSS are
329 specified as separate elements.
331 A set of assistance data types are defined for GPS in Section 5 using
332 the namespace "urn:x-grip:gnss:gps".
334 Note: Different satellite systems share a number of key parameters,
335 and it could be useful to have a generic format for assistance
336 data that could be universally applicable. While the benefits of
337 a generic approach are obvious, this approach enables a more rapid
338 development of a specification without preventing a generic format
339 from being introduced later.
341 4.2. Identifying Assistance Data Types
343 A request for assistance data identifies the XML elements that
344 contain the assistance data by name. The "data" attribute can be
345 included on either the "global" or "local" element of the assistance
346 data request. The "data" attribute includes a whitespace-separated
347 list of elements.
349 Each item in this list is a qualified element name that identifies
350 the requested element. Each item can be interpreted as XML Path
351 Language (XPath) [W3C.REC-xpath20-20070123] expressions that are
352 evaluated in the context of the matching element in the response.
353 These statements are restricted to use of qualified names only.
354 Namespace prefixes are taken from the document context.
356 Each type of assistance data that is identified in the request must
357 be included in the corresponding "global" or "local" element of the
358 response. If information cannot be provided the LIS must indicate
359 which items are either unavailable (a temporary cause of error) or
360 unsupported (a situation that is more likely to be persistent). The
361 "unavailable" and "unsupported" attributes are used in the response
362 to indicate which items were not provided. Unsupported assistance
363 data types must be included in the response using the "unsupported"
364 attribute.
366 If an assistance data type is requested in an inapplicable category
367 (such as the UTC model in the "local" element), it must be reported
368 as "unsupported".
370 This method of identifying assistance data types enables easy
371 extension to forms of GNSS other than GPS or new types of assistance
372 data. By relying on the inherent extensibility provided by
373 namespaces in XML [W3C.REC-xml-names-20060816], extensions can be
374 readily addded. Extensions for other types of GNSS or assistance
375 data need only define elements in a new namespace.
377 4.3. Time Assistance
379 Time synchronization is helpful in ensuring rapid signal acquisition.
380 Satellite signals change with time, so having accurate time ensures
381 that the time-based information provided with assistance data can be
382 more effectively used. Accurate time also enables position
383 determination with fewer pseudorange measurements.
385 Other assistance data protocols define a reference time assistance
386 data type, which includes a time in the GNSS time system. However,
387 the mechanisms that are used to ensure that this information is
388 correct when received are dependent on the type of network. Without
389 these mechanisms, network latency and retransmission delays can
390 result in this value being incorrect when it is received.
392 This document does not define a mechanism for providing accurate time
393 as part of assistance data, instead relying on general purpose time
394 synchronization protocols.
396 The Network Time Protocol (NTP) [RFC1305] or Simple Network Time
397 Protocol (SNTP) [RFC4330] can be used by GNSS receivers to acquire
398 clock synchronization with Coordinated Universal Time (UTC). The
399 time model assistance data type (or UTC model for GPS) provides the
400 information necessary to translate from UTC to the time system used
401 by the GNSS.
403 A LIS does not provide information about time servers. Configuration
404 of hosts can be manual, or time server information can be provided by
405 DHCP ([RFC2132], [RFC3315], [RFC4075], [I-D.gayraud-dhcpv6-ntp-opt]).
407 5. GPS Assistance Data Types
409 This section defines a set of assistance data types for the GPS GNSS
410 (as shown in Table 1). Each assistance data type is defined as an
411 XML element and is able to be identified by the qualified name
412 [W3C.REC-xml-names-20060816] of the element. The GPS elements are
413 defined in the "urn:x-grip:gnss:gps" namespace. The "gps:" prefix is
414 used in this section to identify this namespace.
416 GPS assistance data is constructed based on the definition of the
417 navigation message defined in GPS interface control document
418 [GPS-ICD]. Assistance data that is provided on a per-satellite, or
419 space vehicle (SV), basis is split into "gps:sat" elements under each
420 data type. The satellite is identified by its SV-ID, a number
421 between 1 and 32, in the "num" attribute.
423 An XML Schema for GRIP messages is included in Appendix A. A schema
424 defining the format of assistance data for GPS is included in
425 Appendix B.
427 5.1. UTC Model
429 The UTC model contains the information necessary to convert from UTC
430 time to the time system used by GPS. The "gps:utc" element contains
431 a string of hexadecimal digits that correspond to bits 151 through
432 279 of subframe 4, page 18 of the navigation message, with the parity
433 bits removed.
435 5.2. Ionosphere Model
437 The ionosphere model contains parameters for a model of the
438 propagation delay through the ionosphere - the part of the Earth's
439 atmosphere that has the more significant impact on satellite signals.
440 The "gps:ionosphere" element contains a string of hexadecimal digits
441 that correspond to bits 69 through 145 of subframe 4, page 18 of the
442 navigation message, with the parity bits removed.
444 5.3. Almanac
446 The almanac assistance data type includes information about the
447 satellites in the GPS constellation. This information is intended to
448 be long-lived and changes rarely. This information is not useful for
449 calculating a position, but is helpful in determining what satellites
450 could be used. The "gps:almanac" element contains per-satellite
451 data. The content of the "gps:sat" element is a string of
452 hexadecimal digits that correspond to the collated almanac data from
453 the navigation message (subframe 5, pages 1 through 24; or subframe
454 4, pages 2, 3, 4, 5, 7, 8, 9 and 10).
456 5.4. Real Time Integrity
458 This data type contains a list of the satellite (SV) identifiers for
459 those satellites that are either out of service or are otherwise not
460 recommended for use. The "gps:rti" element contains a whitespace-
461 separated list of satellited identifiers.
463 5.5. Navigation Model
465 The navigation model contains information for each satellite in the
466 chosen set; either all GPS satellites, or those that are expected to
467 be visible from the estimated location of the Device. To that end,
468 the "gps:navigation" element contains one or more "gps:sat" elements.
469 The content of the "gps:sat" element is a hex string of 180
470 characters (90 bytes) that is sub-frames 1 through 3 of the
471 navigation message for the given satellite with parity bits removed.
473 5.5.1. Issue of Data Ephemeris
475 [[Editor's Note: Using IODE to save on bits is a practice that comes
476 over from the original bit-miserly protocols like RRLP that provided
477 GPS assistance data. The complexity of implementing this
478 functionality probably outweighs the relatively small saving in bits.
479 Candidate for removal.]]
481 The navigation model represents the largest and most significant
482 piece of assistance data provided. This information changes on an
483 hourly basis, and at each change the Issue of Data Ephemeris (IODE)
484 is changed. For this reason, a request that asks for the navigation
485 model is able to indicate the IODE for each satellite and the time
486 that this data was acquired. The response can omit satellites with
487 matching IODE.
489 An "gps:iode" element can be included in the "local" or "global"
490 element of the request. It identifies the current time (in UTC or
491 GPS time) and the IODE for each satellite that the receiver knows
492 about.
494
495
497
498
499
500
503 42.5463 -73.2512
504
505 850.24
506
507
508
509
510 66
511 66
512
513
514
515
517 Implementation of this feature by a GRIP server is optional. A GRIP
518 client that uses this option must be prepared to receive navigation
519 model information for satellites that it already has information for.
521 5.6. Time of Week Assistance
523 The time of week (TOW) assistance information includes the telemetry
524 (TLM) message, which is included every six seconds as the first word
525 of a subframe or page. The anti-spoof and alert flags from the
526 handover (HOW) word are also included in this item. This item can
527 change each time, but it rarely does; therefore, knowing the current
528 telemetry word aids in ensuring that the signal can be more rapidly
529 acquired. The "gps:towassist" element contains per-satellite data.
530 The data for each satellite is a whitespace-separated list of four
531 integers, starting with the 14-bits of the TLM message, then the
532 1-bit anti-spoof flag, the 1-bit alert flag and then the 2-bit
533 reserved portion from the TLM word.
535 5.7. Acquisition Assistance
537 Acquisition assistance aids receivers in satellite signal acquisition
538 by attempting to predict signals for a particular location at a
539 certain time. Acquisition assistance is synthesized from satellite
540 data; it is not a reconstruction of parts of the navigation message.
541 This data includes prediced code phase and doppler, plus a means to
542 predict how these change over time. This compact form allows for
543 faster measurement of the signals without necessarily enabling
544 position calculation.
546 The "gps:acqassist" element contains per-satellite data. Each
547 "gps:sat" element contains a list of floating point numbers as
548 described in Table 2.
550 +-------+-----------------+-----------------------------------------+
551 | Order | Name | Description |
552 +-------+-----------------+-----------------------------------------+
553 | 1 | 0th order | The predicted Doppler shift in Hz |
554 | | Doppler | |
555 | 2 | 1st order | The rate of change of Doppler shift in |
556 | | Doppler | Hz/s |
557 | 3 | Doppler Search | The range of Doppler shift values to |
558 | | Window | search in Hz |
559 | 4 | Code Phase | The predicted code phase in chips from |
560 | | | 0 to 1022 |
561 | 5 | Integer Code | The number of whole 1023 chip segments |
562 | | Phase | |
563 | 6 | Code Phase | The range of code phase values to |
564 | | Uncertainty | search |
565 | 7 | Azimuth | The azimuth (from Northing) of the |
566 | | | satellite in degrees |
567 | 8 | Elevation | The elevation (from horizontal) of the |
568 | | | satellite in degrees |
569 +-------+-----------------+-----------------------------------------+
571 Table 2: Acquisition Assistance Fields
573 5.8. Differential GPS Corrections
575 Differential GPS provides a means of compensating for atmospheric
576 effects, orbital model limitation and satellite clock drift. The
577 "gps:dgps" element includes attributes that indicate the GPS time
578 when measurements were taken and per-satellite information. The
579 "gpsWeek" and "gpsTOW" attributes used for the IODE time are used to
580 provide a GPS time on the "gps:dgps" element.
582 The "gps:sat" element includes a whitespace-separated list of three
583 floating point values:
585 UDRE: an estimate of the accuracy of the pseudorange corrections in
586 metres
588 pseudorange correction: a correction value in metres, taken at the
589 time indicated
591 pseudorange correction rate of change: the rate that the pseudorange
592 correction changes in metres per second
594 6. Security Considerations
596 Since this document relies on bundling assistance data with a HELD
597 location response, it inherits many of the same security
598 considerations as HELD [I-D.ietf-geopriv-http-location-delivery]. It
599 also inherits all the protections provided therein; largely provided
600 by use of TLS [RFC4346].
602 Privacy is a major consideration for location protocol security.
603 However, assistance data contains less useful information than the
604 location information that is already provided. The bulk of the
605 assistance data is either publically available or is derived from
606 that publically available data and the estimate location of the
607 Device.
609 Requesting localized assistance data from a GRIP server for an
610 arbitrary location provides little additional information over what
611 is provided by requesting global types. However, a request for
612 acquisition assistance could be used to trivially generate spoofed
613 GNSS measurements. [I-D.thomson-geopriv-held-measurements] provides
614 suggestions for dealing with spoofed GNSS measurements, but it is
615 recommended that a LIS not provide acquisition assistance for
616 arbitrary locations.
618 A Device that relies on assistance data could find that bad
619 assistance data is more of a hindrance than help. However, the
620 impact of an attack by a LIS on assisted GNSS is limited by the fact
621 that bad assistance data can be readily ignored and autonomous
622 operation used.
624 7. IANA Considerations
626 No registrations are necessary for GRIP namespaces (these are not
627 registered by this document).
629 8. Acknowledgements
631 This document uses a modified copy of the GRIP protocol based on the
632 work done by the University of New South Wales through the OSGRS
633 project . Authors of the original
634 GRIP specification were Nam Hoang and Manosh Fernando. The GPS
635 expertise of Neil Harper was invaluable in assembling this document.
637 9. References
639 9.1. Normative References
641 [RFC2119] Bradner, S., "Key words
642 for use in RFCs to
643 Indicate Requirement
644 Levels", BCP 14, RFC 2119,
645 March 1997.
647 [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom,
648 J., Thomson, M., and B.
649 Stark, "HTTP Enabled
650 Location Delivery (HELD)",
651 draft-ietf-geopriv-http-
652 location-delivery-07 (work
653 in progress), April 2008.
655 [W3C.REC-xpath20-20070123] Berglund, A., Chamberlin,
656 D., Robie, J., Boag, S.,
657 Kay, M., Simeon, J., and
658 M. Fernandez, "XML Path
659 Language (XPath) 2.0",
660 World Wide Web Consortium
661 Recommendation REC-
662 xpath20-20070123,
663 January 2007, .
667 [GPS-ICD] "Navstar GPS Space Segment
668 / Navigation User
669 Interfaces", ICD-GPS-
670 200c, April 2000.
672 9.2. Informative References
674 [RFC1305] Mills, D., "Network Time
675 Protocol (Version 3)
676 Specification,
677 Implementation", RFC 1305,
678 March 1992.
680 [RFC4330] Mills, D., "Simple Network
681 Time Protocol (SNTP)
682 Version 4 for IPv4, IPv6
683 and OSI", RFC 4330,
684 January 2006.
686 [RFC2132] Alexander, S. and R.
687 Droms, "DHCP Options and
688 BOOTP Vendor Extensions",
689 RFC 2132, March 1997.
691 [RFC3315] Droms, R., Bound, J.,
692 Volz, B., Lemon, T.,
693 Perkins, C., and M.
694 Carney, "Dynamic Host
695 Configuration Protocol for
696 IPv6 (DHCPv6)", RFC 3315,
697 July 2003.
699 [RFC4075] Kalusivalingam, V.,
700 "Simple Network Time
701 Protocol (SNTP)
702 Configuration Option for
703 DHCPv6", RFC 4075,
704 May 2005.
706 [RFC4346] Dierks, T. and E.
707 Rescorla, "The Transport
708 Layer Security (TLS)
709 Protocol Version 1.1",
710 RFC 4346, April 2006.
712 [I-D.thomson-geopriv-held-measurements] Thomson, M. and J.
713 Winterbottom, "Using
714 Device-provided Location-
715 Related Measurements in
716 HELD", draft-thomson-
717 geopriv-held-measurements-
718 02 (work in progress),
719 May 2008.
721 [I-D.gayraud-dhcpv6-ntp-opt] Gayraud, R. and B.
722 Lourdelet, "Network Time
723 Protocol (NTP) Server
724 Option for DHCPv6", draft-
725 gayraud-dhcpv6-ntp-opt-01
726 (work in progress),
727 February 2008.
729 [W3C.REC-xml-names-20060816] Tobin, R., Hollander, D.,
730 Bray, T., and A. Layman,
731 "Namespaces in XML 1.0
732 (Second Edition)", World
733 Wide Web Consortium Recomm
734 endation REC-xml-names-
735 20060816, August 2006, .
739 Appendix A. GRIP Schema
741 The following schema document defines the request and response
742 elements for the GNSS Reference Interface Protocol (GRIP).
744
745
752
753
754 This document describes the format of GNSS assistance data
755 requests.
756
757
759
760
761
762
763
764
765
766
768
769
770
771
772
773
774
776
777
778
779
780
781
782
783
784
786
787
788
789
791
792
793
794
795
797
798
799
800
801
802
804
805
806
807
808
809
810
811
813
814
815
816
817
818
819
821
822
823
824
825
827
828
830
832
833
834
836
837
838
840
842 Appendix B. GRIP GPS Data Schema
844 The following schema document defines the elements for GPS assistance
845 data, based on the outline in Section 5.
847
848
855
856
857 This document describes the format of GPS assistance data.
858
859
861
863
864
865
866
867
869
870
871
872
873
875
876
877
878
880
881
882
884
885
886
887
888
890
891
892
893
894
895
896
897
898
899
900
901
902
903
905
906
907
909
910
911
913
915
916
917
918
919
920
922
923
924
925
926
927
929
930
931
932
934
935
936
937
938
939
940
941
942
943
944
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
962
963
964
965
966
967
968
969
970
971
972
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
991
992
993
994
995
996
997
998
999
1000
1001
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1078
1080 Authors' Addresses
1082 Martin Thomson
1083 Andrew Corporation
1084 PO Box U40
1085 Wollongong University Campus, NSW 2500
1086 AU
1088 Phone: +61 2 4221 2915
1089 EMail: martin.thomson@andrew.com
1090 URI: http://www.andrew.com/
1091 James Winterbottom
1092 Andrew Corporation
1093 PO Box U40
1094 University of Wollongong, NSW 2500
1095 AU
1097 Phone: +61 242 212938
1098 EMail: james.winterbottom@andrew.com
1099 URI: http://www.andrew.com/products/geometrix
1101 Full Copyright Statement
1103 Copyright (C) The IETF Trust (2008).
1105 This document is subject to the rights, licenses and restrictions
1106 contained in BCP 78, and except as set forth therein, the authors
1107 retain all their rights.
1109 This document and the information contained herein are provided on an
1110 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1111 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1112 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1113 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1114 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1115 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1117 Intellectual Property
1119 The IETF takes no position regarding the validity or scope of any
1120 Intellectual Property Rights or other rights that might be claimed to
1121 pertain to the implementation or use of the technology described in
1122 this document or the extent to which any license under such rights
1123 might or might not be available; nor does it represent that it has
1124 made any independent effort to identify any such rights. Information
1125 on the procedures with respect to rights in RFC documents can be
1126 found in BCP 78 and BCP 79.
1128 Copies of IPR disclosures made to the IETF Secretariat and any
1129 assurances of licenses to be made available, or the result of an
1130 attempt made to obtain a general license or permission for the use of
1131 such proprietary rights by implementers or users of this
1132 specification can be obtained from the IETF on-line IPR repository at
1133 http://www.ietf.org/ipr.
1135 The IETF invites any interested party to bring to its attention any
1136 copyrights, patents or patent applications, or other proprietary
1137 rights that may cover technology that may be required to implement
1138 this standard. Please address the information to the IETF at
1139 ietf-ipr@ietf.org.