TOC 
Network Working GroupV. Singh
Internet-Draft 
Intended status: Standards TrackH. Schulzrinne
Expires: January 13, 2009Columbia University
 H. Tschofenig
 Nokia Siemens Networks
 July 12, 2008


Dynamic Feature Extensions to the Presence Information Data Format Location Object (PIDF-LO)
draft-singh-geopriv-pidf-lo-dynamic-03.txt

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 13, 2009.

Abstract

The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. This document extends the <location> element specified in RFC 4119 to carry temporal feature elements useful for tracking moving objects. It defines five elements, namely speed, bearing, acceleration elevation and directionOfObject. The document also specifies mechanisms to carry multiple moving object's status elements and proposes a mechanism to indicate the type of the PIDF-LO content.



Table of Contents

1.  Introduction
2.  Terminology
3.  Protocol Behavior
    3.1.  Indicating Use of Dynamic Feature PIDF-LO using SIP
    3.2.  Indicating Use of Dynamic Feature PIDF-LO using HELD
    3.3.  Units of Measure
    3.4.  GML DynamicFeature Schema Usage
4.  Transferring Multiple Location Objects
5.  Example
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgements
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Alternatives Considered
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

The Presence Information Data Format - Location Object (PIDF-LO) (see RFC 4119 [1] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.)) provides geographical location of the presentity. This corresponds to a physical location at a given instance of time. However, a number of applications, described below, can benefit from having access to information about changes in location. Location change information is likely to be useful for logistics and public safety. For example, shipping companies or dispatch centers can use it to track whether vehicles are deviating from an established path or exceeding speed limits.

This document defines a location vector by extending the the <location>, introduced by RFC 4119, to carry temporal feature elements:

speed:

Speed is the rate of motion. (The terms speed and velocity are often used interchangeably, but speed is a scaler, having magnitude only, while velocity is a vector quantity, having both magnitude and direction.)

This element contains a 'uom' (Units Of Measure) attribute, which is a reference to a reference system for the amount. The 'uom' attribute uses a URI to refer to a unit of measure definition. The GML document defines a set of convenience measure types described in ISO 19103. This is further explained in Section 3.3 (Units of Measure).

bearing:

Bearing is defined as the horizontal direction of one terrestrial point from another, expressed as the angular distance from a reference direction. It is usually measured from 000 degrees at the reference direction clockwise through 360 degrees.

The <bearing> element is of type gml:DirectionPropertyType and contains a gml:DirectionVector, gml:CompassPoint, DirectionKeyword, or a DirectionString element. This document profiles the usage of this GML element and suggests the usage of the <DirectionVector> element.

acceleration:

This element specifies the rate (usually rapid) at which something happens. The <acceleration> element also contains a 'uom' attribute.

directionOfObject:

The <directionOfObject> describes the instantaneous horizontal of the front of the object relative to true north and the vertical angle relative to the earth's spheroid. It uses the GML <directionVector> element.



 TOC 

2.  Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

This document uses the terminology from [3] (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.).



 TOC 

3.  Protocol Behavior

The document describes the protocol requirements for dynamic feature extensions, so that it can be transmitted by the Location Server or the Location Information Server and understood correctly by Location Recipients. Location Recipients should be able to indicate to the server that they can handle the dynamic feature elements. The server should also indicate to the clients that the type of location object is PIDF-LO including the dynamic feature extension. Also, the unit of measurements should be communicated by server and understood by the clients.



 TOC 

3.1.  Indicating Use of Dynamic Feature PIDF-LO using SIP

The watcher can can indicate its capability using the SIP Accept header. This document proposes to add a 'supported' parameter for the application/pidf-xml media type. It enumerates the non default namespaces supported by the UAS. An example is given below:

Accept: application/pidf+xml; supported="geopriv-temporal-features"

The server can specify the type of content using Content-Type header. The specific PIDF-LO type can be obtained by looking inside the XML content.

Content-Type: application/pidf+xml;



 TOC 

3.2.  Indicating Use of Dynamic Feature PIDF-LO using HELD

There are two areas where it is useful to provide feature indication; the HELD context draft [6] (Winterbottom, J., Tschofenig, H., and M. Thomson, “Location URI Contexts in HTTP-Enabled Location Delivery (HELD),” October 2009.)" allows a Target (or an entity acting on behalf of the Target) to constraint the dereferencing procedure. Hence, it is useful to indicate whether dynamic features should or should not presented to the Location Recipient when a location URI is dereferenced.

Furthermore, when a dereferencing protocol based on HTTP is used then the Location Recipient might want to express the desire to receive a specific response, for example a PIDF-LO that contains a trace.

In a future version of this document the above-described functionality will be added.



 TOC 

3.3.  Units of Measure

GML permits a range of units of measure for the uom attribute. This document restricts this set to the #m/s

