TOC 
GEOPRIVM. Thomson
Internet-DraftAndrew Corporation
Intended status: ExperimentalMarch 05, 2010
Expires: September 6, 2010 


Global Navigation Satellite System (GNSS) Reference Information Protocol (GRIP) - Global Positioning System (GPS) Assistance Data
draft-thomson-geopriv-grip-gps-01

Abstract

This document defines assistance data formats for the Global Positioning System (GPS). These formats can be used with the Global Navigation Satellite System (GNSS) Reference Information Protocol (GRIP) by a GPS receiver to acquire assistance data.

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 September 6, 2010.

Copyright Notice

Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.



Table of Contents

1.  Introduction
2.  Conventions used in this document
    2.1.  Notational Conventions
    2.2.  Angular Measures
    2.3.  Polynomial Expressions
    2.4.  Expressing Reference Time
3.  GPS Assistance Data Types
    3.1.  UTC Model
    3.2.  Navigation Model
        3.2.1.  Navigation Model Clock Model
        3.2.2.  Navigation Model Orbital Model
        3.2.3.  Example Navigation Model
    3.3.  Ionosphere Model
    3.4.  Acquisition Assistance
    3.5.  Differential GPS Corrections
    3.6.  Almanac
    3.7.  Extended Navigation Model
4.  XML Schema
5.  Security Considerations
6.  IANA Considerations
    6.1.  URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:grip:gps'
    6.2.  XML Schema Registration
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References




 TOC 

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 used Global Navigation Satellite System (GNSS).

Server-assisted GPS provides a number of advantages including reducing the time required to measure satellites; reducing the time required to obtain the information necessary to calculate a position; and improving the ability of a receiver to successfully measure satellites in low signal conditions.

This document defines a series of XML elements that, in combination with the GNSS Reference Information Protocol (GRIP) protocol (Thomson, M., “Global Position System (GPS) Assistance Data for GRIP,” Jul 2009.) [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 Specification (GPS Navstar Joint Program Office, “Navstar GPS Space Segment / Navigation User Interfaces,” December 2004.) [GPS‑IS‑200], which defines all the significant parameters.



 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

The GPS Interface Specification (GPS Navstar Joint Program Office, “Navstar GPS Space Segment / Navigation User Interfaces,” December 2004.) [GPS‑IS‑200] 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 Interface Specification. Only enough information is provided to unambiguously identify the corresponding variable in the Interface Specification.



 TOC 

2.1.  Notational Conventions

In naming parameters, the GPS Interface Specification 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:



 TOC 

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‑IS‑200] (GPS Navstar Joint Program Office, “Navstar GPS Space Segment / Navigation User Interfaces,” December 2004.).



 TOC 

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 the rate of change of that value in time. Some values are further expressed 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 expression; 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.



 TOC 

2.4.  Expressing 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 explicitly, reference time is specified within half a week (3.024e8ms) of the time that assistance data is created. The GPS Interface Specification (GPS Navstar Joint Program Office, “Navstar GPS Space Segment / Navigation User Interfaces,” December 2004.) [GPS‑IS‑200] 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).



 TOC 

3.  GPS Assistance Data Types

This section defines assistance data types for GPS. The following definitions are provided:



 TOC 

3.1.  UTC Model

The UTC model contains information on the relationship between Coordinated Universal Time (UTC) time and GPS time. The realization of the UTC model used in GPS is the US Naval Observatory realization: UTC(USNO). The UTC model is always global.

tow:
The tow (Expressing Reference Time) 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 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:

  <utc xmlns="urn:ietf:params:xml:ns:grip:gps">
    <tow week="477">436559</tow>
    <offset>0.76014e-4 -0.21722e-12</offset>
    <leapsec>14</leapsec>
    <leapsec week="2" day="3">15</leapsec>
  </utc>


 TOC 

3.2.  Navigation Model

