GEOPRIV M. Thomson
Internet-Draft J. Winterbottom
Intended status: Experimental Andrew Corporation
Expires: July 9, 2009 January 5, 2009
Providing Satellite Navigation Assistance Data using HELD
draft-thomson-geopriv-held-grip-01
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 July 9, 2009.
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
(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.
Abstract
This document describes a method for providing Global Navigation
Satellite System (GNSS) assistance data using the HTTP-Enabled
Thomson & Winterbottom Expires July 9, 2009 [Page 1]
Internet-Draft A-GNSS AD for HELD January 2009
Location Delivery (HELD) protocol. An assistance data request is
included with the HELD location request and the Location Information
Server (LIS) provides assistance data along with location
information.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Advantages of Assistance Data . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. The GNSS Reference Information Protocol . . . . . . . . . . . 5
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Assistance Data Types . . . . . . . . . . . . . . . . . . 8
4.2. Identifying Assistance Data Types . . . . . . . . . . . . 9
4.3. Time Assistance . . . . . . . . . . . . . . . . . . . . . 9
5. GPS Assistance Data Types . . . . . . . . . . . . . . . . . . 10
5.1. UTC Model . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Ionosphere Model . . . . . . . . . . . . . . . . . . . . . 11
5.3. Almanac . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Real Time Integrity . . . . . . . . . . . . . . . . . . . 11
5.5. Navigation Model . . . . . . . . . . . . . . . . . . . . . 11
5.6. Time of Week Assistance . . . . . . . . . . . . . . . . . 12
5.7. Acquisition Assistance . . . . . . . . . . . . . . . . . . 12
5.8. Differential GPS Corrections . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. GRIP Schema . . . . . . . . . . . . . . . . . . . . . 16
Appendix B. GRIP GPS Data Schema . . . . . . . . . . . . . . . . 19
Thomson & Winterbottom Expires July 9, 2009 [Page 2]
Internet-Draft A-GNSS AD for HELD January 2009
1. Introduction
A Global Navigation Satellite System (GNSS) provides a signal that
enables accurate determination of the position of a receiver in space
and time. A constellation of satellites transmit radio signals that
the receiver is able to measure. From these measurements, the
location of the receiver and the time of measurement can be
determined using knowledge about the position and velocity of the
satellites and signal information.
Acquisition of satellite signals requires searching for the extremely
weak signal transmitted by each satellite. Each satellite transmits
a repeating signal. Acquiring the signal is done by synchronizing
with the received signal in both frequency and time. In order to
synchronize, the receiver searches in two dimensions:
time/code phase: The distance between the satellite and receiver
means that the receiver sees a signal that is offset in time. The
amount of time shift is known as code phase since it is measured
within the window of the repeated code sequence. Code phase forms
the primary measurement used in calculating a position.
frequency: The relative speed of satellite and receiver causes
Doppler shift of the satellite signal.
Satellite signals are typically modulated at a low rate with a
navigation message. The navigation message provides information that
is used in the final calculation phase including information on
satellite orbit, satellite health, time model, atmospheric effects on
the signal. This data is transmitted at very low rates to avoid
hampering the acquisition process, therefore acquiring this
information can take a signficant amount of time.
Once satellite signals have been acquired and measured, the
measurement information is combined with the information from the
navigation message and a position (and time) can be calculated.
Successful calculation of a position typically requires measurement
data for a minimum of 5 satellites unless otherwise supplemented.
If a receiver has to perform all these steps independently, satellite
acquisition and receipt of the navigation message can take
significant amounts of time. Improvements in receiver design have
increased receiver sensitivity and the speed that signals are
acquired. Use of assistance data provides a dramatic improvement in
the time taken to acquire signals and produce a result.
This document provides a means of combining a request for GNSS
assistance data with a HELD [I-D.ietf-geopriv-http-location-delivery]
Thomson & Winterbottom Expires July 9, 2009 [Page 3]
Internet-Draft A-GNSS AD for HELD January 2009
request.
1.1. Advantages of Assistance Data
GNSS assistance data is information provided to a receiver that is
provided to improve the quality and timeliness of GNSS measurements
or positioning. The most basic set of assistance data includes the
same information provided in the navigation message. Additional
forms of assistance data include information customized to a
particular receiver to assist it in acquiring signals, or information
about satellite ephemerides (orbits) that is useful over a longer
period of time.
Acquiring assistance data from the network completely removes the
need to receive the navigation message. Navigation message content
can be transmitted to the receiver using the vastly more efficient
communication paths provided by a data network. This removes a
significant step from the process of determining a position.
Knowing what satellites to search for can reduce signal acquisition
time. One of the most basic pieces of information provided by
assistance data is knowledge of which satellites are above the
horizon and can therefore be measured. Concentrating on "visible"
satellites ensures that less time is wasted where signals could not
possibly be found.
Assistance data can provide information about where in the frequency/
code phase space to search for a particular satellite signal. This
reduces the time required to acquire a satellite signal. Since an
approximate frequency and code phase can be known, it becomes
feasible to spend more time searching for weaker signals, improving
receiver sensitivity. Improved sensitivity ensures that GNSS can be
used in areas where signal penetration is poor, like buildings and
other areas with poor sky visibility, and increases the likelihood of
getting sufficient satellite measurements to calculate a position.
Assistance data also enables compensation for the effects of the
navigation message. Knowing the content of the navigation message
ahead of time means that the receiver is able to anticipate the
effect of its modulation on the signal and compensate accordingly.
This increases the sensitivity of the receiver and allows for faster
signal acquisition.
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].
Thomson & Winterbottom Expires July 9, 2009 [Page 4]
Internet-Draft A-GNSS AD for HELD January 2009
3. The GNSS Reference Information Protocol
The GNSS Reference Information Protocol (GRIP) is a protocol that is
used for the acquisition of GNSS assistance data. This document
describes how to use GRIP in conjunction with HELD to enable the use
of assisted GNSS positioning.
GRIP response message provides a set of several different types of
assistance data. A set of assistance data types for GPS is shown in
Table 1. The scope of each field is also included to shown whether
the data applies globally, to a specific area only (local), or could
apply to either.
+-----------------+--------+----------------------------------------+
| Type | Scope | Description |
+-----------------+--------+----------------------------------------+
| UTC Model | Global | models the difference between GPS time |
| | | and UTC time |
| Ionospheric | Global | models the propagation delay on |
| Model | | satellite signals caused by the |
| | | ionosphere |
| Almanac | Either | a low-detail, long-term model of |
| | | satellite orbits and clocks |
| Real Time | Either | identifies satellites that should not |
| Integrity | | be used |
| Navigation | Either | models the orbit of the satellite over |
| Model | | time |
| TOW Assist | Either | aids in signal acquisition |
| Acquisition | Local | for fast signal acquisition |
| Assistance | | |
| Differential | Local | parameters for fine tuning calculated |
| GPS Corrections | | results |
+-----------------+--------+----------------------------------------+
Table 1: Assistance Data Types for GPS
Data marked as global includes information that is not specific to a
given location. Data marked as local applies only to a particular
location. Data marked as either global or local, in this case
contains information about individual satellites.
The UTC and ionosphere models are global models that apply to all
locations on the planet.
Per-satellite information can be provided as global assistance data,
in which case data for all satellites is provided. Per-satellite
data is localized by constraining the information to the set of
satellites that are expected to be visible from a particular
Thomson & Winterbottom Expires July 9, 2009 [Page 5]
Internet-Draft A-GNSS AD for HELD January 2009
location. Information on satellites that are on the other side of
the Earth or below the horizon is omitted. This ensures that a
receiver is immediately able to restrict the set of satellites that
it searches for.
Acquisition assistance and differential GPS corrections always
contain localized information. Acquisition assistance contains a
prediction about the satellite signal for the given location that
narrows the size of the code phase and frequency space that needs to
be searched. Differential GPS is information on signal errors
provided by another receiver that is near the specified location.
Differential GPS corrections aids in the calculation of results by
providing fine tuning of the measurement data.
A GRIP request can include two parts, a request for global assistance
data and a request for localized assistance data. Each part
identifies the assistance data types that are required; a request for
localized data must also include location information. Location
information can be provided by-value or by-reference.
Note: GRIP, as reproduced in this document, is an incomplete
protocol that has the goal of providing a means for requesting
assistance data. Only the Global Position System (GPS)
constellation is supported in the messages that are included in
this document. This protocol does not fall within the scope of
the work performed by the target working group (GEOPRIV) and the
IETF in general. It is intended that this work find a more
appropriate home before this draft progresses. The information is
included as a temporary measure to ensure that it can be reliably
referenced from this document.
4. Operation
A Device that includes a GNSS receiver is able to request assistance
data as part of a HELD location request to a Location Information
Server (LIS). The request is included as an extension to the
location request and is ignored by a LIS that does not support this
specification, or cannot provide assistance data. The receiver
includes a GRIP assistance data request in a HELD location request.
Thomson & Winterbottom Expires July 9, 2009 [Page 6]
Internet-Draft A-GNSS AD for HELD January 2009
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<adRequest xmlns="urn:x-grip:ns"
xmlns:gps="urn:x-grip:gnss:gps">
<global data="gps:utc gps:ionosphere gps:rti"/>
<local data="gps:navigation gps:acqassist gps:towassist">
<locationURI>
urn:x-grip:location:requester
</locationURI>
</local>
</adRequest>
</locationRequest>
The assistance data request contains two parts, identifying the
global and local assistance data types that are requested. Global
assistance data can be provided without any extra information, but
localized assistance data requires that a location estimate for the
requester be known. Any request for localized assistance data must
include location information. Location information can be provided
by value, preferably using a geodetic form, or by reference.
GRIP requires location information when localized assistance data is
requested because a GRIP server cannot be assumed to have the ability
to locate requesters. However, in the case where the GRIP request is
placed in a HELD request, the LIS is certainly able to locate the
requester. To indicate that the LIS should generate the location
information necessary to generate localized assistance data a special
URN is used in place of the location reference. The
"urn:x-grip:location:requester" URN indicates that the server is
expected to generate location information for the requester and use
that in generating localized assistance data. The LIS MAY choose to
generate location information for any request and ignore the location
information provided.
The location response, along with the location information, includes
the requested assistance data. (Note: the "hexBinary" navigation
data is wrapped due to document constraints.)
Thomson & Winterbottom Expires July 9, 2009 [Page 7]
Internet-Draft A-GNSS AD for HELD January 2009
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
<!-- location information -->
</presence>
<adResponse xmlns="urn:x-grip:ns"
xmlns:gps="urn:x-grip:gnss:gps">
<global>
<gps:utc>00001F0000000890970E4B070E</gps:utc>
<gps:ionosphere>0602FFFE2906FFF8</gps:ionosphere>
<gps:rti>3 6 8 24</gps:rti>
</global>
<local unsupported="gps:acqassist">
<gps:navigation>
<gps:sat num="2">
8B065C8CA0A465D0010045A5905BABDA135662BEDBA56B3A0000190E
FA448B065C8CA12AA5091B3176377C8F1907A6047F5A5E1653A10CCCA86B3A7E8B
065C8CA1AC0079F86A32C9FFF0269127BC14675EF1C04CFFAB23A5E094
</gps:sat>
<gps:sat num="4">
8B065C8CA0A465D0000045A5905BABDA135662BEF4876B3A00FFF801
43D38B065C8CA12A870A2130D3A088963508A103EB9A411787A10C990D6B3A7E8B
065C8CA1ACFFFBF9331B37FFA6268B1C9813770AD0980CFFAB4C87E6B3
</gps:sat>
<!-- more gps:sat elements -->
</gps:navigation>
<gps:towassist>
<gps:sat num="2">407 1 0 0</gps:sat>
<gps:sat num="4">407 1 0 0</gps:sat>
<!-- more gps:sat elements -->
</gps:towassist>
</local>
</adResponse>
</locationResponse>
The response includes the information that was available to the LIS.
Unsupported or unavailable pieces of information are indicated using
the "unsupported" or "unavailable" attributes.
4.1. Assistance Data Types
Each assistance data type is specified as an XML element that is
included in either the "global" or "local" element of the assistance
data response. Assistance data formats for each different GNSS are
specified as separate elements.
A set of assistance data types are defined for GPS in Section 5 using
the namespace "urn:x-grip:gnss:gps".
Thomson & Winterbottom Expires July 9, 2009 [Page 8]
Internet-Draft A-GNSS AD for HELD January 2009
Note: Different satellite systems share a number of key parameters,
and it could be useful to have a generic format for assistance
data that could be universally applicable. While the benefits of
a generic approach are obvious, this approach enables a more rapid
development of a specification without preventing a generic format
from being introduced later.
4.2. Identifying Assistance Data Types
A request for assistance data identifies the XML elements that
contain the assistance data by name. The "data" attribute can be
included on either the "global" or "local" element of the assistance
data request. The "data" attribute includes a whitespace-separated
list of elements.
Each item in this list is a qualified element name that identifies
the requested element. Each item can be interpreted as XML Path
Language (XPath) [W3C.REC-xpath20-20070123] expressions that are
evaluated in the context of the matching element in the response.
These statements are restricted to use of qualified names only.
Namespace prefixes are taken from the document context.
Each type of assistance data that is identified in the request must
be included in the corresponding "global" or "local" element of the
response. If information cannot be provided the LIS must indicate
which items are either unavailable (a temporary cause of error) or
unsupported (a situation that is more likely to be persistent). The
"unavailable" and "unsupported" attributes are used in the response
to indicate which items were not provided. Unsupported assistance
data types must be included in the response using the "unsupported"
attribute.
If an assistance data type is requested in an inapplicable category
(such as the UTC model in the "local" element), it must be reported
as "unsupported".
This method of identifying assistance data types enables easy
extension to forms of GNSS other than GPS or new types of assistance
data. By relying on the inherent extensibility provided by
namespaces in XML [W3C.REC-xml-names-20060816], extensions can be
readily addded. Extensions for other types of GNSS or assistance
data need only define elements in a new namespace.
4.3. Time Assistance
Time synchronization is helpful in ensuring rapid signal acquisition.
Satellite signals change with time, so having accurate time ensures
that the time-based information provided with assistance data can be
Thomson & Winterbottom Expires July 9, 2009 [Page 9]
Internet-Draft A-GNSS AD for HELD January 2009
more effectively used. Accurate time also enables position
determination with fewer pseudorange measurements.
Other assistance data protocols define a reference time assistance
data type, which includes a time in the GNSS time system. However,
the mechanisms that are used to ensure that this information is
correct when received are dependent on the type of network. Without
these mechanisms, network latency and retransmission delays can
result in this value being incorrect when it is received.
This document does not define a mechanism for providing accurate time
as part of assistance data, instead relying on general purpose time
synchronization protocols.
The Network Time Protocol (NTP) [RFC1305] or Simple Network Time
Protocol (SNTP) [RFC4330] can be used by GNSS receivers to acquire
clock synchronization with Coordinated Universal Time (UTC). The
time model assistance data type (or UTC model for GPS) provides the
information necessary to translate from UTC to the time system used
by the GNSS.
Alternatively, a receiver might be able to learn how UTC, or the GNSS
time system relates to a known time reference, such as that used by a
radio access medium. These methods of time synchronization are
specific to those alternative time systems.
A LIS does not provide information about time servers. Configuration
of hosts can be manual, or time server information can be provided by
DHCP ([RFC2132], [RFC3315], [RFC4075], [I-D.gayraud-dhcpv6-ntp-opt]).
5. GPS Assistance Data Types
This section defines a set of assistance data types for the GPS GNSS
(as shown in Table 1). Each assistance data type is defined as an
XML element and is able to be identified by the qualified name
[W3C.REC-xml-names-20060816] of the element. The GPS elements are
defined in the "urn:x-grip:gnss:gps" namespace. The "gps:" prefix is
used in this section to identify this namespace.
GPS assistance data is constructed based on the definition of the
navigation message defined in GPS interface control document
[GPS-ICD]. Assistance data that is provided on a per-satellite, or
space vehicle (SV), basis is split into "gps:sat" elements under each
data type. The satellite is identified by its SV-ID, a number
between 1 and 32, in the "num" attribute.
An XML Schema for GRIP messages is included in Appendix A. A schema
defining the format of assistance data for GPS is included in
Thomson & Winterbottom Expires July 9, 2009 [Page 10]
Internet-Draft A-GNSS AD for HELD January 2009
Appendix B.
5.1. UTC Model
The UTC model contains the information necessary to convert from UTC
time to the time system used by GPS. The "gps:utc" element contains
a string of hexadecimal digits that correspond to bits 151 through
279 of subframe 4, page 18 of the navigation message, with the parity
bits removed.
5.2. Ionosphere Model
The ionosphere model contains parameters for a model of the
propagation delay through the ionosphere - the part of the Earth's
atmosphere that has the more significant impact on satellite signals.
The "gps:ionosphere" element contains a string of hexadecimal digits
that correspond to bits 69 through 145 of subframe 4, page 18 of the
navigation message, with the parity bits removed.
5.3. Almanac
The almanac assistance data type includes information about the
satellites in the GPS constellation. This information is intended to
be long-lived and changes rarely. This information is not useful for
calculating a position, but is helpful in determining what satellites
could be used. The "gps:almanac" element contains per-satellite
data. The content of the "gps:sat" element is a string of
hexadecimal digits that correspond to the collated almanac data from
the navigation message (subframe 5, pages 1 through 24; or subframe
4, pages 2, 3, 4, 5, 7, 8, 9 and 10).
5.4. Real Time Integrity
This data type contains a list of the satellite (SV) identifiers for
those satellites that are either out of service or are otherwise not
recommended for use. The "gps:rti" element contains a whitespace-
separated list of satellited identifiers.
5.5. Navigation Model
The navigation model contains information for each satellite in the
chosen set; either all GPS satellites, or those that are expected to
be visible from the estimated location of the Device. To that end,
the "gps:navigation" element contains one or more "gps:sat" elements.
The content of the "gps:sat" element is a hex string of 180
characters (90 bytes) that is sub-frames 1 through 3 of the
navigation message for the given satellite with parity bits removed.
Thomson & Winterbottom Expires July 9, 2009 [Page 11]
Internet-Draft A-GNSS AD for HELD January 2009
5.6. Time of Week Assistance
The time of week (TOW) assistance information includes the telemetry
(TLM) message, which is included every six seconds as the first word
of a subframe or page. The anti-spoof and alert flags from the
handover (HOW) word are also included in this item. This item can
change each time, but it rarely does; therefore, knowing the current
telemetry word aids in ensuring that the signal can be more rapidly
acquired. The "gps:towassist" element contains per-satellite data.
The data for each satellite is a whitespace-separated list of four
integers, starting with the 14-bits of the TLM message, then the
1-bit anti-spoof flag, the 1-bit alert flag and then the 2-bit
reserved portion from the TLM word.
5.7. Acquisition Assistance
Acquisition assistance aids receivers in satellite signal acquisition
by attempting to predict signals for a particular location at a
certain time. Acquisition assistance is synthesized from satellite
data; it is not a reconstruction of parts of the navigation message.
This data includes prediced code phase and doppler, plus a means to
predict how these change over time. This compact form allows for
faster measurement of the signals without necessarily enabling
position calculation.
The "gps:acqassist" element contains per-satellite data. Each
"gps:sat" element contains a list of floating point numbers as
described in Table 2.
Time attributes, "gpsWeek" and "gpsTOW", identify the instant in time
that this information is relevant. Rate of change information allows
for estimation of these parameters over a small period about this
time.
+-------+-----------------+-----------------------------------------+
| Order | Name | Description |
+-------+-----------------+-----------------------------------------+
| 1 | 0th order | The predicted Doppler shift in Hz |
| | Doppler | |
| 2 | 1st order | The rate of change of Doppler shift in |
| | Doppler | Hz/s |
| 3 | Doppler Search | The range of Doppler shift values to |
| | Window | search in Hz |
| 4 | Code Phase | The predicted code phase in chips from |
| | | 0 to 1022 |
| 5 | Integer Code | The number of whole 1023 chip segments |
| | Phase | |
Thomson & Winterbottom Expires July 9, 2009 [Page 12]
Internet-Draft A-GNSS AD for HELD January 2009
| 6 | Code Phase | The range of code phase values to |
| | Uncertainty | search |
| 7 | Azimuth | The azimuth (from Northing) of the |
| | | satellite in degrees |
| 8 | Elevation | The elevation (from horizontal) of the |
| | | satellite in degrees |
+-------+-----------------+-----------------------------------------+
Table 2: Acquisition Assistance Fields
5.8. Differential GPS Corrections
Differential GPS provides a means of compensating for atmospheric
effects, orbital model limitation and satellite clock drift. The
"gps:dgps" element includes attributes that indicate the GPS time
when measurements were taken and per-satellite information.
Two time attributes, "gpsWeek" and "gpsTOW", indicate when the
differential GPS information applies in GPS time.
The "gps:sat" element includes a whitespace-separated list of three
floating point values:
UDRE: an estimate of the accuracy of the pseudorange corrections in
metres
pseudorange correction: a correction value in metres, taken at the
time indicated
pseudorange correction rate of change: the rate that the pseudorange
correction changes in metres per second
6. Security Considerations
Since this document relies on bundling assistance data with a HELD
location response, it inherits many of the same security
considerations as HELD [I-D.ietf-geopriv-http-location-delivery]. It
also inherits all the protections provided therein; largely provided
by use of TLS [RFC4346].
Privacy is a major consideration for location protocol security.
However, assistance data contains less useful information than the
location information that is already provided. The bulk of the
assistance data is either publically available or is derived from
that publically available data and the estimate location of the
Device.
Requesting localized assistance data from a GRIP server for an
Thomson & Winterbottom Expires July 9, 2009 [Page 13]
Internet-Draft A-GNSS AD for HELD January 2009
arbitrary location provides little additional information over what
is provided by requesting global types. However, a request for
acquisition assistance could be used to trivially generate spoofed
GNSS measurements. [I-D.thomson-geopriv-held-measurements] provides
suggestions for dealing with spoofed GNSS measurements, but it is
recommended that a LIS not provide acquisition assistance for
arbitrary locations.
A Device that relies on assistance data could find that bad
assistance data is more of a hindrance than help. However, the
impact of an attack by a LIS on assisted GNSS is limited by the fact
that bad assistance data can be readily ignored and autonomous
operation used.
7. IANA Considerations
No registrations are necessary. Note: XML namespaces for use in GRIP
do not require registration, unless mandated by the controller of the
namespace used. Uniqueness is the only constraint on the use of a
namespace.
8. Acknowledgements
This document uses a modified copy of the GRIP protocol based on the
work done by the University of New South Wales through the OSGRS
project <http://osgrs.sourceforge.net/>. Authors of the original
GRIP specification were Nam Hoang and Manosh Fernando. The GPS
expertise of Neil Harper was invaluable in assembling this document.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words
for use in RFCs to
Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom,
J., Thomson, M., and B.
Stark, "HTTP Enabled
Location Delivery (HELD)",
draft-ietf-geopriv-http-
location-delivery-11 (work
in progress),
December 2008.
Thomson & Winterbottom Expires July 9, 2009 [Page 14]
Internet-Draft A-GNSS AD for HELD January 2009
[W3C.REC-xpath20-20070123] Berglund, A., Boag, S.,
Chamberlin, D., Robie, J.,
Kay, M., Simeon, J., and
M. Fernandez, "XML Path
Language (XPath) 2.0",
World Wide Web Consortium
Recommendation REC-
xpath20-20070123,
January 2007, <http://
www.w3.org/TR/2007/
REC-xpath20-20070123>.
[GPS-ICD] "Navstar GPS Space Segment
/ Navigation User
Interfaces", ICD-GPS-
200c, April 2000.
9.2. Informative References
[RFC1305] Mills, D., "Network Time
Protocol (Version 3)
Specification,
Implementation", RFC 1305,
March 1992.
[RFC4330] Mills, D., "Simple Network
Time Protocol (SNTP)
Version 4 for IPv4, IPv6
and OSI", RFC 4330,
January 2006.
[RFC2132] Alexander, S. and R.
Droms, "DHCP Options and
BOOTP Vendor Extensions",
RFC 2132, March 1997.
[RFC3315] Droms, R., Bound, J.,
Volz, B., Lemon, T.,
Perkins, C., and M.
Carney, "Dynamic Host
Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315,
July 2003.
[RFC4075] Kalusivalingam, V.,
"Simple Network Time
Protocol (SNTP)
Configuration Option for
Thomson & Winterbottom Expires July 9, 2009 [Page 15]
Internet-Draft A-GNSS AD for HELD January 2009
DHCPv6", RFC 4075,
May 2005.
[RFC4346] Dierks, T. and E.
Rescorla, "The Transport
Layer Security (TLS)
Protocol Version 1.1",
RFC 4346, April 2006.
[I-D.thomson-geopriv-held-measurements] Thomson, M. and J.
Winterbottom, "Using
Device-provided Location-
Related Measurements in
Location Configuration
Protocols", draft-thomson-
geopriv-held-measurements-
03 (work in progress),
October 2008.
[I-D.gayraud-dhcpv6-ntp-opt] Gayraud, R. and B.
Lourdelet, "Network Time
Protocol (NTP) Server
Option for DHCPv6", draft-
gayraud-dhcpv6-ntp-opt-01
(work in progress),
February 2008.
[W3C.REC-xml-names-20060816] Tobin, R., Bray, T.,
Hollander, D., and A.
Layman, "Namespaces in XML
1.0 (Second Edition)",
World Wide Web Consortium
Recommendation REC-xml-
names-20060816,
August 2006, <http://
www.w3.org/TR/2006/
REC-xml-names-20060816>.
Appendix A. GRIP Schema
The following schema document defines the request and response
elements for the GNSS Reference Interface Protocol (GRIP).
<?xml version="1.0"?>
<xs:schema
xmlns:grip="urn:x-grip:ns"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:x-grip:ns"
Thomson & Winterbottom Expires July 9, 2009 [Page 16]
Internet-Draft A-GNSS AD for HELD January 2009
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation>
This document describes the format of GNSS assistance data
requests.
</xs:documentation>
</xs:annotation>
<xs:element name="adRequest" type="grip:adReqType"/>
<xs:complexType name="adReqType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:sequence>
<xs:element name="global" type="grip:dataReqType"/>
<xs:element name="local" type="grip:localDataReqType"
minOccurs="0"/>
</xs:sequence>
<xs:element name="local" type="grip:localDataReqType"/>
</xs:choice>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="localDataReqType">
<xs:complexContent>
<xs:restriction base="grip:dataReqType">
<xs:sequence>
<xs:choice>
<xs:element name="location-info" type="xs:anyType"/>
<xs:element name="locationURI" type="xs:anyURI"/>
</xs:choice>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="dataReqType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
Thomson & Winterbottom Expires July 9, 2009 [Page 17]
Internet-Draft A-GNSS AD for HELD January 2009
</xs:sequence>
<xs:attribute name="data" type="grip:elementsType"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="adResponse" type="grip:adResponseType"/>
<xs:complexType name="adResponseType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:sequence>
<xs:element name="global" type="grip:responseType"/>
<xs:element name="local" type="grip:responseType"
minOccurs="0"/>
</xs:sequence>
<xs:element name="local" type="grip:responseType"/>
</xs:choice>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="responseType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="unsupported" type="grip:elementsType"
default=""/>
<xs:attribute name="unavailable" type="grip:elementsType"
default=""/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="elementsType">
<xs:list itemType="xs:QName"/>
</xs:simpleType>
</xs:schema>
Thomson & Winterbottom Expires July 9, 2009 [Page 18]
Internet-Draft A-GNSS AD for HELD January 2009
Appendix B. GRIP GPS Data Schema
The following schema document defines the elements for GPS assistance
data, based on the outline in Section 5.
<?xml version="1.0"?>
<xs:schema
xmlns:gps="urn:x-grip:gnss:gps"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:x-grip:gnss:gps"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation>
This document describes the format of GPS assistance data.
</xs:documentation>
</xs:annotation>
<!-- Base data types -->
<xs:complexType name="satData" abstract="true">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="sat" type="gps:satBaseType"
minOccurs="0" maxOccurs="32"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="satBaseType" abstract="true">
<xs:simpleContent>
<xs:extension base="xs:anySimpleType">
<xs:attribute name="num" type="gps:satNumType"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="satNumType">
<xs:restriction base="xs:positiveInteger">
<xs:maxInclusive value="32"/>
</xs:restriction>
</xs:simpleType>
Thomson & Winterbottom Expires July 9, 2009 [Page 19]
Internet-Draft A-GNSS AD for HELD January 2009
<xs:attributeGroup name="gpsTimeGroup">
<xs:attribute name="gpsWeek" use="optional">
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxExclusive value="1023"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="gpsTOW" use="required">
<xs:simpleType>
<xs:restriction base="xs:double">
<xs:minInclusive value="0.0"/>
<xs:maxExclusive value="604800.0"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:attributeGroup>
<xs:simpleType name="doubleList">
<xs:list itemType="xs:double"/>
</xs:simpleType>
<!-- GPS element definitions -->
<xs:element name="utc" type="gps:utcType"/>
<xs:simpleType name="utcType">
<xs:restriction base="xs:hexBinary">
<xs:length value="13"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="ionosphere" type="gps:ionosphereType"/>
<xs:simpleType name="ionosphereType">
<xs:restriction base="xs:hexBinary">
<xs:length value="8"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="rti" type="gps:rtiType"/>
<xs:simpleType name="rtiType">
<xs:list itemType="gps:satNumType"/>
</xs:simpleType>
<xs:element name="navigation" type="gps:navigationType">
<xs:unique name="navigationUnique">
<xs:selector xpath="gps:sat"/>
<xs:field xpath="@num"/>
</xs:unique>
Thomson & Winterbottom Expires July 9, 2009 [Page 20]
Internet-Draft A-GNSS AD for HELD January 2009
</xs:element>
<xs:complexType name="navigationType">
<xs:complexContent>
<xs:restriction base="gps:satData">
<xs:sequence>
<xs:element name="sat" type="gps:satNavigationType"
minOccurs="0" maxOccurs="32"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="satNavigationType">
<xs:simpleContent>
<xs:restriction base="gps:satBaseType">
<xs:simpleType>
<xs:restriction base="xs:hexBinary">
<xs:length value="90"/>
</xs:restriction>
</xs:simpleType>
</xs:restriction>
</xs:simpleContent>
</xs:complexType>
<xs:element name="towassist" type="gps:towassistType">
<xs:unique name="towassistUnique">
<xs:selector xpath="gps:sat"/>
<xs:field xpath="@num"/>
</xs:unique>
</xs:element>
<xs:complexType name="towassistType">
<xs:complexContent>
<xs:restriction base="gps:satData">
<xs:sequence>
<xs:element name="sat" type="gps:satTowAssistType"
minOccurs="0" maxOccurs="32"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="satTowAssistType">
<xs:simpleContent>
<xs:restriction base="gps:satBaseType">
<xs:simpleType>
<xs:restriction base="gps:towAssistList">
<xs:length value="4"/>
</xs:restriction>
</xs:simpleType>
</xs:restriction>
Thomson & Winterbottom Expires July 9, 2009 [Page 21]
Internet-Draft A-GNSS AD for HELD January 2009
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="towAssistList">
<xs:list itemType="xs:nonNegativeInteger"/>
</xs:simpleType>
<xs:element name="acqassist" type="gps:acqassistType">
<xs:unique name="acqassistUnique">
<xs:selector xpath="gps:sat"/>
<xs:field xpath="@num"/>
</xs:unique>
</xs:element>
<xs:complexType name="acqassistType">
<xs:complexContent>
<xs:restriction base="gps:satData">
<xs:sequence>
<xs:element name="sat" type="gps:satAcqAssistType"
minOccurs="0" maxOccurs="32"/>
</xs:sequence>
<xs:attributeGroup ref="gps:gpsTimeGroup"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="satAcqAssistType">
<xs:simpleContent>
<xs:restriction base="gps:satBaseType">
<xs:simpleType>
<xs:restriction base="gps:doubleList">
<xs:length value="8"/>
</xs:restriction>
</xs:simpleType>
</xs:restriction>
</xs:simpleContent>
</xs:complexType>
<xs:element name="dgps" type="gps:dgpsType">
<xs:unique name="dgpsUnique">
<xs:selector xpath="gps:sat"/>
<xs:field xpath="@num"/>
</xs:unique>
</xs:element>
<xs:complexType name="dgpsType">
<xs:complexContent>
<xs:restriction base="gps:satData">
<xs:sequence>
<xs:element name="sat" type="gps:satDgpsType"
minOccurs="0" maxOccurs="32"/>
</xs:sequence>
Thomson & Winterbottom Expires July 9, 2009 [Page 22]
Internet-Draft A-GNSS AD for HELD January 2009
<xs:attributeGroup ref="gps:gpsTimeGroup"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="satDgpsType">
<xs:simpleContent>
<xs:restriction base="gps:satBaseType">
<xs:simpleType>
<xs:restriction base="gps:doubleList">
<xs:length value="3"/>
</xs:restriction>
</xs:simpleType>
</xs:restriction>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
Authors' Addresses
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/
James Winterbottom
Andrew Corporation
PO Box U40
University of Wollongong, NSW 2500
AU
Phone: +61 242 212938
EMail: james.winterbottom@andrew.com
URI: http://www.andrew.com/products/geometrix
Thomson & Winterbottom Expires July 9, 2009 [Page 23]