Network WG James Polk Internet-Draft Cisco Systems Expires: January 7, 2009 July 7, 2008 Intended Status: Standards Track (PS) Updates: RFC 4119 and [ID-SIP-GET](if published as an RFC) A Presence Information Data Format - Location Object Extension for Triangulation Data draft-polk-geopriv-pidf-lo-ext-4-triangulation-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 describes how a Presentity Agent (PA) provides a Location Information Server (LIS) with location specific measurement data it observes, for example - how many satellites are visible to a PA, and at what angle are each currently, to aid the LIS in determining geographically where the PA is. This is done within a Session Initiation Protocol subscription framework where the LIS subscribes to the PA for its measurement data. The LIS performs the location calculation, determining where the PA is. Polk Expires January 7, 2009 [Page 1]
Internet-Draft PIDF-LO for Triangulation July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Triangulation Messaging Overview . . . . . . . . . . . . . . 3 3. The Triangulation Element . . . . . . . . . . . . . . . . . . 5 4. Navigational Measurements . . . . . . . . . . . . . . . . . . 7 5. XML Schema for PIDF-LO Extension for Triangulation . . . . . 8 6. Filters within SUBSCRIBE for Triangulation . . . . . . . . . 8 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Contributions . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 Full Copyright Statement and Intellectual Property . . . . . 10 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 This document describes how a Presentity Agent (PA) provides a Location Information Server (LIS) with location specific measurement data it observes, for example - how many satellites are visible to a PA, and at what angle are each currently, to aid the LIS in determining geographically where the PA is. This is done within a Session Initiation Protocol subscription framework where the LIS subscribes to the PA for its measurement data. The LIS performs the location calculation, determining where the PA is. This ability classifies the LIS as a Location Sighter, as defined in RFC 3693 [RFC3693]. This document focuses on a subscription model to accomplish the notifications from the PA whenever it determines it has moved. This would result in a new notification being sent to the LIS with the newly observed measurement data for the LIS to do the new location calculation. In this model, the LIS establishes a subscription to last over time to the PA. Within this subscription, the PA will be told how often to reply. It could be periodically, i.e., at a set interval of time like every minute for the life of the subscription, or based on some trigger. A trigger can be agreed to between PA and LIS, perhaps based on the movement observed by the PA itself. For example, the PA may detect it has new measurement data from the Polk Expires January 7, 2009 [Page 2]
Internet-Draft PIDF-LO for Triangulation July 2008 satellites it has in view (GPS or Galileo system), or from the radio towers (WiMAX). This creates a means of triangulation, when more than one radio signal is being observed or measured from two different transmission sources. Knowing the each radio signal is coming from, a distance can be calculated based on the intersecting lines from those sources. The more sources the better (and more accurate) Time-to-First-Fix, or TTFF. A Presence Information Data Format - Location Object (PIDF-LO), as defined in RFC 4119 [RFC4119] is the location object extension to the Presence Information Data Format (PIDF) defined in RFC 3863 [RFC3863] used to carry Presence state information about a Presentity. Any protocol that carries this PIDF-LO extension needs to comply with the rules and policies within RFC 3693 [RFC3693] as a "Using Protocol". This document describes how this PIDF-LO extension is used within SIP, just as [ID-SIP-CON] has passed this validation, this PIDF-LO extension does not introduce any new Using Protocol concerns relative to SIP. This document describes how a LIS subscribes for, and receives the notifications from the PA - and extends RFC 4119 to accomplish this transmission of measurement (presence) data from PA to LIS. This document does not determine how the PA's location is calculated. As with all measurements, there can be error introduced. This document does not account for the error introduced, either from how the PA observes the direction of each signal, or how the LIS calculates (i.e., which algorithm is used to) the received measurable data from the PA. This document only describes how the LIS subscribes to the PA, and sets up how often the LIS receives new updates from the PA. Section 2 provides an overview of the messaging to carry this PIDF-LO extension for triangulation. Section 3 specifies the Triangulation element. Section 4 discusses the particulars about the measurement data and the extension to the PIDF-LO XML, with Section 5 containing the XML schema. Section 6 details the filters to be used by the LIS to create the specific subscription for triangulation measurement data, as well as the triggers (upon movement of the PA). Section 7 discusses any known open issues, and specifically seeks input to a few questions. Section 10 lists the current contributors to this document. 2. Triangulation Messaging Overview The message flow for this extension to the RFC 4119 defined PIDF-LO is pretty simple. The Location Information Server (LIS) will create a subscription with a Location Target to learn its location. This is accomplished using the location 'get' function first described in [ID-SIP-GET]. The LIS will need a new set of filters specifically to ask the PA if it can supply triangulation data back to the LIS Polk Expires January 7, 2009 [Page 3]
Internet-Draft PIDF-LO for Triangulation July 2008 for the LIS to do the location determination. The LIS will include an indication within the filter document how long it wants to maintain a dialog with the PA. The PA gets to decide how long the subscription lasts, and what information the LIS has access to. RFC 3856 [RFC3856] states that all subscriptions are to be authentication challenged, therefore the PA needs to be prepared to challenge the LIS for this information - and the LIS need to be prepared to for this challenge. Digest is the mechanism RFC 3261 specifies. Once a subscription is authenticated, the PA needs to be make policy decision whether or not to accept the request, and how specific the data is that is revealed. A 200 OK is the final response for accepting this subscription. The PA now sends a NOTIFY immediately, with the radio, cell tower or satellite signal information for the LIS to perform location determination. The LIS will probably include a filter for the PA for if it moves, send new signal observations to the LIS. The LIS might define how far 'movement' is so it does not receive a NOTIFY for every inch the PA moves. PA/UA LIS | | | SUBSCRIBE (w/ filters) | |<------------------------------------| | | | 200 OK | |------------------------------------>| | | | NOTIFY (w/ PIDF-LO) | |------------------------------------>| | | | 200 OK | |<------------------------------------| | | | ********************** | | * PA movement * | | ********************** | | | | new NOTIFY (w/ PIDF-LO) | |------------------------------------>| | | | 200 OK | |<------------------------------------| | | | ********************** | | * PA movement * | | ********************** | | | Polk Expires January 7, 2009 [Page 4]
Internet-Draft PIDF-LO for Triangulation July 2008 | new NOTIFY (w/ PIDF-LO) | |------------------------------------>| | | | 200 OK | |<------------------------------------| | | Figure 1. LIS Subscribes to PS for Triangulation Data 3. The Triangulation Element RFC 4119 extended the PIDF [RFC3863] <status> element with a complex element called <geopriv>. PIDF-LO also created two major subselements which are encapsulated within <geopriv>: one for location information and one for usage rules. This document does not affect the usage rules subelement. The <location-info> element 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 <location-info> element, lateral to geodetic location and civic location already established within RFC 4119. This extension to PIDF-LO creates the <gp:triangulation> element. Below are the mandatory and optional XML subelements contained within the <gp:triangulation> element, with definitions and value ranges. 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. <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" entity="pres:geotarget@example.com"> <tuple id="sg89ae"> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point1" srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W</gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2008-08-03T04:57:29Z</gp:retention-expiry> Polk Expires January 7, 2009 [Page 5]
Internet-Draft PIDF-LO for Triangulation July 2008 </gp:usage-rules> </gp:geopriv> </status> <timestamp>2008-07-28T20:57:29Z</timestamp> </tuple> </presence> Figure 2. RFC 4119 PIDF-LO XML Example Removing the non-location specific (i.e., header) elements, we have above this: <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point1" srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W</gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2008-08-03T04:57:29Z</gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> Figure 3. Subset of RFC 4119 PIDF-LO XML Example This triangulation extension will fit **here** in the schema below, which is lateral to any <gml:location> (where a point would be defined) or <cl:civicAddress> (where all civic addressing) would be under: <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point1" srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W</gml:coordinates> </gml:Point> </gml:location> / <gp:triangulation> **here** ... \ </gp:triangulation> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2008-08-03T04:57:29Z</gp:retention-expiry> </gp:usage-rules> Polk Expires January 7, 2009 [Page 6]
Internet-Draft PIDF-LO for Triangulation July 2008 </gp:geopriv> </status> Figure 4. Inserting Triangulation into XML Subset Example 4. Navigational Measurements Within each radio based measurement system designed for navigational purposes, devices receive broadcast signals from certain sources it knows to look for. Generally the broadcast signals are different for each system. A device designed to determine the time and direction of these sources can apply an algorithm to determine where that devices is. If the algorithm is not local to the device, another device can be used to help in the location determination. A receiver needs to learn which satellites or radio/cell towers it can see in order to provide any meaningful information to a LIS to do a calculation (based on the data provided by the endpoint. Here is an example from [ID-GP-LDM] modified for this extension of PIDF-LO, which shows observations from 3 satellites: <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point1" srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W</gml:coordinates> </gml:Point> </gml:location> <gp:triangulation> <gp:satellite> <sat num="19"> <doppler>499.9395</doppler> <codephase rmsError="1.6e-9">0.87595747</codephase> <cn0>45</cn0> </sat> <sat num="27"> <doppler>378.2657</doppler> <codephase rmsError="1.6e-9">0.56639479</codephase> <cn0>52</cn0> </sat> <sat num="20"> <doppler>-633.0309</doppler> <codephase rmsError="1.6e-9">0.57016835</codephase> <cn0>48</cn0> </sat> </gp:satellite> </gp:triangulation> </gp:location-info> <gp:usage-rules> Polk Expires January 7, 2009 [Page 7]
Internet-Draft PIDF-LO for Triangulation July 2008 <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2008-08-03T04:57:29Z</gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> Figure 5. Satellite Triangulation into XML Subset Example Each satellite has a unique number associated with it, within a given system. The example is about 3 satellites, so there are 3 <sat> elements. There is no preference or order to these elements. The existing <timestamp> field within the PIDF-LO is used to indicate when the signal observations were made, to give the LIS the ability to make a precise location determination. Each of the elements is defined here (which are very similar to those in [ID-GP-LDM], since the data part of the example was borrowed from that ID): <sat num=""> is the satellite number within a given constellation system of satellites (GPS has one set, Galileo has another set). Each satellite is numbered, and this number of part of the broadcast message devices received to learn which specific satellites it can see at any one time. This is critical for location determination. <doppler> This is an observation of the Doppler shift, measured in meters per section. <codephase rmsError> The observed code phase, measured in milliseconds, for the satellite signal. This value includes an optional RMS error attribute. <cn0> The signal to noise ratio for the satellite signal, measured in decibel-Hertz (dB-Hz). 5. XML Schema for PIDF-LO Extension for Triangulation TBD 6. Filters within SUBSCRIBE for Triangulation TBD 7. Open Issues The following are known open issues not yet discussed above: Polk Expires January 7, 2009 [Page 8]
Internet-Draft PIDF-LO for Triangulation July 2008 - should this document be expanded to include any radio based triangulation, such as cellular networks or 802.11 networks? - need the XML schema - need the filters unique to triangulation - Does this ID need a WiMAX example? 8. Security considerations This document does not introduce any new security considerations beyond those in RFC 4119. 9. IANA considerations This document does not have any IANA actions (though that will likely change in future revs of this doc). 10. Contributions The author would like to thank the following individuals for contributing text and ideas to this document, even if they did not know it prior to doing so: James Winterbottom Andrew Corporation Martin Thomson Andrew Corporation as this document borrowed an example from their Internet Draft draft-thomson-geopriv-held-measurements-02.txt, along with a few definitions. 11. Acknowledgments The author would like to thank Marc Linsner for helping adapt this idea into a document. 12. References 12.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 Polk Expires January 7, 2009 [Page 9]
Internet-Draft PIDF-LO for Triangulation July 2008 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004 [ID-SIP-GET] J. Polk, "Session Initiation Protocol (SIP) Location Get Function", draft-polk-sip-location-get-00, "work in progress", July 2008 12.2 Informative References [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 [ID-GP-LDM] M. Thomson, J. Winterbottom, "Using Device-provided Location-Related Measurements in HELD", draft-thomson-geopriv-held-measurements-02.txt, "work in progress", Feb 2008 Authors' Addresses James Polk 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@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. Polk Expires January 7, 2009 [Page 10]
Internet-Draft PIDF-LO for Triangulation July 2008 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Polk Expires January 7, 2009 [Page 11]