The navigation element contains the navigation model, information on the clock and position of each satellite, plus satellite status information. 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 Interface Specification is represented in the value of this element and the value of the bad and signals attributes.
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
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.

Theiod 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 modulation on the signal it receives.



 TOC 

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 (Expressing Reference Time) 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].



 TOC 

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 (Expressing Reference Time) 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:
    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.



 TOC 

3.2.3.  Example Navigation Model

The following example shows an instance of the navigation model in XML form, including a single satellite only:

  <navigation xmlns="urn:ietf:params:xml:ns:grip:gps">
    <satellite number="12" iod="75">
      <ura>4.85</ura>
      <health bad="none" signals="all">ok</health>
      <l2codes pdata="true">p</l2codes>
      <sf1reserved>180f7e3aaa2a7062c8d3a2</sf1reserved>
      <aodo>7200</aodo>
      <clock>
        <tow week="477">436559</tow>
        <groupdelay>3.949e-9</groupdelay>
        <offset>8.034e-9 -2.209e-10 9.17e-14</offset>
      </clock>
      <ephemeris fit4hr="true">
        <tow week="477">436559</tow>
        <semiMajor>6.15861e5</semiMajor>
        <eccentricity>0.98519</eccentricity>
        <longitude>2.10554 -4.674e-9</longitude>
        <inclination>0.02469827347 -1.265e-9</inclination>
        <periapsis>0.978932</periapsis>
        <anomaly>0.122742 0.366697e-8</anomaly>
        <harmonicCorrection>
          <latitude>-0.6958e-4 -0.7828e-4</latitude>
          <radius>0.7604e-4 0.3125e-4</radius>
          <inclination>0.437e-4 0.6893e-4</inclination>
        </harmonicCorrection>
      </ephemeris>
    </satellite>
  </navigation>


 TOC 

3.3.  Ionosphere Model

The ionosphere contains a model of the signal transmission delays introduced by the Earths ionosphere. Alternative models are available, but this element uses the Klobuchar model that is broadcast in the satellite navigation message. 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].
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:

  <ionosphere xmlns="urn:ietf:params:xml:ns:grip:gps">
    <vdelay>1.23e-7 1.1819e-6 1.167e-5 1.16e-6</vdelay>
    <period>7.445e4 3.188e6 1.34e7 1.188e7</period>
  </ionosphere>


 TOC 

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. This value is in units of whole chips (equivalent to 1/1023 milliseconds). 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. This value is in units of Hertz. The uncertainty element includes an estimate of the error in this estimate, at 95% confidence.
direction:
The direction of the satellite from the centroid of the provided location, using the directional notation from [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),” March 2010.). The first value is horizontal azimuth from Northing to Easting, the optional second value is elevation above (or below) the plane of the horizontal.

The following example shows an instance of acquisition assistance in XML form, including a single satellite only:

  <acqAssist xmlns="urn:ietf:params:xml:ns:grip:gps">
    <tow week="477">436559</tow>
    <satellite number="12">
      <rtow>436480</rtow>
      <codephase uncertainty="56">147</codephase>
      <doppler uncertainty="25">1020 0.309</doppler>
      <direction>28 38.71</direction>
    </satellite>
  </acqAssist>


 TOC 

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 differential corrections 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:

  <dgps xmlns="urn:ietf:params:xml:ns:grip:gps">
    <tow week="477">436559</tow>
    <satellite number="12">
      <range uncertainty="0.2">0.623 0.5e-3</range>
    </satellite>
  </dgps>


 TOC 

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 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 (Navigation Model Clock Model).
semiMajor:
The semi-major axis of the orbit. Identical in definition to the same element in Section 3.2.2 (Navigation Model Orbital Model).
eccentricity:
The eccentricity of the orbit. Identical in definition to the same element in Section 3.2.2 (Navigation Model Orbital Model).
longitude:
The longitude of the ascending node. Similar to the same element in Section 3.2.2 (Navigation Model Orbital Model), with the exception that only one coefficient is required.
inclination:
The inclination angle. Similar to the same element in Section 3.2.2 (Navigation Model Orbital Model), with the exception that only one coefficient is required.
periapsis:
The argument of periapsis. Similar to the same element in Section 3.2.2 (Navigation Model Orbital Model), with the exception that only one coefficient is required.
anomaly:
The mean Keplerian anomaly. Similar to the same element in Section 3.2.2 (Navigation Model Orbital Model), with the exception that only one coefficient is required.