[ Editor's Note: Need to find the URN for #m/s]



 TOC 

3.4.  GML DynamicFeature Schema Usage

This document does not define a new schema but instead re-uses a subset of the dynamicFeature.xsd schema available with GML 3.1.1, namely <speed>, <bearing>, <acceleration>, and <directionOfObject>.

These four elements are conveyed inside the <location-info> element defined by RFC 4119 [1] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.).



 TOC 

4.  Transferring Multiple Location Objects

Multiple location vector objects may be required to be transported simultaneously. This can be achieved using <timed-presence> defined in RFC 4481 [4] (Schulzrinne, H., “Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals,” July 2006.).

Typically, the watcher applications can reconstruct the path as well as dynamic behavior (speed, acceleration etc.) along the path by storing the received location vector objects. However, a new Location Recipient may be interested in past location-vectors or may choose to receive notifications at a slower rate without losing valuable information. In other words, it can request to receive multiple location vector objects together. For example, it may want to get one NOTIFY every 15 minutes with multiple location objects aggregated.

The structure of the document which can be used for tracking moving objects using timed-status extension is shown below. An example is given in Section 5 (Example).


   <?xml version="1.0" encoding="UTF-8"?>
   <presence>

         <device>

               <gp:geopriv>
                ..........
               </gp:geopriv>

               <timestamp>.....</timestamp>

               <timed-status from="start-time" until="end-time">
                    <gp:geopriv>
                    ............
                    </gp:geopriv>

                    <gp:geopriv>
                    ...........
                    </gp:geopriv>

               </timed-status>
         </device>

         <tuple>
         .......
         </tuple>

         <person>
         .......
         </person>
   </presence>



 TOC 

5.  Example

The following example shows a PIDF-LO indicating geospatial location information using the gml:Point structure. Outside the <gml:location/> element the additional fields releated to temporal characteristics are included.



<?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="http://www.opengis.net/gml"
  entity="pres:geotarget@example.com">

  <device id="sg89ae">
      <gp:geopriv>
        <gp:location-info>
          <gml:location>
            <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
              <gml:pos>-34.407 150.883</gml:pos>
            </gml:Point>
          </gml:location>
          <gml:speed uom="#m/s">12</gml:speed>
          <gml:bearing>
            <gml:DirectionVector>
              <gml:vector> 270.0 -60.0</gml:vector>
            </gml:DirectionVector>
          </gml:bearing>
        </gp:location-info>
        <gp:usage-rules>
          <gp:retransmission-allowed>no</gp:retransmission-allowed>
          <gp:retention-expiry>2003-06-23T04:57:29Z
          </gp:retention-expiry>
        </gp:usage-rules>
      </gp:geopriv>
    <timestamp>2008-06-22T20:57:29Z</timestamp>
  </device>

</presence>

 Figure 1: Example of a PIDF-LO with Speed Information 

The following example shows multiple PIDF-LO using <timed-status>.



<?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">
  <device id="sg89ae">
         <gp:geopriv>
           <gp:location-info>
               <gml:location>
                  <gml:Point>
                     <gml:pos>140. -35.</gml:pos>
                  </gml:Point>
               </gml:location>
           <gml:speed uom="#m/s">12</gml:speed>
           </gp:location-info>
           <gp:usage-rules>
             <gp:retransmission-allowed>no</gp:retransmission-allowed>
             <gp:retention-expiry>2003-06-23T04:57:29Z
             </gp:retention-expiry>
           </gp:usage-rules>
         </gp:geopriv>
       <timestamp>2003-06-22T20:57:29Z</timestamp>

       <timed-statusfrom="2005-08-15T10:20:00.000-05:00"
          until="2005-08-22T19:30:00.000-05:00">>
          <gp:geopriv>
            <gp:location-info>
               <gml:location>
                  <gml:Point>
                     <gml:pos>110. -35.</gml:pos>
                  </gml:Point>
               </gml:location>
               <gml:speed uom="#m/s">10</gml:speed>
           </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>yes</gp:retransmission-allowed>
              <gp:retention-expiry>2003-06-23T04:55:29Z
              </gp:retention-expiry>
            </gp:usage-rules>
          </gp:geopriv>
          <gp:geopriv>
            <gp:location-info>
               <gml:location>
                  <gml:Point>
                     <gml:pos>114. -35.</gml:pos>
                  </gml:Point>
               </gml:location>
               <gml:speed uom="#m/s">18</gml:speed>
            </gp:location-info>
           <gp:usage-rules>
             <gp:retransmission-allowed>yes</gp:retransmission-allowed>
             <gp:retention-expiry>2003-06-23T04:53:29Z
             </gp:retention-expiry>
           </gp:usage-rules>
         </gp:geopriv>
       </timed-status>

     </device>
</presence>

 Figure 2: Example showing multiple Location Vectors transmitted simultaneously. 



 TOC 

