idnits 2.17.1 draft-thomson-held-grip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1115. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1126. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1133. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1139. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 16, 2008) is 5786 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-07 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: A later version (-06) exists of draft-thomson-geopriv-held-measurements-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft J. Winterbottom 4 Intended status: Experimental Andrew Corporation 5 Expires: December 18, 2008 June 16, 2008 7 Providing Satellite Navigation Assistance Data using HELD 8 draft-thomson-held-grip-00 10 Status of This Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 18, 2008. 35 Abstract 37 This document describes a method for providing Global Navigation 38 Satellite System (GNSS) assistance data using the HTTP-Enabled 39 Location Delivery (HELD) protocol. An assistance data request is 40 included with the HELD location request and the Location Information 41 Server (LIS) provides assistance data along with location 42 information. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1. Advantages of Assistance Data . . . . . . . . . . . . . . 4 48 2. Conventions used in this document . . . . . . . . . . . . . . 4 49 3. The GNSS Reference Information Protocol . . . . . . . . . . . 5 50 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 4.1. Assistance Data Types . . . . . . . . . . . . . . . . . . 8 52 4.2. Identifying Assistance Data Types . . . . . . . . . . . . 9 53 4.3. Time Assistance . . . . . . . . . . . . . . . . . . . . . 9 54 5. GPS Assistance Data Types . . . . . . . . . . . . . . . . . . 10 55 5.1. UTC Model . . . . . . . . . . . . . . . . . . . . . . . . 11 56 5.2. Ionosphere Model . . . . . . . . . . . . . . . . . . . . . 11 57 5.3. Almanac . . . . . . . . . . . . . . . . . . . . . . . . . 11 58 5.4. Real Time Integrity . . . . . . . . . . . . . . . . . . . 11 59 5.5. Navigation Model . . . . . . . . . . . . . . . . . . . . . 11 60 5.5.1. Issue of Data Ephemeris . . . . . . . . . . . . . . . 12 61 5.6. Time of Week Assistance . . . . . . . . . . . . . . . . . 13 62 5.7. Acquisition Assistance . . . . . . . . . . . . . . . . . . 13 63 5.8. Differential GPS Corrections . . . . . . . . . . . . . . . 14 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 70 Appendix A. GRIP Schema . . . . . . . . . . . . . . . . . . . . . 17 71 Appendix B. GRIP GPS Data Schema . . . . . . . . . . . . . . . . 19 73 1. Introduction 75 A Global Navigation Satellite System (GNSS) provides a signal that 76 enables accurate determination of the position of a receiver in space 77 and time. A constellation of satellites transmit radio signals that 78 the receiver is able to measure. From these measurements, the 79 location of the receiver and the time of measurement can be 80 determined using knowledge about the position and velocity of the 81 satellites and signal information. 83 Acquisition of satellite signals requires searching for the extremely 84 weak signal transmitted by each satellite. Each satellite transmits 85 a repeating signal. Acquiring the signal is done by synchronizing 86 with the received signal in both frequency and time. In order to 87 synchronize, the receiver searches in two dimensions: 89 time/code phase: The distance between the satellite and receiver 90 means that the receiver sees a signal that is offset in time. The 91 amount of time shift is known as code phase since it is measured 92 within the window of the repeated code sequence. Code phase forms 93 the primary measurement used in calculating a position. 95 frequency: The relative speed of satellite and receiver causes 96 Doppler shift of the satellite signal. 98 Satellite signals are typically modulated at a low rate with a 99 navigation message. The navigation message provides information that 100 is used in the final calculation phase including information on 101 satellite orbit, satellite health, time model, atmospheric effects on 102 the signal. This data is transmitted at very low rates to avoid 103 hampering the acquisition process, therefore acquiring this 104 information can take a signficant amount of time. 106 Once satellite signals have been acquired and measured, the 107 measurement information is combined with the information from the 108 navigation message and a position (and time) can be calculated. 109 Successful calculation of a position typically requires measurement 110 data for a minimum of 5 satellites unless otherwise supplemented. 112 If a receiver has to perform all these steps independently, satellite 113 acquisition and receipt of the navigation message can take 114 significant amounts of time. Improvements in receiver design have 115 increased receiver sensitivity and the speed that signals are 116 acquired. Use of assistance data provides a dramatic improvement in 117 the time taken to acquire signals and produce a result. 119 This document provides a means of combining a request for GNSS 120 assistance data with a HELD [I-D.ietf-geopriv-http-location-delivery] 121 request. 123 1.1. Advantages of Assistance Data 125 GNSS assistance data is information provided to a receiver that is 126 provided to improve the quality and timeliness of GNSS measurements 127 or positioning. The most basic set of assistance data includes the 128 same information provided in the navigation message. Additional 129 forms of assistance data include information customized to a 130 particular receiver to assist it in acquiring signals, or information 131 about satellite ephemerides (orbits) that is useful over a longer 132 period of time. 134 Acquiring assistance data from the network completely removes the 135 need to receive the navigation message. Navigation message content 136 can be transmitted to the receiver using the vastly more efficient 137 communication paths provided by a data network. This removes a 138 significant step from the process of determining a position. 140 Knowing what satellites to search for can reduce signal acquisition 141 time. One of the most basic pieces of information provided by 142 assistance data is knowledge of which satellites are above the 143 horizon and can therefore be measured. Concentrating on "visible" 144 satellites ensures that less time is wasted where signals could not 145 possibly be found. 147 Assistance data can provide information about where in the frequency/ 148 code phase space to search for a particular satellite signal. This 149 reduces the time required to acquire a satellite signal. Since an 150 approximate frequency and code phase can be known, it becomes 151 feasible to spend more time searching for weaker signals, improving 152 receiver sensitivity. Improved sensitivity ensures that GNSS can be 153 used in areas where signal penetration is poor, like buildings and 154 other areas with poor sky visibility, and increases the likelihood of 155 getting sufficient satellite measurements to calculate a position. 157 Assistance data also enables compensation for the effects of the 158 navigation message. Knowing the content of the navigation message 159 ahead of time means that the receiver is able to anticipate the 160 effect of its modulation on the signal and compensate accordingly. 161 This increases the sensitivity of the receiver and allows for faster 162 signal acquisition. 164 2. Conventions used in this document 166 The key words "must", "must not", "required", "shall", "shall not", 167 "should", "should not", "recommended", "may", and "optional" in this 168 document are to be interpreted as described in [RFC2119]. 170 3. The GNSS Reference Information Protocol 172 The GNSS Reference Information Protocol (GRIP) is a protocol that is 173 used for the acquisition of GNSS assistance data. This document 174 describes how to use GRIP in conjunction with HELD to enable the use 175 of assisted GNSS positioning. 177 GRIP response message provides a set of several different types of 178 assistance data. A set of assistance data types for GPS is shown in 179 Table 1. The scope of each field is also included to shown whether 180 the data applies globally, to a specific area only (local), or could 181 apply to either. 183 +-----------------+--------+----------------------------------------+ 184 | Type | Scope | Description | 185 +-----------------+--------+----------------------------------------+ 186 | UTC Model | Global | models the difference between GPS time | 187 | | | and UTC time | 188 | Ionospheric | Global | models the propagation delay on | 189 | Model | | satellite signals caused by the | 190 | | | ionosphere | 191 | Almanac | Either | a low-detail, long-term model of | 192 | | | satellite orbits and clocks | 193 | Real Time | Either | identifies satellites that should not | 194 | Integrity | | be used | 195 | Navigation | Either | models the orbit of the satellite over | 196 | Model | | time | 197 | TOW Assist | Either | aids in signal acquisition | 198 | Acquisition | Local | for fast signal acquisition | 199 | Assistance | | | 200 | Differential | Local | parameters for fine tuning calculated | 201 | GPS Corrections | | results | 202 +-----------------+--------+----------------------------------------+ 204 Table 1: Assistance Data Types for GPS 206 Data marked as either global or specific to a particular location 207 contains information about individual satellites. This information 208 is localized by constraining the information to the set of satellites 209 that are expected to be visible from that location. Information on 210 satellites that are on the other side of the Earth or below the 211 horizon is omitted. This ensures that a receiver is immediately able 212 to restrict the set of satellites that it searches for. 214 Acquisition assistance and differential GPS corrections always 215 contain localized information. Acquisition assistance contains a 216 prediction about the satellite signal for the given location that 217 narrows the size of the code phase and frequency space that needs to 218 be searched. Differential GPS is information on signal errors 219 provided by another receiver that is near the specified location. 220 Differential GPS corrections aids in the calculation of results by 221 providing fine tuning of the measurement data. 223 A GRIP request can include two parts, a request for global assistance 224 data and a request for localized assistance data. Each part 225 identifies the assistance data types that are required; a request for 226 localized data must also include location information. Location 227 information can be provided by-value or by-reference. 229 Note: GRIP, as reproduced in this document, is an incomplete 230 protocol that has the goal of providing a means for requesting 231 assistance data. Only the Global Position System (GPS) 232 constellation is supported in the messages that are included in 233 this document. This protocol does not fall within the scope of 234 the work performed by the target working group (GEOPRIV) and the 235 IETF in general. It is intended that this work find a more 236 appropriate home before this draft progresses. The information is 237 included as a temporary measure to ensure that it can be reliably 238 referenced from this document. 240 4. Operation 242 A Device that includes a GNSS receiver is able to request assistance 243 data as part of a HELD location request to a Location Information 244 Server (LIS). The request is included as an extension to the 245 location request and is ignored by a LIS that does not support this 246 specification, or cannot provide assistance data. The receiver 247 includes a GRIP assistance data request in a HELD location request. 249 250 252 253 254 255 urn:x-grip:location:requester 256 257 258 259 261 The assistance data request contains two parts, identifying the 262 global and local assistance data types that are requested. Global 263 assistance data can be provided without any extra information, but 264 localized assistance data requires that a location estimate for the 265 requester be known. Any request for localized assistance data must 266 include location information. Location information can be provided 267 by value, preferably using a geodetic form, or by reference. 269 GRIP requires location information when localized assistance data is 270 requested because a GRIP server cannot be assumed to have the ability 271 to locate requesters. However, in the case where the GRIP request is 272 placed in a HELD request, the LIS is certainly able to locate the 273 requester. To indicate that the LIS should generate the location 274 information necessary to generate localized assistance data a special 275 URN is used in place of the location reference. The 276 "urn:x-grip:location:requester" URN indicates that the server is 277 expected to generate location information for the requester and use 278 that in generating localized assistance data. The LIS MAY choose to 279 generate location information for any request and ignore the location 280 information provided. 282 The location response, along with the location information, includes 283 the requested assistance data. (Note: the "hexBinary" navigation 284 data is wrapped due to document constraints.) 285 286 288 289 290 292 293 00001F0000000890970E4B070E 294 0602FFFE2906FFF8 295 3 6 8 24 296 297 298 299 300 8B065C8CA0A465D0010045A5905BABDA135662BEDBA56B3A0000190E 301 FA448B065C8CA12AA5091B3176377C8F1907A6047F5A5E1653A10CCCA86B3A7E8B 302 065C8CA1AC0079F86A32C9FFF0269127BC14675EF1C04CFFAB23A5E094 303 304 305 8B065C8CA0A465D0000045A5905BABDA135662BEF4876B3A00FFF801 306 43D38B065C8CA12A870A2130D3A088963508A103EB9A411787A10C990D6B3A7E8B 307 065C8CA1ACFFFBF9331B37FFA6268B1C9813770AD0980CFFAB4C87E6B3 308 309 310 311 312 407 1 0 0 313 407 1 0 0 314 315 316 317 318 320 The response includes the information that was available to the LIS. 321 Unsupported or unavailable pieces of information are indicated using 322 the "unsupported" or "unavailable" attributes. 324 4.1. Assistance Data Types 326 Each assistance data type is specified as an XML element that is 327 included in either the "global" or "local" element of the assistance 328 data response. Assistance data formats for each different GNSS are 329 specified as separate elements. 331 A set of assistance data types are defined for GPS in Section 5 using 332 the namespace "urn:x-grip:gnss:gps". 334 Note: Different satellite systems share a number of key parameters, 335 and it could be useful to have a generic format for assistance 336 data that could be universally applicable. While the benefits of 337 a generic approach are obvious, this approach enables a more rapid 338 development of a specification without preventing a generic format 339 from being introduced later. 341 4.2. Identifying Assistance Data Types 343 A request for assistance data identifies the XML elements that 344 contain the assistance data by name. The "data" attribute can be 345 included on either the "global" or "local" element of the assistance 346 data request. The "data" attribute includes a whitespace-separated 347 list of elements. 349 Each item in this list is a qualified element name that identifies 350 the requested element. Each item can be interpreted as XML Path 351 Language (XPath) [W3C.REC-xpath20-20070123] expressions that are 352 evaluated in the context of the matching element in the response. 353 These statements are restricted to use of qualified names only. 354 Namespace prefixes are taken from the document context. 356 Each type of assistance data that is identified in the request must 357 be included in the corresponding "global" or "local" element of the 358 response. If information cannot be provided the LIS must indicate 359 which items are either unavailable (a temporary cause of error) or 360 unsupported (a situation that is more likely to be persistent). The 361 "unavailable" and "unsupported" attributes are used in the response 362 to indicate which items were not provided. Unsupported assistance 363 data types must be included in the response using the "unsupported" 364 attribute. 366 If an assistance data type is requested in an inapplicable category 367 (such as the UTC model in the "local" element), it must be reported 368 as "unsupported". 370 This method of identifying assistance data types enables easy 371 extension to forms of GNSS other than GPS or new types of assistance 372 data. By relying on the inherent extensibility provided by 373 namespaces in XML [W3C.REC-xml-names-20060816], extensions can be 374 readily addded. Extensions for other types of GNSS or assistance 375 data need only define elements in a new namespace. 377 4.3. Time Assistance 379 Time synchronization is helpful in ensuring rapid signal acquisition. 380 Satellite signals change with time, so having accurate time ensures 381 that the time-based information provided with assistance data can be 382 more effectively used. Accurate time also enables position 383 determination with fewer pseudorange measurements. 385 Other assistance data protocols define a reference time assistance 386 data type, which includes a time in the GNSS time system. However, 387 the mechanisms that are used to ensure that this information is 388 correct when received are dependent on the type of network. Without 389 these mechanisms, network latency and retransmission delays can 390 result in this value being incorrect when it is received. 392 This document does not define a mechanism for providing accurate time 393 as part of assistance data, instead relying on general purpose time 394 synchronization protocols. 396 The Network Time Protocol (NTP) [RFC1305] or Simple Network Time 397 Protocol (SNTP) [RFC4330] can be used by GNSS receivers to acquire 398 clock synchronization with Coordinated Universal Time (UTC). The 399 time model assistance data type (or UTC model for GPS) provides the 400 information necessary to translate from UTC to the time system used 401 by the GNSS. 403 A LIS does not provide information about time servers. Configuration 404 of hosts can be manual, or time server information can be provided by 405 DHCP ([RFC2132], [RFC3315], [RFC4075], [I-D.gayraud-dhcpv6-ntp-opt]). 407 5. GPS Assistance Data Types 409 This section defines a set of assistance data types for the GPS GNSS 410 (as shown in Table 1). Each assistance data type is defined as an 411 XML element and is able to be identified by the qualified name 412 [W3C.REC-xml-names-20060816] of the element. The GPS elements are 413 defined in the "urn:x-grip:gnss:gps" namespace. The "gps:" prefix is 414 used in this section to identify this namespace. 416 GPS assistance data is constructed based on the definition of the 417 navigation message defined in GPS interface control document 418 [GPS-ICD]. Assistance data that is provided on a per-satellite, or 419 space vehicle (SV), basis is split into "gps:sat" elements under each 420 data type. The satellite is identified by its SV-ID, a number 421 between 1 and 32, in the "num" attribute. 423 An XML Schema for GRIP messages is included in Appendix A. A schema 424 defining the format of assistance data for GPS is included in 425 Appendix B. 427 5.1. UTC Model 429 The UTC model contains the information necessary to convert from UTC 430 time to the time system used by GPS. The "gps:utc" element contains 431 a string of hexadecimal digits that correspond to bits 151 through 432 279 of subframe 4, page 18 of the navigation message, with the parity 433 bits removed. 435 5.2. Ionosphere Model 437 The ionosphere model contains parameters for a model of the 438 propagation delay through the ionosphere - the part of the Earth's 439 atmosphere that has the more significant impact on satellite signals. 440 The "gps:ionosphere" element contains a string of hexadecimal digits 441 that correspond to bits 69 through 145 of subframe 4, page 18 of the 442 navigation message, with the parity bits removed. 444 5.3. Almanac 446 The almanac assistance data type includes information about the 447 satellites in the GPS constellation. This information is intended to 448 be long-lived and changes rarely. This information is not useful for 449 calculating a position, but is helpful in determining what satellites 450 could be used. The "gps:almanac" element contains per-satellite 451 data. The content of the "gps:sat" element is a string of 452 hexadecimal digits that correspond to the collated almanac data from 453 the navigation message (subframe 5, pages 1 through 24; or subframe 454 4, pages 2, 3, 4, 5, 7, 8, 9 and 10). 456 5.4. Real Time Integrity 458 This data type contains a list of the satellite (SV) identifiers for 459 those satellites that are either out of service or are otherwise not 460 recommended for use. The "gps:rti" element contains a whitespace- 461 separated list of satellited identifiers. 463 5.5. Navigation Model 465 The navigation model contains information for each satellite in the 466 chosen set; either all GPS satellites, or those that are expected to 467 be visible from the estimated location of the Device. To that end, 468 the "gps:navigation" element contains one or more "gps:sat" elements. 469 The content of the "gps:sat" element is a hex string of 180 470 characters (90 bytes) that is sub-frames 1 through 3 of the 471 navigation message for the given satellite with parity bits removed. 473 5.5.1. Issue of Data Ephemeris 475 [[Editor's Note: Using IODE to save on bits is a practice that comes 476 over from the original bit-miserly protocols like RRLP that provided 477 GPS assistance data. The complexity of implementing this 478 functionality probably outweighs the relatively small saving in bits. 479 Candidate for removal.]] 481 The navigation model represents the largest and most significant 482 piece of assistance data provided. This information changes on an 483 hourly basis, and at each change the Issue of Data Ephemeris (IODE) 484 is changed. For this reason, a request that asks for the navigation 485 model is able to indicate the IODE for each satellite and the time 486 that this data was acquired. The response can omit satellites with 487 matching IODE. 489 An "gps:iode" element can be included in the "local" or "global" 490 element of the request. It identifies the current time (in UTC or 491 GPS time) and the IODE for each satellite that the receiver knows 492 about. 494 495 497 498 499 500 503 42.5463 -73.2512 504 505 850.24 506 507 508 509 510 66 511 66 512 513 514 515 517 Implementation of this feature by a GRIP server is optional. A GRIP 518 client that uses this option must be prepared to receive navigation 519 model information for satellites that it already has information for. 521 5.6. Time of Week Assistance 523 The time of week (TOW) assistance information includes the telemetry 524 (TLM) message, which is included every six seconds as the first word 525 of a subframe or page. The anti-spoof and alert flags from the 526 handover (HOW) word are also included in this item. This item can 527 change each time, but it rarely does; therefore, knowing the current 528 telemetry word aids in ensuring that the signal can be more rapidly 529 acquired. The "gps:towassist" element contains per-satellite data. 530 The data for each satellite is a whitespace-separated list of four 531 integers, starting with the 14-bits of the TLM message, then the 532 1-bit anti-spoof flag, the 1-bit alert flag and then the 2-bit 533 reserved portion from the TLM word. 535 5.7. Acquisition Assistance 537 Acquisition assistance aids receivers in satellite signal acquisition 538 by attempting to predict signals for a particular location at a 539 certain time. Acquisition assistance is synthesized from satellite 540 data; it is not a reconstruction of parts of the navigation message. 541 This data includes prediced code phase and doppler, plus a means to 542 predict how these change over time. This compact form allows for 543 faster measurement of the signals without necessarily enabling 544 position calculation. 546 The "gps:acqassist" element contains per-satellite data. Each 547 "gps:sat" element contains a list of floating point numbers as 548 described in Table 2. 550 +-------+-----------------+-----------------------------------------+ 551 | Order | Name | Description | 552 +-------+-----------------+-----------------------------------------+ 553 | 1 | 0th order | The predicted Doppler shift in Hz | 554 | | Doppler | | 555 | 2 | 1st order | The rate of change of Doppler shift in | 556 | | Doppler | Hz/s | 557 | 3 | Doppler Search | The range of Doppler shift values to | 558 | | Window | search in Hz | 559 | 4 | Code Phase | The predicted code phase in chips from | 560 | | | 0 to 1022 | 561 | 5 | Integer Code | The number of whole 1023 chip segments | 562 | | Phase | | 563 | 6 | Code Phase | The range of code phase values to | 564 | | Uncertainty | search | 565 | 7 | Azimuth | The azimuth (from Northing) of the | 566 | | | satellite in degrees | 567 | 8 | Elevation | The elevation (from horizontal) of the | 568 | | | satellite in degrees | 569 +-------+-----------------+-----------------------------------------+ 571 Table 2: Acquisition Assistance Fields 573 5.8. Differential GPS Corrections 575 Differential GPS provides a means of compensating for atmospheric 576 effects, orbital model limitation and satellite clock drift. The 577 "gps:dgps" element includes attributes that indicate the GPS time 578 when measurements were taken and per-satellite information. The 579 "gpsWeek" and "gpsTOW" attributes used for the IODE time are used to 580 provide a GPS time on the "gps:dgps" element. 582 The "gps:sat" element includes a whitespace-separated list of three 583 floating point values: 585 UDRE: an estimate of the accuracy of the pseudorange corrections in 586 metres 588 pseudorange correction: a correction value in metres, taken at the 589 time indicated 591 pseudorange correction rate of change: the rate that the pseudorange 592 correction changes in metres per second 594 6. Security Considerations 596 Since this document relies on bundling assistance data with a HELD 597 location response, it inherits many of the same security 598 considerations as HELD [I-D.ietf-geopriv-http-location-delivery]. It 599 also inherits all the protections provided therein; largely provided 600 by use of TLS [RFC4346]. 602 Privacy is a major consideration for location protocol security. 603 However, assistance data contains less useful information than the 604 location information that is already provided. The bulk of the 605 assistance data is either publically available or is derived from 606 that publically available data and the estimate location of the 607 Device. 609 Requesting localized assistance data from a GRIP server for an 610 arbitrary location provides little additional information over what 611 is provided by requesting global types. However, a request for 612 acquisition assistance could be used to trivially generate spoofed 613 GNSS measurements. [I-D.thomson-geopriv-held-measurements] provides 614 suggestions for dealing with spoofed GNSS measurements, but it is 615 recommended that a LIS not provide acquisition assistance for 616 arbitrary locations. 618 A Device that relies on assistance data could find that bad 619 assistance data is more of a hindrance than help. However, the 620 impact of an attack by a LIS on assisted GNSS is limited by the fact 621 that bad assistance data can be readily ignored and autonomous 622 operation used. 624 7. IANA Considerations 626 No registrations are necessary for GRIP namespaces (these are not 627 registered by this document). 629 8. Acknowledgements 631 This document uses a modified copy of the GRIP protocol based on the 632 work done by the University of New South Wales through the OSGRS 633 project . Authors of the original 634 GRIP specification were Nam Hoang and Manosh Fernando. The GPS 635 expertise of Neil Harper was invaluable in assembling this document. 637 9. References 639 9.1. Normative References 641 [RFC2119] Bradner, S., "Key words 642 for use in RFCs to 643 Indicate Requirement 644 Levels", BCP 14, RFC 2119, 645 March 1997. 647 [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, 648 J., Thomson, M., and B. 649 Stark, "HTTP Enabled 650 Location Delivery (HELD)", 651 draft-ietf-geopriv-http- 652 location-delivery-07 (work 653 in progress), April 2008. 655 [W3C.REC-xpath20-20070123] Berglund, A., Chamberlin, 656 D., Robie, J., Boag, S., 657 Kay, M., Simeon, J., and 658 M. Fernandez, "XML Path 659 Language (XPath) 2.0", 660 World Wide Web Consortium 661 Recommendation REC- 662 xpath20-20070123, 663 January 2007, . 667 [GPS-ICD] "Navstar GPS Space Segment 668 / Navigation User 669 Interfaces", ICD-GPS- 670 200c, April 2000. 672 9.2. Informative References 674 [RFC1305] Mills, D., "Network Time 675 Protocol (Version 3) 676 Specification, 677 Implementation", RFC 1305, 678 March 1992. 680 [RFC4330] Mills, D., "Simple Network 681 Time Protocol (SNTP) 682 Version 4 for IPv4, IPv6 683 and OSI", RFC 4330, 684 January 2006. 686 [RFC2132] Alexander, S. and R. 687 Droms, "DHCP Options and 688 BOOTP Vendor Extensions", 689 RFC 2132, March 1997. 691 [RFC3315] Droms, R., Bound, J., 692 Volz, B., Lemon, T., 693 Perkins, C., and M. 694 Carney, "Dynamic Host 695 Configuration Protocol for 696 IPv6 (DHCPv6)", RFC 3315, 697 July 2003. 699 [RFC4075] Kalusivalingam, V., 700 "Simple Network Time 701 Protocol (SNTP) 702 Configuration Option for 703 DHCPv6", RFC 4075, 704 May 2005. 706 [RFC4346] Dierks, T. and E. 707 Rescorla, "The Transport 708 Layer Security (TLS) 709 Protocol Version 1.1", 710 RFC 4346, April 2006. 712 [I-D.thomson-geopriv-held-measurements] Thomson, M. and J. 713 Winterbottom, "Using 714 Device-provided Location- 715 Related Measurements in 716 HELD", draft-thomson- 717 geopriv-held-measurements- 718 02 (work in progress), 719 May 2008. 721 [I-D.gayraud-dhcpv6-ntp-opt] Gayraud, R. and B. 722 Lourdelet, "Network Time 723 Protocol (NTP) Server 724 Option for DHCPv6", draft- 725 gayraud-dhcpv6-ntp-opt-01 726 (work in progress), 727 February 2008. 729 [W3C.REC-xml-names-20060816] Tobin, R., Hollander, D., 730 Bray, T., and A. Layman, 731 "Namespaces in XML 1.0 732 (Second Edition)", World 733 Wide Web Consortium Recomm 734 endation REC-xml-names- 735 20060816, August 2006, . 739 Appendix A. GRIP Schema 741 The following schema document defines the request and response 742 elements for the GNSS Reference Interface Protocol (GRIP). 744 745 752 753 754 This document describes the format of GNSS assistance data 755 requests. 756 757 759 760 761 762 763 764 765 766 768 769 770 771 772 773 774 776 777 778 779 780 781 782 783 784 786 787 788 789 791 792 793 794 795 797 798 799 800 801 802 804 805 806 807 808 809 810 811 813 814 815 816 817 818 819 821 822 823 824 825 827 828 830 832 833 834 836 837 838 840 842 Appendix B. GRIP GPS Data Schema 844 The following schema document defines the elements for GPS assistance 845 data, based on the outline in Section 5. 847 848 855 856 857 This document describes the format of GPS assistance data. 858 859 861 863 864 865 866 867 869 870 871 872 873 875 876 877 878 880 881 882 884 885 886 887 888 890 891 892 893 894 895 896 897 898 899 900 901 902 903 905 906 907 909 910 911 913 915 916 917 918 919 920 922 923 924 925 926 927 929 930 931 932 934 935 936 937 938 939 940 941 942 943 944 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 962 963 964 965 966 967 968 969 970 971 972 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 991 992 993 994 995 996 997 998 999 1000 1001 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1078 1080 Authors' Addresses 1082 Martin Thomson 1083 Andrew Corporation 1084 PO Box U40 1085 Wollongong University Campus, NSW 2500 1086 AU 1088 Phone: +61 2 4221 2915 1089 EMail: martin.thomson@andrew.com 1090 URI: http://www.andrew.com/ 1091 James Winterbottom 1092 Andrew Corporation 1093 PO Box U40 1094 University of Wollongong, NSW 2500 1095 AU 1097 Phone: +61 242 212938 1098 EMail: james.winterbottom@andrew.com 1099 URI: http://www.andrew.com/products/geometrix 1101 Full Copyright Statement 1103 Copyright (C) The IETF Trust (2008). 1105 This document is subject to the rights, licenses and restrictions 1106 contained in BCP 78, and except as set forth therein, the authors 1107 retain all their rights. 1109 This document and the information contained herein are provided on an 1110 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1111 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1112 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1113 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1114 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1115 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1117 Intellectual Property 1119 The IETF takes no position regarding the validity or scope of any 1120 Intellectual Property Rights or other rights that might be claimed to 1121 pertain to the implementation or use of the technology described in 1122 this document or the extent to which any license under such rights 1123 might or might not be available; nor does it represent that it has 1124 made any independent effort to identify any such rights. Information 1125 on the procedures with respect to rights in RFC documents can be 1126 found in BCP 78 and BCP 79. 1128 Copies of IPR disclosures made to the IETF Secretariat and any 1129 assurances of licenses to be made available, or the result of an 1130 attempt made to obtain a general license or permission for the use of 1131 such proprietary rights by implementers or users of this 1132 specification can be obtained from the IETF on-line IPR repository at 1133 http://www.ietf.org/ipr. 1135 The IETF invites any interested party to bring to its attention any 1136 copyrights, patents or patent applications, or other proprietary 1137 rights that may cover technology that may be required to implement 1138 this standard. Please address the information to the IETF at 1139 ietf-ipr@ietf.org.