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 urn:x-grip:location:requester 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 00001F0000000890970E4B070E 0602FFFE2906FFF8 3 6 8 24 8B065C8CA0A465D0010045A5905BABDA135662BEDBA56B3A0000190E FA448B065C8CA12AA5091B3176377C8F1907A6047F5A5E1653A10CCCA86B3A7E8B 065C8CA1AC0079F86A32C9FFF0269127BC14675EF1C04CFFAB23A5E094 8B065C8CA0A465D0000045A5905BABDA135662BEF4876B3A00FFF801 43D38B065C8CA12A870A2130D3A088963508A103EB9A411787A10C990D6B3A7E8B 065C8CA1ACFFFBF9331B37FFA6268B1C9813770AD0980CFFAB4C87E6B3 407 1 0 0 407 1 0 0 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 . 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, . [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, . Appendix A. GRIP Schema The following schema document defines the request and response elements for the GNSS Reference Interface Protocol (GRIP). This document describes the format of GNSS assistance data requests. Thomson & Winterbottom Expires July 9, 2009 [Page 17] Internet-Draft A-GNSS AD for HELD January 2009 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. This document describes the format of GPS assistance data. Thomson & Winterbottom Expires July 9, 2009 [Page 19] Internet-Draft A-GNSS AD for HELD January 2009 Thomson & Winterbottom Expires July 9, 2009 [Page 20] Internet-Draft A-GNSS AD for HELD January 2009 Thomson & Winterbottom Expires July 9, 2009 [Page 21] Internet-Draft A-GNSS AD for HELD January 2009 Thomson & Winterbottom Expires July 9, 2009 [Page 22] Internet-Draft A-GNSS AD for HELD January 2009 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]