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]