One document matched: draft-polk-geopriv-pidf-lo-ext-4-triangulation-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 05:48:00 |