One document matched: draft-barnes-periodic-location-retrieval-00.txt
GEOPRIV M. Barnes
Internet-Draft Nortel
Intended status: Informational October 27, 2008
Expires: April 30, 2009
Periodic Retrieval of Location Information by Devices and Location
Information Servers
draft-barnes-periodic-location-retrieval-00.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 April 30, 2009.
Abstract
The base HTTP Enabled Location Delivery (HELD) protocol includes
options for retrieving location information from a LIS by a Device.
Some networks require the ability for the device to periodically
request location information from the LIS and/or for the LIS to
periodically request location information from the device.
Extensions to base HELD allow a Device to establish a context with a
LIS and negotiate capabilities of the Device in terms of providing
location information. The measurement extensions to base HELD allow
the LIS to request location information from a Device. This document
provides an overview of the requirements and a solution using HELD
and HELD extensions to support the periodic request of location
Barnes Expires April 30, 2009 [Page 1]
Internet-Draft Periodic Location Information Exchange October 2008
information, both by a Device from an LIS and by the LIS from a
Device, depending upon the specific scenario and measurement
capabilities of the Device.
Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3
3. Device to LIS Periodicity . . . . . . . . . . . . . . . . . . 4
4. LIS to Device Periodic Location Requests . . . . . . . . . . . 6
5. Additional Considerations and Potential Enhancements . . . . . 9
5.1. Specifying Interval for Periodic Location and
Measurement Requests . . . . . . . . . . . . . . . . . . . 9
5.2. Accuracy of Location Information . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Barnes Expires April 30, 2009 [Page 2]
Internet-Draft Periodic Location Information Exchange October 2008
1. Introduction and Overview
The retrieval of the location of a Device is information that is
useful for a number of applications. In addition, it is useful in
some applications for a LIS to retrieve the location from a device.
The L7 Location Configuration Protocol (LCP) problem statement and
requirements document [I-D.ietf-geopriv-l7-lcp-ps] provides some
scenarios in which a Device might rely on its access network to
provide location information. The Location Information Server (LIS)
service applies to access networks employing both wired technology
(e.g. DSL, Cable) and wireless technology (e.g. WiMAX) with varying
degrees of Device mobility. This document describes the
functionality for supporting periodic location retrievals required
for wireless technologies such as WiMAX. The functionality in this
document is not specific to WiMAX and could be used by other
technologies with similar requirements.
The base HELD specification [I-D.ietf-geopriv-http-location-delivery]
allows a Device to retrieve the location, either by value or
reference, from a LIS. The context extensions
[I-D.winterbottom-geopriv-held-context] allow a device to manage its
location on a LIS, by applying constraints, such as how long a
location URI is valid, etc. Including location measurements in a
locationRequest message, as described in
[I-D.thomson-geopriv-held-measurements], allows a LIS to gather
location information from a device in cases where the device has
access to location information (e.g., via the access network or GPS),
which is the case with many wireless technologies. The capabilities
negotiation extensions to the HELD context
[I-D.thomson-geopriv-held-capabilities] allow a Device to communicate
its ability to locate itself, along with providing specific
measurement information in a response to a measurementRequest from
the LIS.
This document provides an overview of the requirements for
periodicity of requesting location information both by a Device from
an LIS and by the LIS from a Device depending upon the specific
scenario and measurement capabilities of the Device. The use of base
HELD, along with the context extensions, location measurement
extensions and the capabilities negotiations, to meet these
requirements is detailed.
2. Conventions & Terminology
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 [RFC2119].
Barnes Expires April 30, 2009 [Page 3]
Internet-Draft Periodic Location Information Exchange October 2008
This document uses the terms and references to terms defined in the
base HELD protocol specification, the context extensions, capability
negotiation extensions and measurement extensions.
3. Device to LIS Periodicity
The requirement for a Device to periodically request location
information from a LIS is required for some applications and network
environments, such as WiMAX. The request for location information is
either needed at a specific time interval or based on triggers such
as device movement. The following summarizes the requirements:
[REQ-Dev-to-LIS-1]: A Device requires the capability to request
location information from a LIS at periodic intervals.
[REQ-Dev-to-LIS-2]: A Device requires the capability to request
location information from a LIS based upon event triggers, such as
Device movement.
[REQ-Dev-to-LIS-3]: The solution to support these requirements
should consider existing IETF protocols to allow the Devices to
operate in various network types.
Using the Presence Information Data Format for Location Objects
(PIDF-LO) [RFC4119], along with the extensions to PIDF-LO
[I-D.ietf-geopriv-pdif-lo-profile], is a potential solution to meet
these requirements. However, the frequency of updates to the
presence information from the Device to the Network can negatively
impact performance. There are extensions to allow the throttling of
the event notifications [I-D.niemi-sipping-event-throttle] that could
minimize the impact. However, for some Devices and Networks,
presence is not required, thus the overhead of presence for this
functionality is not desireable.
It is possible that in the future or in the case of Devices that do
support presence, a presence based solution may well be a good
choice. Requirements to allow more continuous updates of presence
information are described in
[I-D.thomson-simple-cont-presence-val-req] may well be applicable to
supporting some of the requirements identified in this document. An
emphasis of these requirements is providing the watcher a means of
control over the measurement process Thus, it is extremely beneficial
for the proposed lightweight solution to make use of the base HELD
protocol and extensions, since the location information is in the
PIDF-LO format. Thus, this solution is compatible with presence and
can can support a broad range of scenarios and network types.
The basic functionality to support the Device sending periodic
locationRequest messages to the LIS can be accomplished with the
Barnes Expires April 30, 2009 [Page 4]
Internet-Draft Periodic Location Information Exchange October 2008
current base HELD protocol by configuring the device with the
periodicity for sending the locationRequest messages. The specifics
of the configuration mechanism are outside the scope of this
document. In addition, specific expiry times are included as part of
the data in the locationResponse messages. The Device should send
another locationRequest message on or before the expiry time.
For Devices that are made aware of location changes, the location
change can be a trigger for the device to send another
locationRequest message.
The following diagram is an example of the basic message flow for
supporting periodicity of Device requesting location information from
a LIS, which requires no changes to base HELD. In this example, the
interval for the periodicity is set to be equal to the "expires"
parameter for the locationURI returned in the locationResponse. But,
the basic message flow is independent of the source of the interval
timer value for the Device or whether the request for location
information from the LIS is triggered by an event.
Barnes Expires April 30, 2009 [Page 5]
Internet-Draft Periodic Location Information Exchange October 2008
+--------+ +-------+
| | | |
| Device | | LIS |
+--------+ +-------+
| |
+---locationRequest---->|
| |
| |
|<---locationResponse---+
| (locationURI,expires) |
| |
| |
,-----------------. |
( Set timer=expires ) |
`-----------------' |
' '
' '
' '
,-------------. |
( timer expires ) |
`-------------' |
| |
| |
+---locationRequest---->|
| |
| |
|<---locationResponse---+
| (locationURI,expires) |
' '
' '
' '
Figure 1: Device to LIS Periodic Location Request
4. LIS to Device Periodic Location Requests
In the cases where Devices have access to location information, such
as via the access network or GPS, a LIS may need to request the
location measurement information in order to support certain
applications. In some cases, the Location Recipient may have a
locationURI, thus the LIS needs up-to-date measurement information
for the Device at a specific instance in time. In this case, the LIS
cannot wait for the Device to send a periodic locationRequest message
as desribed in Section 3.
Barnes Expires April 30, 2009 [Page 6]
Internet-Draft Periodic Location Information Exchange October 2008
The periodicity of the requests by the LIS can be based on
configuration information, periodic requests from the location based
application that requires the location information, or capabilites
exchanged - i.e., based on the types of location measurement
information that may be provided, the LIS can determine a reasonable
interval at which to request the location measurement information.
[REQ-LIS-to-Dev-1]: A LIS requires the capability to determine if a
Device is capable of providing location measurement information.
[REQ-LIS-to-Dev-2]: A LIS requires the capability to request
location measurement information from a Device based upon specific
application periodicity requirements.
[REQ-LIS-to-Dev-3]: A self-locating Device should be able to
communicate to the LIS that it can provide location measurement
information to a LIS.
[REQ-LIS-to-Dev-4]: The solution to support these requirements
should consider existing IETF protocols to allow the LIS to
support Devices in a variety of access networks.
To support the LIS to Device request for location measurement
information, the Device must create a context, as described in
[I-D.winterbottom-geopriv-held-context] to communicate to the LIS the
capabilities it supports in terms of providing location
measuresments. [I-D.thomson-geopriv-held-measurements] defines a
broad range of common location-related measurement types, supporting
a variety of access networks and geographic measurement modalities.
The communication and exchange of these capabilities with the LIS via
the contextRequest message requires that the LIS and Device both
support the HELD device capabilility negotiation mechanisms as
described in [I-D.thomson-geopriv-held-capabilities].
The LIS can then either periodically or based on a trigger send a
measurementRequest message to the Device, as defined in
[I-D.thomson-geopriv-held-capabilities], to retrieve the location
measurements.
The following diagram summarizes the basic message flow for
supporting periodicity of LIS requesting location measurement info
from the Device.
+-------------+ +-------+ +---------+
| Measurement | | | | |
| Source | |Device | | LIS |
+-------------+ +-------+ +---------+
|<~~~~~measTypes~~~>| |
| +----createContext---->|
| | (capabilities) |
Barnes Expires April 30, 2009 [Page 7]
Internet-Draft Periodic Location Information Exchange October 2008
| | |
| |<---contextResponse---+
| | |
| | |
| | ,---------.
| | ( Req Meas )
| | `---------'
| | |
| |<-measurementRequest--+
|<~~measurements~~~>| |
| +-measurementResponse->|
| | |
| | ,---------.
| | ( Calc Loc )
| | `---------'
| | |
| | ,------------.
| | (Time Interval)
| | `------------'
| | |
| | ,---------.
| | ( Req Meas. )
| | `---------'
| | |
| |<-measurementRequest--+
|<~~measurements~~~>| |
| +-measurementResponse->|
| | |
' ' '
' ' '
' ' '
' ' ,------------------.
| | ! LIS may iterate !
| |<-measurementRequest! thru many Req. !
|<~~measurements~~~>| ! measurements !
| +-measurementResponse! to get sufficient!
' ' ! info for accurate!
' ' ! Location info !
' ' `------------------'
' | |
| | ,---------.
| | ( Calc Loc )
| | `---------'
| | |
' ' '
' ' '
' ' '
Barnes Expires April 30, 2009 [Page 8]
Internet-Draft Periodic Location Information Exchange October 2008
Figure 2: LIS to Device Periodic Location Measurement Request
5. Additional Considerations and Potential Enhancements
Some anticipated users of the functionality described in this
document have identified more specific requirements. This section
discusses two of the requirements that have been discussed. A
description of how these requirements are addressed by base HELD and
the extensions discussed in this document is provided.
5.1. Specifying Interval for Periodic Location and Measurement Requests
The Device to LIS periodic location requests requires no additional
functionality beyond that provided by base HELD and the extensions as
described in Section 3. However, the approach has the limitation
that the periodicity is controlled by the Device through
configuration or event triggers, such as Device movement. The
periodicity is also inherently controlled by LIS with the "expires"
parameter associated with a locationURI. This provides the basic
functionality, however, does not provide flexibility in terms of the
LIS specifying the interval at which it would prefer the location
requests be sent.
Sending the Device capabilities when a context is established or
updated allows the Device to communicate some of the characteristics
of the functionality supported by the Device. The LIS responds with
the set of capabilities that it can use in the contextResponse
message. The intent of this capability negotiation is to provide the
LIS with information so that it can request measurements from the
Device.
An additional requirement for the Device to be able to specify a
desired expiry time has also been suggested. To support this
functionality, it may be possible to extend the capabilites by adding
a URI that indicates the capability of the Device to support periodic
requests for location from the LIS. This would allow the LIS to
decide whether it has the capacity to support these requests or
whether it prefers to be in control and thus limit the periodicity of
the Device requesting location based on the "expires" parameter
associated with a specific locationURI, in the case that it does not
support this capability. In most cases, it is anticipated that since
the LIS does have information as to the capabilities of a Device, it
is more sensible to operate in this latter fashion. However, due to
the ability for a Device to update a context, it is possible that a
Device may attempt to negotiate this capability after a certain
period of time [TBD]. In order to control whether a Device would
attempt to re-negotiate this capability an additional capability URI
Barnes Expires April 30, 2009 [Page 9]
Internet-Draft Periodic Location Information Exchange October 2008
could be defined. This might be useful, for example, when a LIS may
be temporarily unable to support location requests at a higher
frequency. However, going beyond defining these URIs, additional
functionality to support negotiating the rate at which the Device can
send requests for location information isn't desireable. The
functionality would increase the dependency between the LIS and
Device and the overhead for this functionality could be more than
leaving the rate of the Device sending location requests to the LIS
under control of the Device.
That all said, since the capability negotiation mechanism is intended
to provide sufficient information as to the types of measurements a
LIS may request from the Device, with the LIS controlling the
periodicity of the requests, it does not seem necessarily to add the
additional URI for negotiating support of periodicity - i.e., support
is inherent in the establishment of the context and the LIS has the
knowledge as to the rate at which the location measurement
information is required.
That all said, since the capability negotiation mechanism is intended
to provide sufficient information as to the types of measurements a
LIS may request from the Device, with the LIS controlling the
periodicity of the requests, it does not seem necessarily to add the
additional URI for negotiating support of periodicity - i.e., support
is inherent in the establishment of the context and the LIS has the
knowledge as to the rate at which the location measurement
information is required.
5.2. Accuracy of Location Information
The specification of the accuracy of location information has been
discussed as a potential requirement in relation to the source of the
location measurement information that is used by the LIS to determine
location (e.g., GPS). [I-D.thomson-geopriv-uncertainty] defines a
general representation of Uncertainty and Confidence with respect to
the location information in the PIDF-LO. This methodology should be
able to account for potential inaccuracies in location measurement
information provided by the Device to the LIS, which the LIS uses as
input for location determination, particularly since the context
negotiation allows the LIS to communicate to the Device the types of
location measurements that it supports or will be using for the
specific context.
6. Security Considerations
This document makes use of the base HELD protocol and extensions,
along with the security mechanisms specified for the protocol and
Barnes Expires April 30, 2009 [Page 10]
Internet-Draft Periodic Location Information Exchange October 2008
extensions, thus no new security considerations are introduced.
7. IANA Considerations
This document does not require any IANA registrations. However, if
it is decided to define additional capability URNs as discussed in
Section 4, the appropriate registrations will be added to this
section.
8. Contributors
This document is a result of input from and discussion amongst(in
alphabetical order): Jayshree Bharatia, Devaki Chandramouli, Mike
Hammer, Jay Iyer, James Polk, Muthaiah Venkatachalam and James
Winterbottom. Some details are derived from slide presentations from
Devaki Chandramouli, Muthaiah Venkatachalam, and James Winterbottom.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-09 (work in
progress), September 2008.
[I-D.winterbottom-geopriv-held-context]
Winterbottom, J., Tschofenig, H., and M. Thomson, "HELD
Protocol Context Management Extensions",
draft-winterbottom-geopriv-held-context-03 (work in
progress), September 2008.
[I-D.thomson-geopriv-held-measurements]
Thomson, M. and J. Winterbottom, "Using Device-provided
Location-Related Measurements in HELD",
draft-thomson-geopriv-held-measurements-02 (work in
progress), May 2008.
[I-D.thomson-geopriv-held-capabilities]
Thomson, M. and J. Winterbottom, "Device Capability
Negotiation for Device-Based Location Determination and
Barnes Expires April 30, 2009 [Page 11]
Internet-Draft Periodic Location Information Exchange October 2008
Location Measurements in HELD",
draft-thomson-geopriv-held-capabilities-04 (work in
progress), July 2008.
9.2. Informative References
[I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
progress), June 2008.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-13
(work in progress), September 2008.
[I-D.niemi-sipping-event-throttle]
Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
Protocol (SIP) Event Notification Extension for
Notification Throttling",
draft-niemi-sipping-event-throttle-07 (work in progress),
October 2008.
[I-D.thomson-geopriv-uncertainty]
Thomson, M. and J. Winterbottom, "Representation of
Uncertainty and Confidence in PIDF-LO",
draft-thomson-geopriv-uncertainty-01 (work in progress),
June 2008.
[I-D.thomson-simple-cont-presence-val-req]
Thomson, M., "Requirements for the Support of Continuously
Varying Values in Presence",
draft-thomson-simple-cont-presence-val-req-00 (work in
progress), October 2008.
Barnes Expires April 30, 2009 [Page 12]
Internet-Draft Periodic Location Information Exchange October 2008
Author's Address
Mary Barnes (editor)
Nortel
2201 Lakeside Blvd
Richardson, TX
Email: mary.barnes@nortel.com
Barnes Expires April 30, 2009 [Page 13]
Internet-Draft Periodic Location Information Exchange October 2008
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.
Barnes Expires April 30, 2009 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 06:15:19 |