Geopriv Working Group A. Busin Internet-Draft Y. Jin Intended status: Standards Track M. Mosmondor Expires: May 22, 2008 S. Loreto Ericsson Nov 19, 2007 Requirements for a Location Quality of Service (QoS) Information Object draft-busin-geopriv-location-qos-req-01 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 May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes requirements for Location Quality of Service (QoS) Information that may be carried both in the Geopriv Layer 7 Location Configuration Protocol (L7 LPC) and in the Location Dereference Protocol (LDP) requests. The Location QoS Information is used for expressing the required or desired level of quality, accuracy, response time, and age of requested Location Information. Busin, et al. Expires May 22, 2008 [Page 1] Internet-Draft Requirements for QoS Location Filtering Nov 2007 The resulting Location Information is conveyed in existing location formats wrapped in GEOPRIV privacy extensions to the Presence Information Document Format (PIDF-LO) [RFC4119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Location QoS Information benefits . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Location QoS Information . . . . . . . . . . . . . . . . . . . 4 4.1. Horizontal accuracy . . . . . . . . . . . . . . . . . . . 5 4.2. Vertical accuracy . . . . . . . . . . . . . . . . . . . . 5 4.3. Age of the Location Information . . . . . . . . . . . . . 6 4.4. Response Time . . . . . . . . . . . . . . . . . . . . . . 6 4.5. QoS class . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Location QoS Information Object Requirements . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Busin, et al. Expires May 22, 2008 [Page 2] Internet-Draft Requirements for QoS Location Filtering Nov 2007 1. Introduction GEOPRIV working group is standardizing the transmission of the Location Information through a direct, or indirect mechanisms. o A Geopriv Layer 7 Location Configuration Protocol (L7 LPC) is used by a device or middlebox to acquire a location information which already exist from a server within an access network. The requirements for a Location Configuration Protocol are listed in [I-D.ietf-geopriv-l7-lcp-ps]. o A Location Dereference Protocol (LPD) is used by a client to query a location dereference server (e.g. LIS), based on location URI input and which returns location information (e.g., a PIDF-LO). The requirements for a Location Dereference Protocol (LDP) are listed in [I-D.ietf-geopriv-lbyr-requirements]. Location QoS is described with a set of location QoS parameters (i.e., positioning accuracy, location response time, etc.) and corresponding values. Different services and applications that use Location Information may require different location QoS. For example, the positioning accuracy may be an important parameter for some services/ applications. The minimum acceptable positioning accuracy for various services/applications may vary from meters (e.g., in navigation) to kilometers (e.g., in local weather reports). In such a context it should be possible to specify required location QoS in terms of defining an acceptable set of parameters and their values to provide a valid response to the location request. A valid location response is considered as a response that fulfills the location QoS requirements specified in the location request. Both the [I-D.ietf-geopriv-l7-lcp-ps] and the [I-D.ietf-geopriv-lbyr-requirements] do not identify requirements for Location QoS. This document defines requirements for a Location QoS Information needed for expressing the required level of location QoS. This is achieved by defining a required set of location QoS parameters that are of relevance to the recipient of Location Information (Location Recipient). 1.1. Location QoS Information benefits The purpose of Location QoS Information is "for expressing the required level of Location QoS". This has two main benefits: Busin, et al. Expires May 22, 2008 [Page 3] Internet-Draft Requirements for QoS Location Filtering Nov 2007 1. The recipient will not receive (and pay for) Location Information that it is useless to him. For example, the parent seeking his children; if parent is unable to specify what accuracy it needs, it may receive Location Information that states "child is in somewhere in the circle area of 200 km in radius". This information is clearly quite useless for the parent. Nevertheless, the recipient (parent) will probably have to pay for this information. 2. It allows Location Server to decide which source (or technique) for location/position determination to use. For example, should it use more accurate positioning that will take long time to respond, or lower (but satisfying) accuracy with quicker response? 2. Requirements Terminology The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology This document reuses the terminology of [RFC3693] such as Location Information (LS), Target, Location Server (LS), and Location Recipient (LR). 3.1. Terms Location QoS : the required or desired level of quality, accuracy, response time, and age of requested Location Information. Location QoS Information : A parameter conveying required or desired location QoS information. 4. Location QoS Information This section of the document describes location QoS information that is used to express a required or desired level of location service quality, in terms of minimum horizontal and vertical accuracy, maximum response time, and maximum age of requested Location Information. This document defines the following as the list of location QoS parameters: Busin, et al. Expires May 22, 2008 [Page 4] Internet-Draft Requirements for QoS Location Filtering Nov 2007 o horizontal accuracy o vertical accuracy o age o response time o QoS class 4.1. Horizontal accuracy Usually the position of a Target is expressed as a point (either in two or three dimensions) and an area or volume of positioning uncertainty around that point. The size of positioning uncertainty area/volume can be used as a measure of positioning accuracy. If the uncertainty area/volume is smaller, the positioning accuracy is higher. The horizontal accuracy of Location Information is described with maximum horizontal size of a positioning uncertainty area/volume. The horizontal accuracy parameter specifies maximum acceptable horizontal size of a positioning uncertainty area/volume. If this parameter is not present, the Location Server may include Location Information with any horizontal accuracy as long as requirements defined with other QoS parameters are fulfilled. The Location Server shall normally attempt to satisfy or approach as closely as possible the requested horizontal accuracy when other location QoS parameters are not in conflict. The achieved accuracy level of Location Information shall be indicated using the shapes and uncertainty areas as described in [I-D.ietf-geopriv-pdif-lo-profile]. 4.2. Vertical accuracy The vertical accuracy of Location Information is described with maximum vertical size of a positioning uncertainty area/volume. The vertical accuracy parameter specifies maximum acceptable vertical size of a positioning uncertainty area/volume. If this parameter is not present, the Location Server may include Location Information with any vertical accuracy as long as requirements defined with other QoS parameters are fulfilled. The Location Server shall normally attempt to satisfy or approach as closely as possible the requested vertical accuracy when other location QoS parameters are not in conflict. Busin, et al. Expires May 22, 2008 [Page 5] Internet-Draft Requirements for QoS Location Filtering Nov 2007 4.3. Age of the Location Information The age parameter states the maximum allowable age of the Location Information that is being sent in a response to a Location Recipient. This Location Information may have been cached in the system from a previous location query. If this parameter is not present, the Location Server may include Location Information of any age as long as requirements defined with other QoS parameters are fulfilled. The Location Server shall normally attempt to satisfy or approach as closely as possible the requested age when other location QoS parameters are not in conflict. 4.4. Response Time Response time is defined as the time needed for the Location Server to send a response with the Location Information after having received a location request. Different Location Recipients may have different requirements for the response time. In some cases the response time may depend on the positioning accuracy and on age of the Location Information. This relation may be dependent on the positioning technique that is used to determine a Target's position. The Location Server may need to make trade-offs between these three parameters. The response time parameter defines maximum allowable time needed for the Location Server to send a response with the Location Information after having received a location request. If this parameter is not present, the Location Server may respond with Location Information at any time as long as requirements defined with other QoS parameters are fulfilled. The Location Server shall normally attempt to satisfy or approach as closely as possible the requested response time when other location QoS parameters are not in conflict. 4.5. QoS class The QoS class defines the degree of adherence of the location service to given QoS parameters: horizontal and vertical accuracy, response time, and age of Location Information. There are two location QoS classes defined: "Assured" and "Best effort" [3GPP.22.071]. Busin, et al. Expires May 22, 2008 [Page 6] Internet-Draft Requirements for QoS Location Filtering Nov 2007 The "Assured" location QoS class presumes strict adherence to given QoS parameters. The Location Server must obtain Location Information while fulfilling the requirements set by the other QoS parameters (horizontal and vertical accuracy, age, and response time). If the location response does not satisfy QoS parameters, the response will be discarded by the Location Server. The "Best effort" location QoS class presumes that QoS parameters are not adhered to strictly. The Location Server shall obtain Location Information while fulfilling the requirements set by the other QoS parameters, but it will not discard the response if other QoS parameters are not satisfied. The "Best effort" class is considered as the default QoS class in the case that there is no location QoS class parameter definition provided in the request. 5. Location QoS Information Object Requirements The Location Recipient may request that the Location Server provides it with the GEOPRIV location information concerning a particular Target [RFC3693]. In a location request, the Location Recipient MAY optionally include one or more Location QoS Information parameters that defines required location QoS. The using protocol for the exchange of Location QoS Information is out of the scope of this document. Req. 1.(Location QoS Information generalities): 1.1) Geopriv MUST specify Location QoS Information, both in syntax and semantics, that SHOULD be insert in the LCP and LDP request; the Location QoS information MUST be supported and understood by the Location Recipient and the Location Server. 1.2) The Location QoS Information MAY be optional. This means that a Location QoS Information MAY not be present in a LCP or DLP request. 1.3) Some of the Location QoS Information MAY be defined as "extensions". This means that the syntax or semantics of these QoS Information is not fully defined in the basic Location QoS Information definition, but their use may be limited to one or more of the using protocols. 1.4) The Location QoS Information MUST be extensible, allowing the definition of new parameters or attributes. Busin, et al. Expires May 22, 2008 [Page 7] Internet-Draft Requirements for QoS Location Filtering Nov 2007 1.5) The Location QoS Information SHOULD be usable in a variety of protocols, such as HTTP and SIP. Req. 2.(Location QoS Information Object fields) The Location QoS Information Object definition MUST contain the following fields, which MAY be optional to use: 2.1) horizontal accuracy parameter 2.2) vertical accuracy parameter 2.3) age parameter 2.4) response time parameter 2.5) QoS class parameter 6. Security Considerations Privacy and security considerations related to Location Information are discussed in detail in [RFC3693]. 7. IANA Considerations This document does not require actions by the IANA. 8. Acknowledgments 9. Normative References [3GPP.22.071] 3GPP, "Location Services (LCS); Service description; Stage 1", 3GPP TS 22.071 3.5.0, March 2004. [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-05 (work in progress), September 2007. [I-D.ietf-geopriv-lbyr-requirements] Marshall, R., "Requirements for a Location-by-Reference Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work in progress), October 2007. [I-D.ietf-geopriv-pdif-lo-profile] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV PIDF-LO Usage Clarification, Considerations and Busin, et al. Expires May 22, 2008 [Page 8] Internet-Draft Requirements for QoS Location Filtering Nov 2007 Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work in progress), October 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. Authors' Addresses Aeke Busin Ericsson Stockholm Sweeden Email: ake.busin@ericsson.com Yufeng Jin Ericsson Shanghai China Email: yufeng.jin@ericsson.com Miran Mosmondor Ericsson Krapinska 45 Zagreb 10000 Croatia Email: miran.mosmondor@ericsson.com Busin, et al. Expires May 22, 2008 [Page 9] Internet-Draft Requirements for QoS Location Filtering Nov 2007 Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Salvatore.Loreto@ericsson.com Busin, et al. Expires May 22, 2008 [Page 10] Internet-Draft Requirements for QoS Location Filtering Nov 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Busin, et al. Expires May 22, 2008 [Page 11]