6.  Security Considerations

This document defines additional location elements carried by PIDF-LO (see [1] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.)). The security considerations of RFC 4119 [1] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) are applicable to this document.



 TOC 

7.  IANA Considerations

[Editor's Note: This section needs to register a token for indicating the dynamic feature capability, see Section 3.1 (Indicating Use of Dynamic Feature PIDF-LO using SIP).]



 TOC 

8.  Acknowledgements

We would like to thank Carl Reed, Rohan Mahy, Cullen Jennings, Martin Thomson, Brian Rosen, and Klaus Darilion for their comments.



 TOC 

9.  References



 TOC 

9.1. Normative References

[1] Peterson, J., “A Presence-based GEOPRIV Location Object Format,” RFC 4119, December 2005 (TXT).
[2] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, BCP 14, March 1997.
[3] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” RFC 3693, February 2004 (TXT).
[4] Schulzrinne, H., “Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals,” RFC 4481, July 2006 (TXT).
[5] “Geographic information - Geography Markup Language (GML), OpenGIS 03-105r1, available at: http://portal.opengeospatial.org/files/?artifact_id=4700,” April 2004.


 TOC 

9.2. Informative References

[6] Winterbottom, J., Tschofenig, H., and M. Thomson, “Location URI Contexts in HTTP-Enabled Location Delivery (HELD),” draft-winterbottom-geopriv-held-context-05 (work in progress), October 2009 (TXT).


 TOC 

Appendix A.  Alternatives Considered

During the work on this document we encountered alternative approaches. These approaches make use of the MovingObjectStatus or its parent element track of dynamicFeature.xsd. MovingObjectStatus contains child elements where no use cases are currently known, e.g., validTime and contains elements that are already defined with PIDF-LO, such as <location>. Since it might not be know whether a Location Recipient understands the location extension defined in this document a PIDF-LO with a <location> element inside the <MovingObjectStatus> will likely create problems. Including the <location> element twice, once as defined with RFC 4119 (PIDF-LO) and again in <MovingObjectStatus>, is unnecessary. The <track> element allows multiple <MovingObjectStatus> to be used. Figure 3 (Example of a PIDF-LO with a track Element) shows such an instance document carrying the <track> element.



<?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="http://www.opengis.net/gml"
  entity="pres:geotarget@example.com">
  <device id="sg89ae">
      <gp:geopriv>
        <gp:location-info>
          <gml:track>
            <gml:MovingObjectStatus>
              <gml:validTime>
                <gml:TimeInstant>
                  <gml:timePosition>2005-11-28T13:00:00
                  </gml:timePosition>
                </gml:TimeInstant>
              </gml:validTime>
              <gml:location>
                <gml:Point>
                  <gml:pos>140. -35.</gml:pos>
                </gml:Point>
              </gml:location>
              <gml:speed uom="#kph">12</gml:speed>
              <gml:bearing>
                <gml:CompassPoint>SE</gml:CompassPoint>
              </gml:bearing>
            </gml:MovingObjectStatus>
            <gml:MovingObjectStatus>
              <gml:validTime>
                <gml:TimeInstant>
                  <gml:timePosition>2005-11-28T14:00:00
                  </gml:timePosition>
                </gml:TimeInstant>
              </gml:validTime>
              <gml:location>
                <gml:Point>
                  <gml:pos>140.1 -34.9</gml:pos>
                </gml:Point>
              </gml:location>
              <gml:speed uom="#kph">23.</gml:speed>
              <gml:bearing>
                <gml:CompassPoint>ESE</gml:CompassPoint>
              </gml:bearing>
            </gml:MovingObjectStatus>
          </gml:track>
        </gp:location-info>
        <gp:usage-rules>
          <gp:retransmission-allowed>no</gp:retransmission-allowed>
          <gp:retention-expiry>2003-06-23T04:57:29Z
          </gp:retention-expiry>
        </gp:usage-rules>
      </gp:geopriv>
    <timestamp>2003-06-22T20:57:29Z</timestamp>
  </device>
</presence>

 Figure 3: Example of a PIDF-LO with a track Element 

The authors decided to pick the simplest version.



 TOC 

Authors' Addresses

  Singh Vishal
 
Email:  singh.vishal@gmail.com
  
  Henning Schulzrinne
  Columbia University
  Department of Computer Science
  450 Computer Science Building, New York, NY 10027
  US
Phone:  +1 212 939 7004
Email:  hgs@cs.columbia.edu
URI:  http://www.cs.columbia.edu
  
  Hannes Tschofenig
  Nokia Siemens Networks
  Linnoitustie 6
  Espoo 02600
  Finland
Phone:  +358 (50) 4871445
Email:  Hannes.Tschofenig@gmx.net
URI:  http://www.tschofenig.priv.at


 TOC 

Full Copyright Statement

Intellectual Property