idnits 2.16.02
/tmp/draft-thomson-geopriv-grip-gps-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (June 29, 2011) is 2851 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '0' on line 553
-- Looks like a reference, but probably isn't: '1' on line 265
== Missing Reference: 'GD' is mentioned on line 423, but not defined
-- Looks like a reference, but probably isn't: '3' on line 553
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV M. Thomson
3 Internet-Draft Andrew Corporation
4 Intended status: Experimental June 29, 2011
5 Expires: December 31, 2011
7 Global Navigation Satellite System (GNSS) Reference Information Protocol
8 (GRIP) - Global Positioning System (GPS) Assistance Data
9 draft-thomson-geopriv-grip-gps-02.txt
11 Abstract
13 This document defines assistance data formats for the Global
14 Positioning System (GPS). These formats can be used with the Global
15 Navigation Satellite System (GNSS) Reference Information Protocol
16 (GRIP) by a GPS receiver to acquire assistance data.
18 Status of This Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at http://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on December 31, 2011.
35 Copyright Notice
37 Copyright (c) 2011 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
53 2. Conventions used in this document . . . . . . . . . . . . . . 3
54 2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
55 2.2. Angular Measures . . . . . . . . . . . . . . . . . . . . . 4
56 2.3. Polynomial Expressions . . . . . . . . . . . . . . . . . . 4
57 2.4. Expressing Reference Time . . . . . . . . . . . . . . . . 5
58 3. GPS Assistance Data Types . . . . . . . . . . . . . . . . . . 6
59 3.1. UTC Model . . . . . . . . . . . . . . . . . . . . . . . . 6
60 3.2. Navigation Model . . . . . . . . . . . . . . . . . . . . . 7
61 3.2.1. Navigation Model Clock Model . . . . . . . . . . . . . 10
62 3.2.2. Navigation Model Orbital Model . . . . . . . . . . . . 10
63 3.2.3. Example Navigation Model . . . . . . . . . . . . . . . 12
64 3.3. Ionosphere Model . . . . . . . . . . . . . . . . . . . . . 12
65 3.4. Acquisition Assistance . . . . . . . . . . . . . . . . . . 13
66 3.5. Differential GPS Corrections . . . . . . . . . . . . . . . 14
67 3.6. Almanac . . . . . . . . . . . . . . . . . . . . . . . . . 14
68 3.7. Extended Navigation Model . . . . . . . . . . . . . . . . 16
69 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17
70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
72 6.1. URN Sub-Namespace Registration for
73 'urn:ietf:params:xml:ns:grip:gps' . . . . . . . . . . . . 27
74 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 27
75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28
78 8.2. Informative References . . . . . . . . . . . . . . . . . . 28
80 1. Introduction
82 The Global Positioning System (GPS) is a navigation system that
83 provides the means to determine the location of a receiver in space
84 and time with high accuracy. With a large number of satellites, it
85 is the most widely used Global Navigation Satellite System (GNSS).
87 Server-assisted GPS provides a number of advantages including
88 reducing the time required to measure satellites; reducing the time
89 required to obtain the information necessary to calculate a position;
90 and improving the ability of a receiver to successfully measure
91 satellites in low signal conditions.
93 This document defines a series of XML elements that, in combination
94 with the GNSS Reference Information Protocol (GRIP) protocol
95 [I-D.thomson-geopriv-grip], can be used to provide a receiver with
96 assistance data.
98 Readers of this document are warned that detailed knowledge of GPS is
99 likely necessary to understand this document. It is intended that
100 this document be read in conjunction with the GPS Interface
101 Specification [GPS-IS-200], which defines all the significant
102 parameters.
104 2. Conventions used in this document
106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
108 document are to be interpreted as described in [RFC2119].
110 The GPS Interface Specification [GPS-IS-200] describes the navigation
111 message and the parameters contained therein. This document does not
112 repeat definitions and it cannot be interpreted without reference to
113 the GPS Interface Specification. Only enough information is provided
114 to unambiguously identify the corresponding variable in the Interface
115 Specification.
117 2.1. Notational Conventions
119 In naming parameters, the GPS Interface Specification frequently uses
120 mathematical symbols and characters that cannot be represented in
121 this document format. In particular, Greek characters are used to
122 represent many parameters. The following conventions are used in
123 this document to aid in correlating the two texts:
125 o This document uses the full English name of the character (for
126 instance, the argument of periapsis is represented by the Greek
127 letter "omega").
129 o The case of English names follows the case of the Greek character.
130 Uppercase Greek characters are represented in full uppercase
131 (e.g., the longitude of the ascending node is represented by the
132 Greek letter "OMEGA").
134 o Difference variables, which are represented as a character
135 preceded by the Greek letter delta, are expressed in the same
136 manner, with a hypen separating the delta from the variable
137 definition (e.g., the mean motion difference from computed value
138 is represented as "DELTA-n").
140 o Subscripts on symbols are represented using square brackets (e.g.,
141 the reference time used in satellite clock correction is
142 represented by "t[ot]").
144 o Variables that represent a time rate of change, shown in the
145 Interface Specification with a small dot above the character are
146 succeeded by the string "dot" using consistent case (e.g., the
147 rate of right ascension is represented by "OMEGADOT").
149 o The following mathematical operators are used: add "+", subtract
150 "-", multiply "*", divide "/", and power "^". Spaces are used to
151 separate these from identifiers in cases where it might otherwise
152 be ambiguous.
154 o The following mathematical functions are represented by common
155 abbreviations: square root "sqrt", sine "sin", and cosine "cos".
157 2.2. Angular Measures
159 The formats described in this document are expressed in units of
160 radians, not semi-circles. When converting, it is important to use
161 the same approximation for the mathematical constant pi as is used by
162 all GPS systems. Using this approximation ensures that the
163 assistance data is generated and applied using the same values.
165 The fixed approximation for pi used in GPS is 3.1415926535898
166 [GPS-IS-200].
168 2.3. Polynomial Expressions
170 The GPS navigation message is updated infrequently, but it models
171 values that change over time. Thus, the message includes values that
172 model how values change over time.
174 Many values in GPS assistance data are expressed with a base value
175 that is set at a particularly point in time, plus a value for the
176 rate of change of that value in time. Some values are further
177 expressed with coefficients for the rate of change of the rate of
178 change. In other words, values are expressed as a polynomial
179 function in terms of time.
181 This extends to other values, such as those in the Ionosphere Model
182 that change depending on longitude. In the GPS navigation message,
183 the Ionosphere model has four polynomial terms, allowing for a more
184 complex model of ionosphere effects across different longitudes.
186 This document uses a generalized model for univariate polynomial
187 expressions. These expressions are used extensively. Each element
188 that includes a polynomial expression rather than a fixed value
189 includes the definition of the target value (and its units) plus the
190 input variable (and its units).
192 Polynomial expressions are expressed as simple lists in XML schema,
193 or a space-separated sequence of numbers. The first value in the
194 list is the constant expression; the second value is the first order
195 term; the nth value is the coefficient of the (n-1)th power of the
196 input, giving:
198 value(x) = sum from i=1..n of p[i]*x^(i-1)
200 Polynomials can be any length, but since every term needs to be
201 considered when the input variable is anything other than zero,
202 receivers MAY limit their support to as many coefficients as are
203 included in the GPS navigation message. The mandatory number of
204 supported coefficients is included in the definition of polynomials.
206 For instance, the polynomial expression "4 0.5 0.06" with an input
207 value of 2 produces: 4 + 0.5 * 2 + 0.06 * 2 ^ 2 = 5.24.
209 2.4. Expressing Reference Time
211 Where the input variable to a polynomial expression is time, a
212 reference value is commonly used. The input to the polynomial
213 expression is the difference between the current (or applicable) time
214 and the reference time. The value for reference time is usually
215 provided as a separate element in these cases and this element is
216 identified in the definition of the polynomial expression.
218 The "tow" element provides a reference time for assistance data that
219 requires a reference. This element includes the GPS time of week in
220 milliseconds to use as a reference. The input variable to time-based
221 polynomials is the difference between the current time of week and
222 the reference time of week.
224 A GPS week has 604800000 (6.048e8) milliseconds. Unless specified
225 explicitly, reference time is specified within half a week
226 (3.024e8ms) of the time that assistance data is created. The GPS
227 Interface Specification [GPS-IS-200] describes how to accomodate week
228 rollovers into calculations of time differences.
230 Alternatively, an explicit GPS week number can be indicated in the
231 "week" attribute of the "tow" element. Note that GPS week rollovers
232 also occur ever 1024 weeks (approximately 20 years).
234 3. GPS Assistance Data Types
236 This section defines assistance data types for GPS. The following
237 definitions are provided:
239 o UTC Model (Section 3.1)
241 o Navigation Model (Section 3.2)
243 o Ionosphere Model (Section 3.3)
245 o Acquisition Assistance (Section 3.4)
247 o Differential GPS Corrections (Section 3.5)
249 o Almanac (Section 3.6)
251 o Extended Navigation Model (Section 3.7)
253 3.1. UTC Model
255 The UTC model contains information on the relationship between
256 Coordinated Universal Time (UTC) time and GPS time. The realization
257 of the UTC model used in GPS is the US Naval Observatory realization:
258 UTC(USNO). The UTC model is always global.
260 tow: The tow (Section 2.4) element includes a the reference time
261 value (t[ot]).
263 offset: A polynomial in time for the time offset between GPS time
264 and UTC time. This produces a value in seconds. Two values are
265 required, which correspond to A[0] and A[1].
267 leapsec: UTC occasionally introduces a leap second. GPS time does
268 not. The "leapsec" element without attributes indicates the
269 current number of leap seconds difference between the two time
270 systems.
272 Additional instances of the "leapsec" element may be provided to
273 indicate when new leap seconds come into effect. The "week" and
274 "day" attributes respectively indicate the week and day that the
275 included value is introduced.
277 The following example shows an instance of the UTC model in XML form,
278 including information on the introduction of a new leap second:
280
281 436559
282 0.76014e-4 -0.21722e-12
283 14
284 15
285
287 3.2. Navigation Model
289 The "navigation" element contains the navigation model, information
290 on the clock and position of each satellite, plus satellite status
291 information. The navigation model is specific to a satellite and
292 forms the bulk of the information transmitted by a satellite.
294 Navigation model data can be global or local. Global data contains
295 information for all satellites; local data contains on those
296 satellites that can be seen from the input location.
298 Multiple "satellite" elements are included in the navigation model,
299 each containing the information for a single satellite. If the
300 information is local, only relevant satellites are included. Each
301 satellite included in the set is identified by number in the "number"
302 attribute.
304 The "satellite" element for navigation model has the following
305 elements:
307 ura: User Range Accuracy (URA) includes an estimation of the net
308 error in pseudorange measurements from this satellite, in meters.
309 This value MAY be set to "INF", indicating that no accuracy
310 prediction is available and that the satellite is not suitable for
311 use. INF corresponds to a value of 15 in the transmitted
312 navigation message.
314 health: The health of the satellite and the signals that it
315 transmits. The bit map from the Interface Specification is
316 represented in the value of this element and the value of the
317 "bad" and "signals" attributes.
319 The following values for the "bad" attribute relate to all of the
320 navigation data:
322 none: No data is bad (default value)
324 parity: Some or all of the parity is bad
326 tlm-how: The TLM or HOW is bad, apart from the Z-count
328 z-count: The Z-count is bad
330 sf123: Some or all data in subframes 1 through 3 is bad
332 sf45: Some or all data in subframes 4 and 5 is bad
334 most: Some or all data in any subframe is bad, excluding the TLM/
335 HOW
337 all: Some or all data in any subframe is bad, including TLM/HOW
339 The "signals" attribute identifies specific signals that might be
340 affected:
342 L1P: The L1P signal
344 L1C: The L1C signal
346 L1: Both L1P and L1C signals
348 L2P: The L2P signal
350 L2C: The L2C signal
352 L2: Both L2P and L2C signals
354 all: All signals
356 The following values for the element describe problems with the
357 identified signals, or with the entire satellite:
359 ok: All signals are OK
361 weak: The identified signal is weak
363 dead: The identified signal is dead
364 nodata: The identified signal has no data modulation
366 out: The entire satellite is temporarily out of service
368 soonout: The entire satellite will soon be out of service
370 spare: Unknown, reserved value
372 combination: Multiple errors that require a combination of
373 indications
375 l2codes: A space separated list identifying which codes (C/A or P)
376 are transmitted on the L2 signal. This MAY be empty. The "pdata"
377 flag is set to "true" if the L2P signal contains data (note that
378 this is indicated with a bit value of 0 in the GPS navigation
379 message).
381 sf1reserved: A hexadecimal representation of the 87 reserved bits
382 from subframe 1. This value is padded with a zero bit at the
383 start of the sequence.
385 aodo: The age of data offset, in seconds. A value of "INF"
386 corresponds to the maximum value from the GPS signal (27900) and
387 indicates that the navigation message correction table (NMCT)
388 cannot be used.
390 clock: Parameters that model the satellite clock. These are
391 described below.
393 ephemeris: Satellite orbital parameters, or ephemeris. These are
394 described below.
396 The"iod" attribute contains the Issue Of Data, Clock (IODC) value
397 from the navigation message. The lower 8 bits of this 10 bit value
398 indicate the Issue of Data, Ephemeris (IODE). This is only included
399 if the information is derived from the navigation message broadcast
400 by the satellite.
402 Servers MAY choose to omit navigation model information for
403 satellites that have a URA of "INF" or bad health when providing
404 local assistance data. Satellite data SHOULD always be provided for
405 global data.
407 The "health", "l2codes", "sf1reserved" and "aodo" elements contain
408 information that might not be relevant to some receivers. These
409 elements are optional, and MUST be omitted if the information
410 provided is not directly taken from the navigation message broadcast
411 by the satellite. This ensures that when present these values can be
412 used by a receiver to compansate for the effect of navigation message
413 modulation on the signal it receives.
415 3.2.1. Navigation Model Clock Model
417 The "clock" element of the satellite navigation model contains
418 information on the clock in the satellite.
420 tow: The tow (Section 2.4) element includes a the reference time
421 value (t[oc]).
423 groupdelay: The group delay differential (T[GD]), used in
424 calculating time offsets in single frequency receivers. This is a
425 value in seconds.
427 offset: A polynomial expression in time, modelling the difference
428 between the satellite time and GPS time. This produces a value in
429 seconds. Three values are required, which correspond to a[f0]
430 a[f1] and a[f2].
432 3.2.2. Navigation Model Orbital Model
434 The "ephemeris" element of the satellite navigation model contains
435 information on the orbit of the satellite.
437 tow: The tow (Section 2.4) element includes the epehemeris reference
438 time (t[oe]).
440 semiMajor: The size of the semi-major axis of the satellite orbit,
441 in meters (A). The navigation message includes the square root of
442 this value in A^(1/2).
444 eccentricity: The eccentricity of the satellite orbit (e), which is
445 dimensionless.
447 longitude: A polynomial espression in time for the longitude of the
448 ascending node. This produces a value in radians. Two values are
449 required, which correspond to OMEGA[g] and OMEGADOT[g].
451 Note that this deviates from the navigation message, which
452 includes the longitude of the ascending node at weekly epoch
453 (OMEGA[0]) and the rate of right ascension (OMEGADOT). The values
454 used are derived as follows:
456 OMEGA[g] = OMEGA[0] - OMEGADOT[e] * t[oe]
457 OMEGADOT[g] = OMEGADOT - OMEGADOT[e]
459 Where the constant OMEGADOT[e] is 7.2921151467e-5 radians/second.
461 This polynomial expression is applied using:
463 OMEGA[k] = OMEGA + OMEGADOT[g] * t[k]
465 inclination: A polynomial espression in time for the angle of
466 inclination. This produces a value in radians. Two values are
467 required, which correspond to i[0] and idot.
469 periapsis: A polynomial espression in time for the argument of
470 periapsis. This produces a value in radians. One value is
471 required, which corresponds to omega.
473 anomaly: A polynomial espression in time for the mean Keplerian
474 anomaly. This produces a value in radians. Two values are
475 required, which correspond to M[0] and n.
477 The value of n is derived from DELTA-n using the following
478 expression:
480 n = n[0] + DELTA-n
482 harmonicCorrection: This element contains harmonic correction values
483 for the argument of latitude, the orbit radius and the angle of
484 inclination. Each is expressed as a list with two terms. The
485 first term contains the amplitude of the cosine harmonic
486 correction; the second term contains the amplitude of the sine
487 harmonic correction.
489 The following harmonic correction values are provided:
491 latitude: The amplitude of harmonic correction for the argument
492 of latitude, corresponding to C[uc] and C[us].
494 radius: The amplitude of harmonic correction for the orbit
495 radius, corresponding to C[rc] and C[rs].
497 inclination: The amplitude of harmonic correction for the angle
498 of inclination, corresponding to C[ic] and C[is].
500 The "fit4hr" indicates whether the model is fit over the standard
501 period of 4 hours. If false, the model is based on a longer time
502 frame.
504 3.2.3. Example Navigation Model
506 The following example shows an instance of the navigation model in
507 XML form, including a single satellite only:
509
510
511 4.85
512 ok
513 p
514 180f7e3aaa2a7062c8d3a2
515 7200
516
517 436559
518 3.949e-9
519 8.034e-9 -2.209e-10 9.17e-14
520
521
522 436559
523 6.15861e5
524 0.98519
525 2.10554 -4.674e-9
526 0.02469827347 -1.265e-9
527 0.978932
528 0.122742 0.366697e-8
529
530 -0.6958e-4 -0.7828e-4
531 0.7604e-4 0.3125e-4
532 0.437e-4 0.6893e-4
533
534
535
536
538 3.3. Ionosphere Model
540 The "ionosphere" contains a model of the signal transmission delays
541 introduced by the Earths ionosphere. Alternative models are
542 available, but this element uses the Klobuchar model that is
543 broadcast in the satellite navigation message. The ionosphere model
544 is always global.
546 vdelay: A polynomial expression in latitude for the vertical delay
547 imposed by the ionosphere. This produces a value in seconds.
548 Four values are required, which correspond to alpha[0] through
549 alpha[3].
551 period: A polynomial expression in latitude for the period of the
552 ionosphere model. This produces a value in seconds. Four values
553 are required, which correspond to beta[0] through beta[3].
555 The following example shows an instance of the ionosphere model in
556 XML form:
558
559 1.23e-7 1.1819e-6 1.167e-5 1.16e-6
560 7.445e4 3.188e6 1.34e7 1.188e7
561
563 3.4. Acquisition Assistance
565 The "acqAssist" element contains an estimate of the measurement a
566 receiver is expected to make at a specified location. Acquisition
567 assistance is always local.
569 The "tow" element includes the reference time used in constructing
570 the acquisition assistance.
572 The "satellite" element for acquisition assistance has the following
573 elements:
575 rtow: An estimate of satellite time as seen by the receiver at the
576 reference time. This can be used to gain an estimate of the
577 range.
579 codephase: An estimate of the code phase at the receiver at the
580 given time. This value is in units of whole chips (equivalent to
581 1/1023 milliseconds). The "uncertainty" element includes an
582 estimate of the error in this estimate, at 95% confidence.
584 doppler: An estimate of the frequency shift due to the Doppler
585 effect at the receiver at the given time. This value is in units
586 of Hertz. The "uncertainty" element includes an estimate of the
587 error in this estimate, at 95% confidence.
589 direction: The direction of the satellite from the centroid of the
590 provided location, using the directional notation from [RFC5962].
591 The first value is horizontal azimuth from Northing to Easting,
592 the optional second value is elevation above (or below) the plane
593 of the horizontal.
595 The following example shows an instance of acquisition assistance in
596 XML form, including a single satellite only:
598
599 436559
600
601 436480
602 147
603 1020 0.309
604 28 38.71
605
606
608 3.5. Differential GPS Corrections
610 The "dgps" element contains an estimate of the pseudorage measurement
611 error. Differential GPS corrections are generated by fixed
612 receivers, which are able to compensate for errors that are not
613 accounted for in other GPS data. Because this information degrades
614 quickly as the distance from the fixed receiver increases,
615 differential GPS corrections are always local.
617 The "tow" element includes the reference time used in the
618 differential GPS corrections.
620 The "satellite" element for differential corrections has a single
621 "range" element. This contains a polynomial expression in time for
622 the range correction. At least two coefficients are required. The
623 "uncertainty" element includes an estimate of the remaining error in
624 this estimate, at 95% confidence.
626 The following example shows an instance of differential GPS
627 corrections in XML form, including a single satellite only:
629
630 436559
631
632 0.623 0.5e-3
633
634
636 3.6. Almanac
638 The "almanac" element contains long term information about satelite
639 clock and orbit. Almanac data is always global.
641 In the navigation message, almanac data is a simplified, low accuracy
642 version of the navigation model. In this XML representation, the
643 data MAY include additional information in the provided fields,
644 providing that the model remains usable over a period equivalent to
645 that of the almanac in the navigation message (182 days).
647 Almanac is of limited use when a navigation model is available. All
648 satellites transmit this information, so global information is
649 available even where the region covered by the server is not global.
650 Receivers use almanac to provide a rough indication of satellite
651 location after a long period where the receiver does not update other
652 data.
654 The "satellite" element contains per-satellite almanac data. The
655 "healthy" attribute identifies whether the satellite is currently fit
656 for use; a value of "false" indicates the presence of a problem. The
657 "healthy" attribute can be omitted if the satellite is healthy.
659 The "satellite" element contains the following elements:
661 tow: The reference time for the almanac data.
663 clockOffset: A polynomial expression for clock offset, containing
664 information identical to that in the "offset" element from
665 Section 3.2.1.
667 semiMajor: The semi-major axis of the orbit. Identical in
668 definition to the same element in Section 3.2.2.
670 eccentricity: The eccentricity of the orbit. Identical in
671 definition to the same element in Section 3.2.2.
673 longitude: The longitude of the ascending node. Similar to the same
674 element in Section 3.2.2, with the exception that only one
675 coefficient is required.
677 inclination: The inclination angle. Similar to the same element in
678 Section 3.2.2, with the exception that only one coefficient is
679 required.
681 periapsis: The argument of periapsis. Similar to the same element
682 in Section 3.2.2, with the exception that only one coefficient is
683 required.
685 anomaly: The mean Keplerian anomaly. Similar to the same element in
686 Section 3.2.2, with the exception that only one coefficient is
687 required.
689 The following example shows an instance of the almanac in XML form,
690 including a single satellite only:
692
693
694 436559
695 8.034e-9 -2.209e-10
696 6.15861e5
697 0.98519
698 2.10554
699 0.02469827347
700 0.978932
701 0.122742
702
703
705 3.7. Extended Navigation Model
707 The extended navigation model allows for predictions of ephemeris
708 over a longer period of time than might be allowed for with the basic
709 navigation model. For many parameters, a curve fit using a
710 polynomial with a limited number of coefficients only works for a
711 short time. While data might be sufficiently accurate within the
712 curve fit interval, outside this interval the data becomes
713 increasingly inaccurate.
715 Extended navigation model data is always global.
717 The "extNavigation" element includes multiple predictions for
718 satellite clock and ephemeris. These are predictions of future
719 state, based on more elaborate models that the server might maintain.
720 Each prediction has a specific period of time that it is valid for.
721 Thus, a receiver is able to use a new model as the previous model
722 expires.
724 The "extNavigation" element contains multiple "estimate" elements,
725 each of which contains the a complete model, plus an indication of
726 when the model is predicted to be valid.
728 The "validity" element includes two GPS time of week (Section 2.4)
729 elements, "start" and "end", that respectively indicate when the
730 estimate becomes valid and when it becomes invalid.
732 Each "satellite" element then contains a clock model (Section 3.2.1)
733 and an orbit model (Section 3.2.2).
735 Scheduled events might occur that cause predictions about certain
736 satellites to become invalid. The server MUST omit predictions for
737 affected satellite from the affected period onwards.
739 The following example shows an instance of extended navigation model
740 data in XML form, including a single estimate and a single satellite
741 only:
743
744
745
746 872465
747 1066134
748
749
750
751 872465
752 3.949e-9
753 8.034e-9 -2.209e-10 9.17e-14
754
755
756 872465
757 6.15861e5
758 0.98519
759 2.10554 -4.674e-9
760 0.02469827347 -1.265e-9
761 0.978932
762 0.122742 0.366697e-8
763
764 -0.6958e-4 -0.7828e-4
765 0.7604e-4 0.3125e-4
766 0.437e-4 0.6893e-4
767
768
769
770
771
773 4. XML Schema
775
782
783
786 Global Positioning System (GPS) Schema for GRIP
787
788
789
791 This document defines assistance data for GPS.
792
793
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
820
821
822
823
824
826
827
828
829
830
831
832
833
834
835
836
837
839
840
841
843
844
845
846
847
849
850
851
852
853
854
855
856
857
858
860
861
862
863
864
865
866
867
868
870
871
873
874
875
876
878
879
880
881
882
883
884
885
886
888
889
890
891
892
893
894
895
896
897
898
899
901
902
903
904
905
906
907
910
911
912
913
915
916
917
918
919
920
922
924
926
928
929
931
932
933
934
935
937
938
939
940
942
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
997
998
999
1000
1001
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1016
1017
1018
1019
1020
1021
1022
1023
1025
1026
1028
1029
1030
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1060
1061
1062
1063
1064
1066
1067
1068
1069
1070
1071
1072
1075
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1090
1091
1092
1094
1095
1096
1097
1098
1099
1100
1102
1103
1104
1105
1107
1108
1109
1110
1111
1112
1115
1116
1117
1118
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1142
1143
1144
1145
1146
1147
1148
1149
1152
1153
1154
1155
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1170
1171
1172
1174
1175
1177
1178
1179
1180
1181
1182
1183
1184
1186
1187
1188
1189
1191
1192
1193
1194
1195
1196
1197
1198
1199
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1214
1216 5. Security Considerations
1218 This document is subject to the security considerations described in
1219 [I-D.thomson-geopriv-grip].
1221 6. IANA Considerations
1223 The XML namespace used for GPS assistance data is registered in
1224 Section 6.1, the corresponding schema definition is registered in
1225 Section 6.2.
1227 6.1. URN Sub-Namespace Registration for
1228 'urn:ietf:params:xml:ns:grip:gps'
1230 This section registers a new XML namespace,
1231 "urn:ietf:params:xml:ns:grip:gps", per the guidelines in [RFC3688].
1233 URI: urn:ietf:params:xml:ns:grip:gps
1235 Registrant Contact: IETF, GEOPRIV working group,
1236 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
1238 XML:
1240 BEGIN
1241
1242
1244
1245
1246 GPS Assistance Data
1247
1248
1249 # Namespace for GPS Assistance Data Definitions