The following example shows an instance of the almanac in XML form, including a single satellite only:

  <almanac xmlns="urn:ietf:params:xml:ns:grip:gps">
    <satellite number="12" healthy="true">
      <tow week="477">436559</tow>
      <clockOffset>8.034e-9 -2.209e-10</clockOffset>
      <semiMajor>6.15861e5</semiMajor>
      <eccentricity>0.98519</eccentricity>
      <longitude>2.10554</longitude>
      <inclination>0.02469827347</inclination>
      <periapsis>0.978932</periapsis>
      <anomaly>0.122742</anomaly>
    </satellite>
  </almanac>


 TOC 

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 (Expressing Reference Time) 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 (Navigation Model Clock Model) and an orbit model (Navigation Model Orbital Model).

Scheduled events might occur that cause predictions about certain satellites to become invalid. The server MUST omit predictions for 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:

  <extNavigation xmlns="urn:ietf:params:xml:ns:grip:gps">
    <estimate>
      <validity>
        <start week="477">872465</start>
        <end week="477">1066134</end>
      </validity>
      <satellite number="12">
        <clock>
          <tow week="477">872465</tow>
          <groupdelay>3.949e-9</groupdelay>
          <offset>8.034e-9 -2.209e-10 9.17e-14</offset>
        </clock>
        <ephemeris>
          <tow week="477">872465</tow>
          <semiMajor>6.15861e5</semiMajor>
          <eccentricity>0.98519</eccentricity>
          <longitude>2.10554 -4.674e-9</longitude>
          <inclination>0.02469827347 -1.265e-9</inclination>
          <periapsis>0.978932</periapsis>
          <anomaly>0.122742 0.366697e-8</anomaly>
          <harmonicCorrection>
            <latitude>-0.6958e-4 -0.7828e-4</latitude>
            <radius>0.7604e-4 0.3125e-4</radius>
            <inclination>0.437e-4 0.6893e-4</inclination>
          </harmonicCorrection>
        </ephemeris>
      </satellite>
    </estimate>
  </extNavigation>


 TOC 

4.  XML Schema

