GEOPRIV M. Thomson Internet-Draft Andrew Corporation Intended status: Experimental July 27, 2009 Expires: January 28, 2010 Global Navigation Satellite System (GNSS) Reference Information Protocol (GRIP) - Global Positioning System (GPS) Assistance Data draft-thomson-geopriv-grip-gps-00 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 28, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines assistance data formats for the Global Positioning System (GPS). These formats can be used with the Global Thomson Expires January 28, 2010 [Page 1] Internet-Draft GRIP GPS July 2009 Navigation Satellite System (GNSS) Reference Information Protocol (GRIP) by a GPS receiver to acquire assistance data. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 2.2. Angular Measures . . . . . . . . . . . . . . . . . . . . . 4 2.3. Polynomial Expressions . . . . . . . . . . . . . . . . . . 4 2.4. Reference Time . . . . . . . . . . . . . . . . . . . . . . 5 3. GPS Assistance Data Types . . . . . . . . . . . . . . . . . . 6 3.1. UTC Model . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Navigation Model . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Navigation Model Clock Model . . . . . . . . . . . . . 10 3.2.2. Navigation Model Orbital Model . . . . . . . . . . . . 10 3.2.3. Example Navigation Model . . . . . . . . . . . . . . . 12 3.3. Ionosphere Model . . . . . . . . . . . . . . . . . . . . . 12 3.4. Acquisition Assistance . . . . . . . . . . . . . . . . . . 13 3.5. Differential GPS Corrections . . . . . . . . . . . . . . . 14 3.6. Almanac . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.7. Extended Navigation Model . . . . . . . . . . . . . . . . 16 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6.1. URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:grip:gps' . . . . . . . . . . . . 27 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 Thomson Expires January 28, 2010 [Page 2] Internet-Draft GRIP GPS July 2009 1. Introduction The Global Positioning System (GPS) is a navigation system that provides the means to determine the location of a receiver in space and time with high accuracy. With a large number of satellites, it is the most widely use Global Navigation Satellite System (GNSS). Server-assisted GPS provides a number of advantages including reducing the time required to measure satellites and the time required to obtain the information necessary to calculate a position. This document defines a series of XML elements that, in combination with the GNSS Reference Information Protocol (GRIP) protocol [I-D.thomson-geopriv-grip], can be used to provide a receiver with assistance data. Readers of this document are warned that detailed knowledge of GPS is likely necessary to understand this document. It is intended that this document be read in conjunction with the GPS Interface Control Document (ICD) [GPS-ICD], which defines all the significant parameters. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The GPS Interface Control Document (ICD) [GPS-ICD] describes the navigation message and the parameters contained therein. This document does not repeat definitions and it cannot be interpreted without reference to the GPS ICD. Only enough information is provided to unambiguously identify the corresponding variable in the ICD. 2.1. Notational Conventions In naming parameters, the GPS ICD frequently uses mathematical symbols and characters that cannot be represented in this document format. In particular, Greek characters are used to represent many parameters. The following conventions are used in this document to aid in correlating the two texts: o This document uses the full English name of the character (for instance, the argument of periapsis is represented by the Greek letter "omega"). Thomson Expires January 28, 2010 [Page 3] Internet-Draft GRIP GPS July 2009 o The case of English names follows the case of the Greek character. Uppercase Greek characters are represented in full uppercase (e.g., the longitude of the ascending node is represented by the Greek letter "OMEGA"). o Difference variables, which are represented as a character preceded by the Greek letter delta, are expressed in the same manner, with a hypen separating the delta from the variable definition (e.g., the mean motion difference from computed value is represented as "DELTA-n"). o Subscripts on symbols are represented using square brackets (e.g., the reference time used in satellite clock correction is represented by "t[ot]"). o Variables that represent a time rate of change, shown in the ICD with a small dot above the character are succeeded by the string "dot" using consistent case (e.g., the rate of right ascension is represented by "OMEGADOT"). o The following mathematical operators are used: add "+", subtract "-", multiply "*", divide "/", and power "^". Spaces are used to separate these from identifiers in cases where it might otherwise be ambiguous. o The following mathematical functions are represented by common abbreviations: square root "sqrt", sine "sin", and cosine "cos". 2.2. Angular Measures The formats described in this document are expressed in units of radians, not semi-circles. When converting, it is important to use the same approximation for the mathematical constant pi as is used by all GPS systems. Using this approximation ensures that the assistance data is generated and applied using the same values. The fixed approximation for pi used in GPS is 3.1415926535898 [GPS-ICD]. 2.3. Polynomial Expressions The GPS navigation message is updated infrequently, but it models values that change over time. Thus, the message includes values that model how values change over time. Many values in GPS assistance data are expressed with a base value that is set at a particularly point in time, plus a value for therate of change of that value in time. Some values are further expressed Thomson Expires January 28, 2010 [Page 4] Internet-Draft GRIP GPS July 2009 with coefficients for the rate of change of the rate of change. In other words, values are expressed as a polynomial function in terms of time. This extends to other values, such as those in the Ionosphere Model that change depending on longitude. In the GPS navigation message, the Ionosphere model has four polynomial terms, allowing for a more complex model of ionosphere effects across different longitudes. This document uses a generalized model for univariate polynomial expressions. These expressions are used extensively. Each element that includes a polynomial expression rather than a fixed value includes the definition of the target value (and its units) plus the input variable (and its units). Polynomial expressions are expressed as simple lists in XML schema, or a space-separated sequence of numbers. The first value in the list is the constant express; the second value is the first order term; the nth value is the coefficient of the (n-1)th power of the input, giving: value(x) = sum from i=1..n of p[i]*x^(i-1) Polynomials can be any length, but since every term needs to be considered when the input variable is anything other than zero, receivers MAY limit their support to as many coefficients as are included in the GPS navigation message. The mandatory number of supported coefficients is included in the definition of polynomials. For instance, the polynomial expression "4 5 6" with an input value of 2 produces: 4 + 5 * 2 + 6 * 2 ^ 2 = 38. 2.4. Reference Time Where the input variable to a polynomial expression is time, a reference value is commonly used. The input to the polynomial expression is the difference between the current (or applicable) time and the reference time. The value for reference time is usually provided as a separate element in these cases and this element is identified in the definition of the polynomial expression. The "tow" element provides a reference time for assistance data that requires a reference. This element includes the GPS time of week in milliseconds to use as a reference. The input variable to time-based polynomials is the difference between the current time and the reference time. A GPS week has 604800000 (6.048e8) milliseconds. Unless specified Thomson Expires January 28, 2010 [Page 5] Internet-Draft GRIP GPS July 2009 explicitly, reference time is specified within half a week (3.024e8ms) of the time that assistance data is created. The GPS ICD [GPS-ICD] describes how to accomodate week rollovers into calculations of time differences. Alternatively, an explicit GPS week number can be indicated in the "week" attribute of the "tow" element. Note that GPS week rollovers also occur ever 1024 weeks (approximately 20 years). 3. GPS Assistance Data Types This section defines assistance data types for GPS. The following definitions are provided: o UTC Model (Section 3.1) o Navigation Model (Section 3.2) o Ionosphere Model (Section 3.3) o Acquisition Assistance (Section 3.4) o Differential GPS Corrections (Section 3.5) o Almanac (Section 3.6) o Extended Navigation Model (Section 3.7) 3.1. UTC Model The UTC model contains information on the relationship between Coordinated Universal Time (UTC) time and GPS time. The UTC model is always global. tow: The tow (Section 2.4) element includes a the reference time value (t[ot]). offset: A polynomial in time for the time offset between GPS time and UTC time. This produces a value in seconds. Two values are required, which correspond to A[0] and A[1]. leapsec: UTC occasionally introduces a leap second. GPS time does not. The "leapsec" element without attributes indicates the current number of leap seconds difference between the two time systems. Additional instances of the "leapsec" element may be provided to indicate when new leap seconds come into effect. The "week" and Thomson Expires January 28, 2010 [Page 6] Internet-Draft GRIP GPS July 2009 "day" attributes respectively indicate the week and day that the included value is introduced. The following example shows an instance of the UTC model in XML form, including information on the introduction of a new leap second: 436559 0.76014e-4 -0.21722e-12 14 15 3.2. Navigation Model The "navigation" element contains the navigation model, information on the clock and position of each satellite. The navigation model is specific to a satellite and forms the bulk of the information transmitted by a satellite. Navigation model data can be global or local. Global data contains information for all satellites; local data contains on those satellites that can be seen from the input location. Multiple "satellite" elements are included in the navigation model, each containing the information for a single satellite. If the information is local, only relevant satellites are included. Each satellite included in the set is identified by number in the "number" attribute. The "satellite" element for navigation model has the following elements: ura: User Range Accuracy (URA) includes an estimation of the net error in pseudorange measurements from this satellite, in meters. This value MAY be set to "INF", indicating that no accuracy prediction is available and that the satellite is not suitable for use. INF corresponds to a value of 15 in the transmitted navigation message. health: The health of the satellite and the signals that it transmits. The bit map from the ICD is represented in the value of this element and the value of the "bad" and "signals" attributes. Thomson Expires January 28, 2010 [Page 7] Internet-Draft GRIP GPS July 2009 The following values for the "bad" attribute relate to all of the navigation data: none: No data is bad (default value) parity: Some or all of the parity is bad tlm-how: The TLM or HOW is bad, apart from the Z-count z-count: The Z-count is bad sf123: Some or all data in subframes 1 through 3 is bad sf45: Some or all data in subframes 4 and 5 is bad most: Some or all data in any subframe is bad, excluding the TLM/ HOW all: Some or all data in any subframe is bad, including TLM/HOW The "signals" attribute identifies specific signals that might be affected: L1P: The L1P signal L1C: The L1C signal L1: Both L1P and L1C signals L2P: The L2P signal L2C: The L2C signal L2: Both L2P and L2C signals all: All signals The following values for the element describe problems with the identified signals, or with the entire satellite: ok: All signals are OK weak: The identified signal is weak dead: The identified signal is dead Thomson Expires January 28, 2010 [Page 8] Internet-Draft GRIP GPS July 2009 nodata: The identified signal has no data modulation out: The entire satellite is temporarily out of service soonout: The entire satellite will soon be out of service spare: Unknown, reserved value combination: Multiple errors that require a combination of indications l2codes: A space separated list identifying which codes (C/A or P) are transmitted on the L2 signal. This MAY be empty. The "pdata" flag is set to "true" if the L2P signal contains data (note that this is indicated with a bit value of 0 in the GPS navigation message). sf1reserved: A hexadecimal representation of the 87 reserved bits from subframe 1. This value is padded with a zero bit at the start of the sequence. aodo: The age of data offset, in seconds. A value of "INF" corresponds to the maximum value from the GPS signal (27900) and indicates that the navigation message correction table (NMCT) cannot be used. clock: Parameters that model the satellite clock. These are described below. ephemeris: Satellite orbital parameters, or ephemeris. These are described below. The"iod" attribute contains the Issue Of Data, Clock (IODC) value from the navigation message. The lower 8 bits of this 10 bit value indicate the Issue of Data, Ephemeris (IODE). This is only included if the information is derived from the navigation message broadcast by the satellite. Servers MAY choose not to include navigation model information for satellites that have a URA of "INF" or bad health when providing local assistance data. The "health", "l2codes", "sf1reserved" and "aodo" elements contain information that might not be relevant to some receivers. These elements are optional, and MUST be omitted if the information provided is not directly taken from the navigation message broadcast by the satellite. This ensures that when present these values can be used by a receiver to compansate for the effect of navigation message Thomson Expires January 28, 2010 [Page 9] Internet-Draft GRIP GPS July 2009 modulation on the signal it receives. 3.2.1. Navigation Model Clock Model The "clock" element of the satellite navigation model contains information on the clock in the satellite. tow: The tow (Section 2.4) element includes a the reference time value (t[oc]). groupdelay: The group delay differential (T[GD]), used in calculating time offsets in single frequency receivers. This is a value in seconds. offset: A polynomial expression in time, modelling the difference between the satellite time and GPS time. This produces a value in seconds. Three values are required, which correspond to a[f0] a[f1] and a[f2]. 3.2.2. Navigation Model Orbital Model The "ephemeris" element of the satellite navigation model contains information on the orbit of the satellite. tow: The tow (Section 2.4) element includes the epehemeris reference time (t[oe]). semiMajor: The size of the semi-major axis of the satellite orbit, in meters (A). The navigation message includes the square root of this value in A^(1/2). eccentricity: The eccentricity of the satellite orbit (e), which is dimensionless. longitude: A polynomial espression in time for the longitude of the ascending node. This produces a value in radians. Two values are required, which correspond to OMEGA[g] and OMEGADOT[g]. Note that this deviates from the navigation message, which includes the longitude of the ascending node at weekly epoch (OMEGA[0]) and the rate of right ascension (OMEGADOT). The values used are derived as follows: OMEGA[g] = OMEGA[0] - OMEGADOT[e] * t[oe] OMEGADOT[g] = OMEGADOT - OMEGADOT[e] Where the constant OMEGADOT[e] is 7.2921151467e-5 radians/second. This polynomial expression is applied using: Thomson Expires January 28, 2010 [Page 10] Internet-Draft GRIP GPS July 2009 OMEGA[k] = OMEGA + OMEGADOT[g] * t[k] inclination: A polynomial espression in time for the angle of inclination. This produces a value in radians. Two values are required, which correspond to i[0] and idot. periapsis: A polynomial espression in time for the argument of periapsis. This produces a value in radians. One value is required, which corresponds to omega. anomaly: A polynomial espression in time for the mean Keplerian anomaly. This produces a value in radians. Two values are required, which correspond to M[0] and n. The value of n is derived from DELTA-n using the following expression: n = n[0] + DELTA-n harmonicCorrection: This element contains harmonic correction values for the argument of latitude, the orbit radius and the angle of inclination. Each is expressed as a list with two terms. The first term contains the amplitude of the cosine harmonic correction; the second term contains the amplitude of the sine harmonic correction. The following harmonic correction values are provided: latitude: The amplitude of harmonic correction for the argument of latitude, corresponding to C[uc] and C[us]. radius: The amplitude of harmonic correction for the orbit radius, corresponding to C[rc] and C[rs]. inclination: The amplitude of harmonic correction for the angle of inclination, corresponding to C[ic] and C[is]. The "fit4hr" indicates whether the model is fit over the standard period of 4 hours. If false, the model is based on a longer time frame. Thomson Expires January 28, 2010 [Page 11] Internet-Draft GRIP GPS July 2009 3.2.3. Example Navigation Model The following example shows an instance of the navigation model in XML form, including a single satellite only: 4.85 ok p 180f7e3aaa2a7062c8d3a2 7200 436559 3.949e-9 8.034e-9 -2.209e-10 9.17e-14 436559 6.15861e5 0.98519 2.10554 -4.674e-9 0.02469827347 -1.265e-9 0.978932 0.122742 0.366697e-8 -0.6958e-4 -0.7828e-4 0.7604e-4 0.3125e-4 0.437e-4 0.6893e-4 3.3. Ionosphere Model The "ionosphere" contains a model of the signal transmission delays introduced by the Earths ionosphere. The ionosphere model is always global. vdelay: A polynomial expression in latitude for the vertical delay imposed by the ionosphere. This produces a value in seconds. Four values are required, which correspond to alpha[0] through alpha[3]. Thomson Expires January 28, 2010 [Page 12] Internet-Draft GRIP GPS July 2009 period: A polynomial expression in latitude for the period of the ionosphere model. This produces a value in seconds. Four values are required, which correspond to beta[0] through beta[3]. The following example shows an instance of the ionosphere model in XML form: 1.23e-7 1.1819e-6 1.167e-5 1.16e-6 7.445e4 3.188e6 1.34e7 1.188e7 3.4. Acquisition Assistance The "acqAssist" element contains an estimate of the measurement a receiver is expected to make at a specified location. Acquisition assistance is always local. The "tow" element includes the reference time used in constructing the acquisition assistance. The "satellite" element for acquisition assistance has the following elements: rtow: An estimate of satellite time as seen by the receiver at the reference time. This can be used to gain an estimate of the range. codephase: An estimate of the code phase at the receiver at the given time. The "uncertainty" element includes an estimate of the error in this estimate, at 95% confidence. doppler: An estimate of the frequency shift due to the Doppler effect at the receiver at the given time. The "uncertainty" element includes an estimate of the error in this estimate, at 95% confidence. direction: The direction of the satellite from the receiver, using the directional notation from [I-D.singh-geopriv-pidf-lo-dynamic]. The first value is horizontal azimuth from Northing to Easting, the optional second value is elevation above (or below) the plane of the horizontal. Thomson Expires January 28, 2010 [Page 13] Internet-Draft GRIP GPS July 2009 The following example shows an instance of acquisition assistance in XML form, including a single satellite only: 436559 436480 147 1020 0.309 28 38.71 3.5. Differential GPS Corrections The "dgps" element contains an estimate of the pseudorage measurement error. Differential GPS corrections are generated by fixed receivers, which are able to compensate for errors that are not accounted for in other GPS data. Because this information degrades quickly as the distance from the fixed receiver increases, differential GPS corrections are always local. The "tow" element includes the reference time used in the differential GPS corrections. The "satellite" element for acquisition assistance has a single "range" element. This contains a polynomial expression in time for the range correction. At least two coefficients are required. The "uncertainty" element includes an estimate of the remaining error in this estimate, at 95% confidence. The following example shows an instance of differential GPS corrections in XML form, including a single satellite only: 436559 0.623 0.5e-3 3.6. Almanac The "almanac" element contains long term information about satelite clock and orbit. Almanac data is always global. In the navigation message, almanac data is a simplified, low accuracy version of the navigation model. In this XML representation, the Thomson Expires January 28, 2010 [Page 14] Internet-Draft GRIP GPS July 2009 data MAY include additional information in the provided fields, providing that the model remains usable over a period equivalent to that of the almanac in the navigation message (182 days). Almanac is of limited use when a navigation model is available. All satellites transmit this information, so global information is available even where the region covered by the server is not global. Receivers use almanac to provide a rough indication of satellite location after a long period where the receiver does not update other data. The "satellite" element contains per-satellite almanac data. The "healthy" attribute identifies whether the satellite is currently fit for use; a value of "false" indicates the presence of a problem. The "healthy" attribute can be omitted if the satellite is healthy. The "satellite" element contains the following elements: tow: The reference time for the almanac data. clockOffset: A polynomial expression for clock offset, containing information identical to that in the "offset" element from Section 3.2.1. semiMajor: The semi-major axis of the orbit. Identical in definition to the same element in Section 3.2.2. eccentricity: The eccentricity of the orbit. Identical in definition to the same element in Section 3.2.2. longitude: The longitude of the ascending node. Similar to the same element in Section 3.2.2, with the exception that only one coefficient is required. inclination: The inclination angle. Similar to the same element in Section 3.2.2, with the exception that only one coefficient is required. periapsis: The argument of periapsis. Similar to the same element in Section 3.2.2, with the exception that only one coefficient is required. anomaly: The mean Keplerian anomaly. Similar to the same element in Section 3.2.2, with the exception that only one coefficient is required. Thomson Expires January 28, 2010 [Page 15] Internet-Draft GRIP GPS July 2009 The following example shows an instance of the almanac in XML form, including a single satellite only: 436559 8.034e-9 -2.209e-10 6.15861e5 0.98519 2.10554 0.02469827347 0.978932 0.122742 3.7. Extended Navigation Model The extended navigation model allows for predictions of ephemeris over a longer period of time than might be allowed for with the basic navigation model. For many parameters, a curve fit using a polynomial with a limited number of coefficients only works for a short time. While data might be sufficiently accurate within the curve fit interval, outside this interval the data becomes increasingly inaccurate. Extended navigation model data is always global. The "extNavigation" element includes multiple predictions for satellite clock and ephemeris. These are predictions of future state, based on more elaborate models that the server might maintain. Each prediction has a specific period of time that it is valid for. Thus, a receiver is able to use a new model as the previous model expires. The "extNavigation" element contains multiple "estimate" elements, each of which contains the a complete model, plus an indication of when the model is predicted to be valid. The "validity" element includes two GPS time of week (Section 2.4) elements, "start" and "end", that respectively indicate when the estimate becomes valid and when it becomes invalid. Each "satellite" element then contains a clock model (Section 3.2.1) and an orbit model (Section 3.2.2). Scheduled events might occur that cause predictions about certain satellites to become invalid. The server MUST omit predictions for Thomson Expires January 28, 2010 [Page 16] Internet-Draft GRIP GPS July 2009 affected satellite from the affected period onwards. The following example shows an instance of extended navigation model data in XML form, including a single estimate and a single satellite only: 872465 1066134 872465 3.949e-9 8.034e-9 -2.209e-10 9.17e-14 872465 6.15861e5 0.98519 2.10554 -4.674e-9 0.02469827347 -1.265e-9 0.978932 0.122742 0.366697e-8 -0.6958e-4 -0.7828e-4 0.7604e-4 0.3125e-4 0.437e-4 0.6893e-4 4. XML Schema Thomson Expires January 28, 2010 [Page 17] Internet-Draft GRIP GPS July 2009 Global Positioning System (GPS) Schema for GRIP This document defines assistance data for GPS. Thomson Expires January 28, 2010 [Page 18] Internet-Draft GRIP GPS July 2009 Thomson Expires January 28, 2010 [Page 19] Internet-Draft GRIP GPS July 2009 Thomson Expires January 28, 2010 [Page 20] Internet-Draft GRIP GPS July 2009 Thomson Expires January 28, 2010 [Page 21] Internet-Draft GRIP GPS July 2009 Thomson Expires January 28, 2010 [Page 22] Internet-Draft GRIP GPS July 2009 Thomson Expires January 28, 2010 [Page 23] Internet-Draft GRIP GPS July 2009 Thomson Expires January 28, 2010 [Page 24] Internet-Draft GRIP GPS July 2009 Thomson Expires January 28, 2010 [Page 25] Internet-Draft GRIP GPS July 2009 5. Security Considerations This document is subject to the security considerations described in [I-D.thomson-geopriv-grip]. Thomson Expires January 28, 2010 [Page 26] Internet-Draft GRIP GPS July 2009 6. IANA Considerations The XML namespace used for GPS assistance data is registered in Section 6.1, the corresponding schema definition is registered in Section 6.2. 6.1. URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:grip:gps' This section registers a new XML namespace, "urn:ietf:params:xml:ns:grip:gps", per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:grip:gps Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). XML: BEGIN GPS Assistance Data