1250 ## urn:ietf:params:xml:ns:grip:gps

1251 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
1252 with the RFC number for this specification.]
1253 See RFCXXXX

1254
1255
1256 END
1258 6.2. XML Schema Registration
1260 This section registers an XML schema as per the guidelines in
1261 [RFC3688].
1263 URI: urn:ietf:params:xml:schema:grip:gps
1265 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
1266 Martin Thomson (martin.thomson@andrew.com).
1268 Schema: The XML for this schema can be found as the entirety of
1269 Section 4 of this document.
1271 7. Acknowledgements
1273 This document is part of the definition of GRIP. The original GRIP
1274 protocol was developed by the University of New South Wales through
1275 the OSGRS project . The GPS expertise
1276 of Neil Harper was invaluable in assembling this document.
1278 8. References
1280 8.1. Normative References
1282 [RFC2119] Bradner, S., "Key words for use in
1283 RFCs to Indicate Requirement Levels",
1284 BCP 14, RFC 2119, March 1997.
1286 [RFC3688] Mealling, M., "The IETF XML
1287 Registry", BCP 81, RFC 3688,
1288 January 2004.
1290 [RFC5962] Schulzrinne, H., Singh, V.,
1291 Tschofenig, H., and M. Thomson,
1292 "Dynamic Extensions to the Presence
1293 Information Data Format Location
1294 Object (PIDF-LO)", RFC 5962,
1295 September 2010.
1297 [GPS-IS-200] GPS Navstar Joint Program Office,
1298 "Navstar GPS Space Segment /
1299 Navigation User Interfaces",
1300 Interface Specification IS-GPS-200D,
1301 December 2004.
1303 8.2. Informative References
1305 [I-D.thomson-geopriv-grip] Thomson, M., "Global Navigation
1306 Satellite System (GNSS) Reference
1307 Information Protocol (GRIP)",
1308 draft-thomson-geopriv-grip-02 (work
1309 in progress), Jun 2011.
1311 [W3C.REC-xmlschema-1-20010502] Maloney, M., Thompson, H.,
1312 Mendelsohn, N., and D. Beech, "XML
1313 Schema Part 1: Structures", World
1314 Wide Web Consortium FirstEdition REC-
1315 xmlschema-1-20010502, May 2001, .
1319 Author's Address
1321 Martin Thomson
1322 Andrew Corporation
1323 Andrew Building (39)
1324 Wollongong University Campus
1325 Northfields Avenue
1326 Wollongong, NSW 2522
1327 AU
1329 Phone: +61 2 4221 2915
1330 EMail: martin.thomson@andrew.com