GEOPRIV M. Thomson Internet-Draft J. Winterbottom Intended status: Experimental Andrew Corporation Expires: December 18, 2008 June 16, 2008 Providing Satellite Navigation Assistance Data using HELD draft-thomson-held-grip-00 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 December 18, 2008. Abstract This document describes a method for providing Global Navigation Satellite System (GNSS) assistance data using the HTTP-Enabled 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. Thomson & Winterbottom Expires December 18, 2008 [Page 1] Internet-Draft A-GNSS AD for HELD June 2008 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.5.1. Issue of Data Ephemeris . . . . . . . . . . . . . . . 12 5.6. Time of Week Assistance . . . . . . . . . . . . . . . . . 13 5.7. Acquisition Assistance . . . . . . . . . . . . . . . . . . 13 5.8. Differential GPS Corrections . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. GRIP Schema . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. GRIP GPS Data Schema . . . . . . . . . . . . . . . . 19 Thomson & Winterbottom Expires December 18, 2008 [Page 2] Internet-Draft A-GNSS AD for HELD June 2008 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 December 18, 2008 [Page 3] Internet-Draft A-GNSS AD for HELD June 2008 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 December 18, 2008 [Page 4] Internet-Draft A-GNSS AD for HELD June 2008 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 either global or specific to a particular location contains information about individual satellites. This information is localized by constraining the information to the set of satellites that are expected to be visible from that 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 Thomson & Winterbottom Expires December 18, 2008 [Page 5] Internet-Draft A-GNSS AD for HELD June 2008 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. 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 Thomson & Winterbottom Expires December 18, 2008 [Page 6] Internet-Draft A-GNSS AD for HELD June 2008 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 December 18, 2008 [Page 7] Internet-Draft A-GNSS AD for HELD June 2008 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 December 18, 2008 [Page 8] Internet-Draft A-GNSS AD for HELD June 2008 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 December 18, 2008 [Page 9] Internet-Draft A-GNSS AD for HELD June 2008 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. 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 Appendix B. Thomson & Winterbottom Expires December 18, 2008 [Page 10] Internet-Draft A-GNSS AD for HELD June 2008 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 December 18, 2008 [Page 11] Internet-Draft A-GNSS AD for HELD June 2008 5.5.1. Issue of Data Ephemeris [[Editor's Note: Using IODE to save on bits is a practice that comes over from the original bit-miserly protocols like RRLP that provided GPS assistance data. The complexity of implementing this functionality probably outweighs the relatively small saving in bits. Candidate for removal.]] The navigation model represents the largest and most significant piece of assistance data provided. This information changes on an hourly basis, and at each change the Issue of Data Ephemeris (IODE) is changed. For this reason, a request that asks for the navigation model is able to indicate the IODE for each satellite and the time that this data was acquired. The response can omit satellites with matching IODE. An "gps:iode" element can be included in the "local" or "global" element of the request. It identifies the current time (in UTC or GPS time) and the IODE for each satellite that the receiver knows about. 42.5463 -73.2512 850.24 66 66 Implementation of this feature by a GRIP server is optional. A GRIP client that uses this option must be prepared to receive navigation model information for satellites that it already has information for. Thomson & Winterbottom Expires December 18, 2008 [Page 12] Internet-Draft A-GNSS AD for HELD June 2008 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. +-------+-----------------+-----------------------------------------+ | 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 | | | 6 | Code Phase | The range of code phase values to | | | Uncertainty | search | | 7 | Azimuth | The azimuth (from Northing) of the | | | | satellite in degrees | Thomson & Winterbottom Expires December 18, 2008 [Page 13] Internet-Draft A-GNSS AD for HELD June 2008 | 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. The "gpsWeek" and "gpsTOW" attributes used for the IODE time are used to provide a GPS time on the "gps:dgps" element. 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 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 Thomson & Winterbottom Expires December 18, 2008 [Page 14] Internet-Draft A-GNSS AD for HELD June 2008 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 for GRIP namespaces (these are not registered by this document). 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-07 (work in progress), April 2008. [W3C.REC-xpath20-20070123] Berglund, A., Chamberlin, D., Robie, J., Boag, S., Kay, M., Simeon, J., and M. Fernandez, "XML Path Language (XPath) 2.0", World Wide Web Consortium Recommendation REC- xpath20-20070123, Thomson & Winterbottom Expires December 18, 2008 [Page 15] Internet-Draft A-GNSS AD for HELD June 2008 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 DHCPv6", RFC 4075, May 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. Thomson & Winterbottom Expires December 18, 2008 [Page 16] Internet-Draft A-GNSS AD for HELD June 2008 [I-D.thomson-geopriv-held-measurements] Thomson, M. and J. Winterbottom, "Using Device-provided Location- Related Measurements in HELD", draft-thomson- geopriv-held-measurements- 02 (work in progress), May 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., Hollander, D., Bray, T., and A. Layman, "Namespaces in XML 1.0 (Second Edition)", World Wide Web Consortium Recomm endation 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 December 18, 2008 [Page 17] Internet-Draft A-GNSS AD for HELD June 2008 Thomson & Winterbottom Expires December 18, 2008 [Page 18] Internet-Draft A-GNSS AD for HELD June 2008 Appendix B. GRIP GPS Data Schema The following schema document defines the elements for GPS assistance data, based on the outline in Section 5. Thomson & Winterbottom Expires December 18, 2008 [Page 19] Internet-Draft A-GNSS AD for HELD June 2008 This document describes the format of GPS assistance data. Thomson & Winterbottom Expires December 18, 2008 [Page 20] Internet-Draft A-GNSS AD for HELD June 2008 Thomson & Winterbottom Expires December 18, 2008 [Page 21] Internet-Draft A-GNSS AD for HELD June 2008 Thomson & Winterbottom Expires December 18, 2008 [Page 22] Internet-Draft A-GNSS AD for HELD June 2008 Thomson & Winterbottom Expires December 18, 2008 [Page 23] Internet-Draft A-GNSS AD for HELD June 2008 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/ Thomson & Winterbottom Expires December 18, 2008 [Page 24] Internet-Draft A-GNSS AD for HELD June 2008 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 December 18, 2008 [Page 25] Internet-Draft A-GNSS AD for HELD June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Thomson & Winterbottom Expires December 18, 2008 [Page 26]