Geopriv WG James Polk Internet-Draft Jay Iyer Expires: January 7, 2009 Cisco Systems Intended Status: Standards Track (PS) July 7, 2008 Updates: RFC 4119 and [ID-SIP-GET] (if published as an RFC) Extending the Presence Information Data Format - Location Object (PIDF-LO) for Assisted Global Positioning System (A-GPS) Data draft-polk-geopriv-pidf-lo-4-agps-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 January 7, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines how a device encapsulates Assisted Global Positioning System (A-GPS) data to ask a Location Information Server (LIS) to calculate the device's position, and return that information to the device. This communication will be completed using the Session Initiation Protocol (SIP), using Presence Filters specific to A-GPS in a (SUBSCRIBE) request, and a Presence Information Data Format - Location Object (PIDF-LO) as the (NOTIFY) reply. Polk Expires January 7, 2009 [Page 1] Internet-Draft PIDF-LO with A-GPS Data July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology and Acronym Explosion . . . . . . . . . . . . 3 2. Assisted-GPS Communications Overview . . . . . . . . . . . . 4 3. A-GPS Elements Defined . . . . . . . . . . . . . . . . . . . 5 3.1 Message Type=0 Assist Request . . . . . . . . . . . . . 6 3.2 Message Type=1 Assist Response . . . . . . . . . . . . . 7 3.3 Message Type=2 Location Request . . . . . . . . . . . . 9 3.4 Message Type=3 Location Response . . . . . . . . . . . . 9 4. XML Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 5. XML Schema for A-GPS within PIDF-LO . . . . . . . . . . . . . 14 6. Filters to ask for A-GPS within SUBSCRIBE . . . . . . . . . . 14 7. Known Open Issues . . . . . . . . . . . . . . . . . . . . . .14 8. Security considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 Full Copyright Statement and Intellectual Property . . . . . 16 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 RFC 2119 [RFC2119]. 1. Introduction US Global Positioning System (GPS) is widely accepted to enable clients to calculate their location based on data the device receives from satellites. In order to compute the location, an entity must triangulate data received from at least three satellites. For an initial cold start, the GPS device must wait a certain time called the Time-to-First-Fix (TTFF), before it can successfully begin reporting the location. Under certain circumstances, this time can be as long as 12 minutes. The device must also have a line of site view to at least three satellites to successfully get a position fix. This also causes additional battery drain on mobile devices. In order to address these line of site and timing problems, primarily to reduce the TTFF, a solution called the Assisted GPS (A-GPS) has been deployed [IEEE-1]. A-GPS works by allowing devices to obtain ephemeris data from an Assisted GPS server. Assisted GPS enables faster computation of the location information at the clients. This document describes the messaging required to enable Assisted GPS computation on client devices - based on the SIP subscription model established in RFC 3265 [RFC3265], as well as Polk Expires January 7, 2009 [Page 2] Internet-Draft PIDF-LO with A-GPS Data July 2008 augmenting the PIDF-LO, as defined in RFC 4119 [RFC4119], to encapsulate additional location related data to a Assisted GPS server. Additionally, this document will define a set of Presence filters to identify within the SIP SUBSCRIBE what is wanted in the NOTIFY. This set of filters is an extension of the SIP 'Location Get' filters first described in here [ID-SIP-GET]. 1.1 Terminology and Acronym Explosion The following terms will be used within this document A-GPS Assisted Global Positioning System - A method of GPS positioning where the receiver is assisted through a means other than directly from the GPS satellites. BS Base Station [RFC5154] - A generalized equipment set that provides connectivity, management, and control between the subscriber station and IEEE 802.16 network. The term BS can also be applied to cellular systems DGPS Differential Global Positioning System (DGPS) is an enhancement to Global Positioning System that uses a network of fixed, ground-based reference stations to broadcast the difference between the positions indicated by the satellite systems and the known fixed positions Ephemeris An ephemeris is a table of values that gives the positions of astronomical objects in the sky at a given time or times LIS Location Information Server - a special instance of a Location Server that consolidates locations of endpoints and responds to queries for locations of devices. LBS Location Based Services LS Location Server. Defined in RFC 3693 as a device that receives location from a Location Target directly, or from another LS in a chain of LSs, and transmits location to another LS. An LS does not response to queries about a Target's location. MAC Media Access Protocol. MS, SS, MSS: Mobile Station (MS), Subscriber station (SS), Polk Expires January 7, 2009 [Page 3] Internet-Draft PIDF-LO with A-GPS Data July 2008 Mobile Node (MN) [RFC5121] - The terms subscriber station, mobile station, and mobile node are used to convey the same semantics in this document and refer to an IP host. TTFF Time to First Fix. The time required by a GPS receiver to first calculate its position. UTC Coordinated Universal Time 2. Assisted-GPS Communications Overview The GPS devices must have network connectivity for the 'A' in A-GPS in order to get this ephemeris data from the server. These devices usually have a cellular or wireless LAN connection in order to contact the Assisted GPS server. The Assisted GPS server, with good satellite reception and computational power, can assist the client devices to obtain satellite constellation information known as the almanac, satellite ephemeris data, thereby reducing the TTFF. In addition to improving the TTFF, A-GPS requires less computational power and consumes less power at client devices when compared to traditional GPS. A device capable of using Assisted GPS obtains dynamic assistance information from the Location Information Server (LIS), and requires connectivity or attachment to the network. The A-GPS capable device can take advantage of assists during at least the following scenarios: 1. during boot time - when a device initially powers up 2. at network attachment time - when a device detects attachment to a network 3. Periodically, while attached to the network. 4. On demand, while attached to the network. The type of server that does this calculation is some form of a LIS, one that is A-GPS capable. The device needs to contact a LIS, and request that it do the conversion. The answer from the LIS will be the conversion that is used. A-GPS does not have to be a one-time only communication (see Figure 1.). The device can create a subscription with the LIS for periodic or triggered updates (see Figure 2). If triggered updates are a requirement, then SIP appears to be the only IETF protocol (to date) that can accomplish this function, based on the subscription model it has. Polk Expires January 7, 2009 [Page 4] Internet-Draft PIDF-LO with A-GPS Data July 2008 A-GPS Device LIS | | | A-GPS Request | |------------------------------------>| | | | A-GPS Response | |<------------------------------------| Figure 1. Single Request for A-GPS A-GPS Device LIS | | | A-GPS Request | |------------------------------------>| | | | A-GPS Response | |<------------------------------------| | | | A-GPS Update | |<------------------------------------| | | | A-GPS Update | |<------------------------------------| | | | ********************** | | * some time might be * | | * between updates * | | ********************** | | | | A-GPS Update | |<------------------------------------| | | Figure 2. Single Request, Multiple Responses for A-GPS In Figure 2, the request might create a subscription, asking that more than one notification be sent back to the device. These notifications can be periodic, meaning at a certain interval in time until the subscription is updated or terminated. These notifications can be triggered by the device moving, or thinks it has moved. How a device detects this is out of scope of this document. 3. A-GPS Elements Defined RFC 4119 extended the PIDF [RFC3863] element with a complex element called . PIDF-LO also created two major subselements which are encapsulated within : one for location information and one for usage rules. This document does not affect the usage rules subelement. The element Polk Expires January 7, 2009 [Page 5] Internet-Draft PIDF-LO with A-GPS Data July 2008 MUST contain one or more directives indicating the XML schema(s) that are used for geographic location formats, according to RFC 4119. This document creates a new schema under the element, effectively lateral to geo-coordinate location and civic location already established within RFC 4119. This extension to PIDF-LO creates the element. Below are the mandatory and optional XML subelements contained within the element, with definitions and value ranges. Out of respect for the WiMAX Forum, this payload will be minimal in size, because WiMAX deals with power constrained devices communicating over low speed links (or high speed links shared by many devices - sometimes allowing for each to only have a small part of the available bandwidth), therefore this needs to be thought of in terms of how the XML can be placed into a binary bit-map. There are 4 message types for adding A-GPS to the PIDF-LO, Location-Request, Location-Response, Assisted-Request and Assisted-Response. Some of the individual fields are mandatory (M), and some are optional (O). Each of the message types starts the same 3 elements, with the following elements: A-GPS Header (Mandatory fields) Message length (4 bytes) Length of the SIP Payload in bytes Transaction ID (2 bytes) Message Type (1 byte) MT = 0 for Assist-REQ MT = 1 for Assist-RSP MT = 2 for LOC-REQ MT = 3 for LOC-RSP The next set of elements within the XML depends on which of the 4 message types is being communicated. One, and only one of the following message types MUST appear as the next XML elements within the same PIDF-LO. (M) means an element is mandatory in the message type. (O) means the element is optional in the message type. 3.1 Message Type=0 Assist Request Satellite System Type (M) This is set to the type of GPS Polk Expires January 7, 2009 [Page 6] Internet-Draft PIDF-LO with A-GPS Data July 2008 satellite system in place. Choices for this element are Navstar, or Galileo. 1 byte : Local Reference Identifier (M) This is set to the local reference identifier, known to the client at the time of the query. A client accessing this over a wireless LAN network item 1 Local Reference ID (M) For WiMAX or cellular systems, this can be set to the Base-station ID, or for WiFi systems, this can be set to the Access Point MAC address. Assist-REQ from LS (M) (2 Bytes) bit map of the requested info: Bit 0: Location aid: coarse location aiding to assist the GPS measurements Bit 1: coarse time aid Bit 2: DGPS corrections Bit 3: navigational model Bit 4: Acquisition assistance Bit 5: Satellite health Bit 6: Ionospheric model Bit 7: UTC Model Bit 8: Almanac Bits 9-15: Reserved Aiding Mask (O) Aiding Mask for the satellites (32 bit quantity, 1 bit per satellite) Bit set => ephemeris for the satellite requested Periodicity (O) Periodicity of the response as expected by the Mobile System. Expressed in terms of time interval (minutes) between two consecutive Responses by LS. Needed only for periodic location Duration (O) Total duration for which the assist-REQ is valid (in minutes). Needed only for periodic location 3.2 Message Type=1 Assist Response > Satellite System Type (O) Local reference Identifier. Included if location aiding is requested by the Polk Expires January 7, 2009 [Page 7] Internet-Draft PIDF-LO with A-GPS Data July 2008 MS for MS initiated TTFF enhancements. For network initiated TTFF enhancement, this parameter is always included. >sign of latitude (O) North or south >latitude (O) Integer (0..2^23-1). The latitude encoded value (N) is derived from the actual latitude X in degrees (0..90) by this formula: N <= 2^23 X /90 < N+1 >longitude (O) Integer (-2^23.. 2^23-1). The longitude encoded value (N) is derived from the actual longitude X in degrees (-180..+180) by this formula: N <= 2^24 X /360 < N+1 >uncertainty ellipse (O) semi major, semi minor, major axis. Refer to Annex A in the LBS Spec >confidence level (O) Represents the confidence by which the position of a target entity is known to be within the shape description (i.e., uncertainty ellipse for 2D description, uncertainty ellipsoid for 3D description) and is expressed as a percentage. This is an integer (0..100). >Z height (O) Provides altitude information in meters Integer (0..2^15-1). Refer to annex A for details >Z height uncertainty (O) Contains the altitude uncertainty code. Refer to Annex A for details Time aid (O) Included if time aiding is requested by the MS for MS initiated TTFF enhancements. For network initiated TTFF enhancement, this parameter is always included. Assistance Data (O) Included, if requested by MS, based on the bit map set by the MS in the Assist-REQ message Polk Expires January 7, 2009 [Page 8] Internet-Draft PIDF-LO with A-GPS Data July 2008 Error code (O) Included in the event of an error. Please see LBS document for the codes 3.3 Message Type=2 Location Request (Optional unless otherwise indicated) Periodicity (O) Periodicity of the response as expected by the MS. Expressed in terms of time interval (seconds) between two consecutive Responses by LS. Needed only for periodic location. Duration (O) Total duration for which the LOC-REQ is valid (in seconds). Needed only for periodic location. Location capabilities (M) Indicates the capabilities of the MS. A bit vector: Bit 0: Uplink (TDOA) Time Difference of Arrival Bit 1: Down Link (DL) Round Trip Delay (RTD) measurements only Bit 2: DL RD measurements only Bit 3: DL Receive Signal Strength Indication (RSSI) measurements only Bits 4-7: reserved. Accuracy (O) Desired accuracy of the location response Latency (O) Desired Latency for the location response 3.4 Message Type=3 location Response MS location (M) Location of the MS as calculated by it. >Timestamp (M) Timestamp when location was calculated >sign of latitude (M) North or south >latitude (M) Integer (0..2^23-1). The latitude encoded value (N) is derived from the actual latitude X in degrees (0..90) by this formula: Polk Expires January 7, 2009 [Page 9] Internet-Draft PIDF-LO with A-GPS Data July 2008 N <= 2^23 X /90 < N+1 >longitude (M) Integer (-2^23.. 2^23-1). The longitude encoded value (N) is derived from the actual longitude X in degrees (-180..+180) by this formula: N <= 2^24 X /360 < N+1 >uncertainty ellipse (O) semi major, semi minor, major axis. Refer to Annex A in the LBS Spec >confidence level (O) Represents the confidence by which the position of a target entity is known to be within the shape description (i.e., uncertainty ellipse for 2D description, uncertainty ellipsoid for 3D description) and is expressed as a percentage. This is an integer (0..100). >Z height (O) Provides altitude information in meters Integer (0..2^15-1). Refer to annex A for details >Z height uncertainty (O) Contains the altitude uncertainty code. Refer to Annex A for details Error code (O) Included in the event of an error. Please see LBS document for the codes 4. XML Examples The following is an example taken from RFC4119 [RFC4119] (with an updated times) which provides GPS coordinates as its location format. All the security and privacy rules apply to this PIDF-LO extension as they do to RFC 4119, including any retransmission and retention-expiry elements. Polk Expires January 7, 2009 [Page 10] Internet-Draft PIDF-LO with A-GPS Data July 2008 37:46:30N 122:25:10W no 2008-08-03T04:57:29Z 2008-07-28T20:57:29Z Removing the non-location specific (i.e., header) elements, we have above this: 37:46:30N 122:25:10W no 2008-08-03T04:57:29Z This A-GPS extension will fit **here** in the schema below 37:46:30N 122:25:10W / **here** ... \ Polk Expires January 7, 2009 [Page 11] Internet-Draft PIDF-LO with A-GPS Data July 2008 no 2008-08-03T04:57:29Z 4.1 Example XML for Message Type=0 Assist Request (4 bytes) (2 bytes) (4 values) (2 bytes) (4 bytes) (range) (range) 4.2 Example XML for Message Type=1 Assist Response (4 bytes) (2 bytes) (4 values) Polk Expires January 7, 2009 [Page 12] Internet-Draft PIDF-LO with A-GPS Data July 2008 4.3 Example XML for Message Type=2 Location Request (4 bytes) (2 bytes) (4 values) duration> 4.4 Example XML for Message Type=3 Location Response (4 bytes) (2 bytes) (4 values) Polk Expires January 7, 2009 [Page 13] Internet-Draft PIDF-LO with A-GPS Data July 2008 5. XML Schema for A-GPS within PIDF-LO TBD 6. Filters to ask for A-GPS within SUBSCRIBE TBD 7. Known Open Issues This document is admittedly incomplete. There are many fields and definitions that are not expanded or explained. Part of this is due to synchronizing this document with the WiMAX Forum's WiMAX Location Protocol (WLP), which is still be worked on. Part of this is due to there not being enough time to complete this document. - does this extension to RFC 4119 necessitate extending the element to include the URI of the LIS? 8. Security considerations This document introduces no new security considerations from that in RFC 4119 [RFC4119]. 9. IANA considerations TBD (the modified PIDF-LO schema, the A-GPS filters, and the element will be listed here) 10. Acknowledgments Your name here... or if you contribute a fair amount of text, you can be a co-author. Polk Expires January 7, 2009 [Page 14] Internet-Draft PIDF-LO with A-GPS Data July 2008 11. References 11.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [IEEE-1] Djuknic, G. and R. Richton, "Geolocation and Assisted GPS", IEEE Computer, Feb 2001. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 [ID-SIP-GET] J. Polk, "Session Initiation Protocol (SIP) Location Get Function", draft-polk-sip-location-get-00, "work in progress", July 2008 [RFC5154] J. Jee et al, "IP over IEEE 802.16 Problem Statement and Goals", RFC 5154, [RFC5121] B. Patil, et al, "Transmission of IPv6 via the IPv6 Convergence Sub-layer over IEEE 802.16 networks", RFC 5121, [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004 [3GPP-1] 3GPP TS 44.031, Location Services (LCS); Mobile Station (MS) - Serving Mobile Location Center (SMLC) Radio Resource LCS Protocol (RRLP) 11.2. Informative References none Authors' Addresses James Polk 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@cisco.com Polk Expires January 7, 2009 [Page 15] Internet-Draft PIDF-LO with A-GPS Data July 2008 Jay Iyer 3625 Cisco Way San Jose , CALIFORNIA 95134 +1 408 527 2214 mailto: jiyer@cisco.com 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. Polk Expires January 7, 2009 [Page 16] Internet-Draft PIDF-LO with A-GPS Data July 2008 Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Polk Expires January 7, 2009 [Page 17]