<xs:schema
    targetNamespace="urn:ietf:params:xml:ns:grip:gps"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:gps="urn:ietf:params:xml:ns:grip:gps"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">

  <xs:annotation>
    <xs:appinfo
        source="urn:ietf:params:xml:schema:grip:gps">
      Global Positioning System (GPS) Schema for GRIP
    </xs:appinfo>
    <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
                           published RFC and remove this note.]] -->
      This document defines assistance data for GPS.
    </xs:documentation>
  </xs:annotation>

  <!-- Common types -->
  <xs:element name="tow" type="gps:towType"/>
  <xs:complexType name="towType">
    <xs:simpleContent>
      <xs:extension base="gps:towBaseType">
        <xs:attribute name="week" type="gps:weekType"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:simpleType name="towBaseType">
    <xs:restriction base="xs:nonNegativeInteger">
      <xs:maxExclusive value="604800000"/> <!-- 7*24*60*60*1000 -->
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="weekType">
    <xs:restriction base="xs:nonNegativeInteger">
      <xs:maxExclusive value="1024"/> <!-- 10 bits -->
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="dayType">
    <xs:restriction base="xs:positiveInteger">
      <xs:maxInclusive value="7"/> <!-- starts at 1 -->
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="nonNegativeDouble">
    <xs:restriction base="xs:double">
      <xs:minInclusive value="0.0"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="polyType">
    <xs:restriction base="gps:polyBaseType">
      <xs:minLength value="1"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="polyBaseType">
    <xs:list itemType="xs:double"/>
  </xs:simpleType>

  <xs:complexType name="polyUncType">
    <xs:simpleContent>
      <xs:extension base="gps:polyType">
        <xs:attribute name="uncertainty"
                      type="gps:nonNegativeDouble"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name="perSatelliteBaseType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="satellite" type="gps:satelliteBaseType"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="perSatelliteTowType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element ref="gps:tow"/>
          <xs:element name="satellite" type="gps:satelliteBaseType"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="satelliteBaseType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:any namespace="##any" processContents="strict"
                  minOccurs="1" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="number" type="xs:nonNegativeInteger"
                      use="required"/>
        <xs:anyAttribute namespace="##any" processContents="strict"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <!-- UTC -->
  <xs:element name="utc" type="gps:utcType"/>
  <xs:complexType name="utcType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element ref="gps:tow"/>
          <xs:element name="offset" type="gps:polyType"/>
          <xs:element name="leapsec" type="gps:leapsecType"
                      minOccurs="1" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="leapsecType">
    <xs:simpleContent>
      <xs:extension base="xs:integer">
        <xs:attribute name="week" type="gps:weekType"/>
        <xs:attribute name="day" type="gps:weekType"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <!-- Navigation Model -->
  <xs:element name="navigation" type="gps:navigationType"/>
  <xs:complexType name="navigationType">
    <xs:complexContent>
      <xs:restriction base="gps:perSatelliteBaseType">
        <xs:sequence>
          <xs:element name="satellite"
                      type="gps:navigationSatelliteType"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="navigationSatelliteType">
    <xs:complexContent>
      <xs:restriction base="gps:satelliteBaseType">
        <xs:sequence>
          <xs:element name="ura" type="gps:nonNegativeDouble"/>
          <xs:element name="health" type="gps:healthType"
                      minOccurs="0"/>
          <xs:element name="l2codes" type="gps:l2codesType"
                      minOccurs="0"/>
          <xs:element name="sf1reserved" type="gps:sf1reservedType"
                      minOccurs="0"/>
          <xs:element name="aodo" type="gps:nonNegativeDouble"
                      minOccurs="0"/>
          <xs:element ref="gps:clock"/>
          <xs:element ref="gps:ephemeris"/>
        </xs:sequence>
        <xs:attribute name="iod" type="gps:iodType"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="healthType">
    <xs:simpleContent>
      <xs:extension base="gps:healthBaseType">
        <xs:attribute name="bad" type="gps:healthBadType"
                      default="none"/>
        <xs:attribute name="signals" type="gps:healthSignalsType"
                      default="all"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:simpleType name="healthBaseType">
    <xs:restriction base="xs:token">
      <xs:enumeration value="ok"/>
      <xs:enumeration value="weak"/>
      <xs:enumeration value="dead"/>
      <xs:enumeration value="nodata"/>
      <xs:enumeration value="out"/>
      <xs:enumeration value="soonout"/>
      <xs:enumeration value="spare"/>
      <xs:enumeration value="combination"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="healthBadType">
    <xs:restriction base="xs:token">
      <xs:enumeration value="none"/>
      <xs:enumeration value="some"/>
      <xs:enumeration value="parity"/>
      <xs:enumeration value="tlm-how"/>
      <xs:enumeration value="all"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="healthSignalsType">
    <xs:restriction base="xs:token">
      <xs:enumeration value="L1"/>
      <xs:enumeration value="L1P"/>
      <xs:enumeration value="L1C"/>
      <xs:enumeration value="L2"/>
      <xs:enumeration value="L2P"/>
      <xs:enumeration value="L2C"/>
      <xs:enumeration value="all"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="l2codesType">
    <xs:simpleContent>
      <xs:extension base="gps:l2codesBaseType">
        <xs:attribute name="pdata" type="xs:boolean" use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:simpleType name="l2codesBaseType">
    <xs:list>
      <xs:simpleType>
        <xs:restriction base="xs:token">
          <xs:enumeration value="p"/>
          <xs:enumeration value="c/a"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:list>
  </xs:simpleType>

  <xs:simpleType name="sf1reservedType">
    <xs:restriction base="xs:hexBinary">
      <xs:pattern value="[0-7][\da-fA-F]{21}"/> <!-- 87 bits -->
    </xs:restriction>
  </xs:simpleType>

  <xs:element name="clock" type="gps:clockType"/>
  <xs:complexType name="clockType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element ref="gps:tow"/>
          <xs:element name="groupdelay" type="xs:double"/>
          <xs:element name="offset" type="gps:polyType"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="ephemeris" type="gps:ephemerisType"/>
  <xs:complexType name="ephemerisType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element ref="gps:tow"/>
          <xs:group ref="gps:keplerianOrbitBase"/>
          <xs:element name="harmonicCorrection"
                      type="gps:harmonicCorrectionType"/>
        </xs:sequence>
        <xs:attribute name="fit4hr" type="xs:boolean"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:group name="keplerianOrbitBase">
    <xs:sequence>
      <xs:element name="semiMajor" type="gps:nonNegativeDouble"/>
      <xs:element name="eccentricity" type="gps:nonNegativeDouble"/>
      <xs:element name="longitude" type="gps:polyType"/>
      <xs:element name="inclination" type="gps:polyType"/>
      <xs:element name="periapsis" type="gps:polyType"/>
      <xs:element name="anomaly" type="gps:polyType"/>
    </xs:sequence>
  </xs:group>

  <xs:complexType name="harmonicCorrectionType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="latitude" type="gps:harmonicType"/>
          <xs:element name="radius" type="gps:harmonicType"/>
          <xs:element name="inclination" type="gps:harmonicType"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  <xs:simpleType name="harmonicType">
    <xs:restriction base="gps:polyType">
      <xs:length value="2"/> <!-- cosine sine -->
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="iodType">
    <xs:restriction base="xs:nonNegativeInteger">
      <xs:maxExclusive value="1024"/>
    </xs:restriction>
  </xs:simpleType>

  <!-- Almanac -->
  <xs:element name="almanac" type="gps:almanacType"/>
  <xs:complexType name="almanacType">
    <xs:complexContent>
      <xs:restriction base="gps:perSatelliteBaseType">
        <xs:sequence>
          <xs:element name="satellite"
                      type="gps:almanacSatelliteType"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="almanacSatelliteType">
    <xs:complexContent>
      <xs:restriction base="gps:satelliteBaseType">
        <xs:sequence>
          <xs:element ref="gps:tow"/>
          <xs:element name="clockOffset" type="gps:polyType"/>
          <xs:group ref="gps:keplerianOrbitBase"/>
        </xs:sequence>
        <xs:attribute name="healthy" type="xs:boolean"
                      default="true"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <!-- Extended Navigation -->
  <xs:element name="extNavigation" type="gps:extNavigationType"/>
  <xs:complexType name="extNavigationType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="estimate" type="gps:estimateType"
                      maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="estimateType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="validity" type="gps:validityType"/>
          <xs:element name="satellite"
                      type="gps:extNavigationSatelliteType"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="validityType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="start" type="gps:towType"/>
          <xs:element name="end" type="gps:towType"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="extNavigationSatelliteType">
    <xs:complexContent>
      <xs:restriction base="gps:satelliteBaseType">
        <xs:sequence>
          <xs:element ref="gps:clock"/>
          <xs:element ref="gps:ephemeris"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <!-- Acquisition Assistance -->
  <xs:element name="acqAssist" type="gps:acqAssistType"/>
  <xs:complexType name="acqAssistType">
    <xs:complexContent>
      <xs:restriction base="gps:perSatelliteTowType">
        <xs:sequence>
          <xs:element ref="gps:tow"/>
          <xs:element name="satellite"
                      type="gps:acqAssistSatelliteType"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="acqAssistSatelliteType">
    <xs:complexContent>
      <xs:restriction base="gps:satelliteBaseType">
        <xs:sequence>
          <xs:element name="rtow" type="gps:towType"/>
          <xs:element name="codephase" type="gps:polyUncType"/>
          <xs:element name="doppler" type="gps:polyUncType"/>
          <xs:element name="direction" type="gps:directionType"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:simpleType name="directionType">
    <xs:restriction base="gps:polyType">
      <xs:maxLength value="2"/>
    </xs:restriction>
  </xs:simpleType>

  <!-- DGPS Corrections -->
  <xs:element name="dgps" type="gps:dgpsType"/>
  <xs:complexType name="dgpsType">
    <xs:complexContent>
      <xs:restriction base="gps:perSatelliteTowType">
        <xs:sequence>
          <xs:element ref="gps:tow"/>
          <xs:element name="satellite" type="gps:dgpsSatelliteType"
                      minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:complexType name="dgpsSatelliteType">
    <xs:complexContent>
      <xs:restriction base="gps:satelliteBaseType">
        <xs:sequence>
          <xs:element name="range" type="gps:polyUncType"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <!-- Ionosphere Model -->
  <xs:element name="ionosphere" type="gps:ionosphereType"/>
  <xs:complexType name="ionosphereType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
        <xs:sequence>
          <xs:element name="vdelay" type="gps:polyType"/>
          <xs:element name="period" type="gps:polyType"/>
        </xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>


 TOC 