Namespace for GPS Assistance Data Definitions

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

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

See RFCXXXX

END 6.2. XML Schema Registration This section registers an XML schema as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:grip:gps Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). Thomson Expires January 28, 2010 [Page 27] Internet-Draft GRIP GPS July 2009 Schema: The XML for this schema can be found as the entirety of Section 4 of this document. 7. Acknowledgements This document is part of the definition of GRIP. The original GRIP protocol was developed by the University of New South Wales through the OSGRS project . The GPS expertise of Neil Harper was invaluable in assembling this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [GPS-ICD] "Navstar GPS Space Segment / Navigation User Interfaces", ICD-GPS-200c, April 2000. [I-D.singh-geopriv-pidf-lo-dynamic] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", dra ft-singh-geopriv-pidf-lo- dynamic-06 (work in progress), June 2009. 8.2. Informative References [I-D.thomson-geopriv-grip] Thomson, M., "Global Position System (GPS) Assistance Data for GRIP", draft-thomson-geopriv- grip-gps-00 (work in progress), Jul 2009. [W3C.REC-xmlschema-1-20010502] Thompson, H., Mendelsohn, N., Maloney, M., and D. Beech, "XML Schema Part 1: Structures", World Wide Web Consortium FirstE Thomson Expires January 28, 2010 [Page 28] Internet-Draft GRIP GPS July 2009 dition REC-xmlschema-1-20010502, May 2001, . Author's Address Martin Thomson Andrew Corporation PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2915 EMail: martin.thomson@andrew.com URI: http://www.andrew.com/ Thomson Expires January 28, 2010 [Page 29]