One document matched: draft-busin-geopriv-location-qos-req-01.txt
Differences from draft-busin-geopriv-location-qos-req-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 19:15:24 |