5.  Security Considerations

This document is subject to the security considerations described in [I‑D.thomson‑geopriv‑grip] (Thomson, M., “Global Position System (GPS) Assistance Data for GRIP,” Jul 2009.).



 TOC 

6.  IANA Considerations

The XML namespace used for GPS assistance data is registered in Section 6.1 (URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:grip:gps'), the corresponding schema definition is registered in Section 6.2 (XML Schema Registration).



 TOC 

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] (Mealling, M., “The IETF XML Registry,” January 2004.).

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
        <?xml version="1.0"?>
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
          <head>
            <title>GPS Assistance Data</title>
          </head>
          <body>
            <h1>Namespace for GPS Assistance Data Definitions</h1>
            <h2>urn:ietf:params:xml:ns:grip:gps</h2>
    [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
    with the RFC number for this specification.]
            <p>See RFCXXXX</p>
          </body>
        </html>
      END



 TOC 

6.2.  XML Schema Registration

This section registers an XML schema as per the guidelines in [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:
urn:ietf:params:xml:schema:grip:gps
Registrant Contact:
IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).
Schema:
The XML for this schema can be found as the entirety of Section 4 (XML Schema) of this document.


 TOC 

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 http://osgrs.sourceforge.net/. The GPS expertise of Neil Harper was invaluable in assembling this document.



 TOC 

8.  References



 TOC 

8.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3688] Mealling, M., “The IETF XML Registry,” BCP 81, RFC 3688, January 2004 (TXT).
[GPS-IS-200] GPS Navstar Joint Program Office, “Navstar GPS Space Segment / Navigation User Interfaces,” Interface Specification IS-GPS-200D, December 2004.
[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),” draft-singh-geopriv-pidf-lo-dynamic-09 (work in progress), March 2010 (TXT).


 TOC 

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 (TXT).
[W3C.REC-xmlschema-1-20010502] Beech, D., Thompson, H., Mendelsohn, N., and M. Maloney, “XML Schema Part 1: Structures,” World Wide Web Consortium FirstEdition REC-xmlschema-1-20010502, May 2001 (HTML).


 TOC 

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/