One document matched: draft-barnes-ecrit-rough-loc-00.txt
Internet Engineering Task Force R. Barnes
Internet-Draft M. Lepinski
Intended status: Experimental BBN Technologies
Expires: August 21, 2008 February 18, 2008
Using Imprecise Location for Emergency Context Resolution
draft-barnes-ecrit-rough-loc-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 August 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Emergency calling works best when precise location is available for
emergency call routing. However, there are situations in which a
location provider is unable or unwilling to provide precise location,
yet still wishes to enable subscribers to make emergency calls. This
document describes the level of location accuracy that providers must
provide to enable emergency call routing. In addition, we descibe
how emergency services and non-emergency services can be invoked by
an endpoint that does not have access to its precise location.
Barnes & Lepinski Expires August 21, 2008 [Page 1]
Internet-Draft ECRIT with Rough Location February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Determining sufficient location precision . . . . . . . . . . 4
3.1. Location filtering . . . . . . . . . . . . . . . . . . . . 5
3.2. Constructing and maintaining filters . . . . . . . . . . . 6
4. Requesting location-based services . . . . . . . . . . . . . . 7
4.1. Emergency calling . . . . . . . . . . . . . . . . . . . . 7
4.2. Non-emergency services . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Barnes & Lepinski Expires August 21, 2008 [Page 2]
Internet-Draft ECRIT with Rough Location February 2008
1. Introduction
Information about the location of an emergency caller is a critical
input to the process of emergency call establshment, in that endpoint
location is used to determine which Public Safety Answering Point
(PSAP) should be the destination of the call. (The entire emergency
calling process is described in detail in
[I.D-ietf-ecrit-framework][I.D-ietf-ecrit-phonebcp].) This process
is most likely to work properly when the endpoint is provided with
the most accurate precise information available about its location.
Using location information with maximal precision and accuracy
minimizes the chance that a call will be mis-routed. And when that
location is provided to the endpoint, the endpoint is able to verify
that the location is correct (to the extent of the endpoint's
knowledge of its own location) prior to an emergency call, and is
able to perform emergency call routing functions on its own,
providing redundancy for network-provided functions.
However, there may be situations in which it is not feasible for
endpoints to be provided with maximally precise and accurate
location. These cases may arise when computing precise location is
an expensive or time-consuming operation (e.g., in the case of
wireless triangulation), and location is needed quickly (as is often
the case in emergency situations). Or they may arise because the
policy of the location provider does not allow precise location to be
provided to the endpoint (e.g. due to privacy considerations). While
it is undesirable to use imprecise location for emergency call
routing, the possibility that precise location may not be available
to the calling device must be accomodated in order to make emergency
calling possible in the largest possible set of circumstances.
This document is concerned imprecise location only in the context of
routing emergency calls, i.e., for determining the correct PSAP to
receive a given call (e.g., via a LoST query [I.D-ietf-ecrit-lost]).
Location information may also be used in the emergency calling
framework to direct the dispatch of emergency responders. This usage
is treated separately from call routing for purposes of this
document, and this document does not place requirements on the
location provided for dispatch (although it should obviously be as
precise as possible). The only provision for dispatch in this
document is a recommendation that the location provider supply
endpoints with a URI that can be used by a PSAP or other emergency
authority to obtain a different location for use in dispatch,
hopefully more precise than the one used for routing.
This document describes the use of imprecise location information in
the emergency call routing system. Section 3 describes how location
providers can determine the precision necessary to support emergency
Barnes & Lepinski Expires August 21, 2008 [Page 3]
Internet-Draft ECRIT with Rough Location February 2008
call routing. Section 4 describes how emergency calls are placed in
such an environment, and how non-emergency service can be invoked
when precise location is not available to the endpoint by value.]
2. 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].
We consider in this document patterns of interaction as described in
[I.D-ietf-ecrit-framework]. The two main parties of interest are
endpoints and location providers. Endpoints are hosts connected to
the Internet that originate emergency calls in the emergency calling
architecture, while location providers are entities that supply
location information that is used for emergency calling. In
addition, we will discuss how these parties interact with the LoST
mapping infrastructure [I.D-ietf-ecrit-mapping-arch], and with
emergency and non-emergency location-based service providers.
3. Determining sufficient location precision
A location provider wishing to provide location information usable
for emergency call routing requires a mechanism for determining when
a description of location (e.g., a polygon) is precise enough to be
used for emergency call routing. This mechanism might be used to
decide when to terminate a positioning mechanism that converges over
time, or to choose a polygon larger than the known location of the
endpoint (in order to obscure the known location of the endpoint),
while preserving the utility of the location for emergency call
routing in either case.
There are two base requirements for a location to be usable for
emergency services:
1. The location SHOULD be sufficiently precise that a LoST request
with the location and any service URN will return a single URI
mapping value. This may not be possible in all cases, e.g.,
because of overlapping service boundaries (leading to areas that
do not have a unique mapping) or positioning limitations (leading
to insufficient precision).
2. When the location of the endpoint is known by the provider to
greater precision than is being provided, the provided location
MUST return the same mappings from LoST (for all service URNs) as
the known location.
Barnes & Lepinski Expires August 21, 2008 [Page 4]
Internet-Draft ECRIT with Rough Location February 2008
In this section, we describe how to use a "location filter" to
determine whether a given location is usable for emergency call
routing, and how to construct and maintain such a filter.
3.1. Location filtering
With each service-to-URI mapping, a LoST query provides a service
boundary that represents the set of locations in which that mapping
is valid. A consequence of this is that given a set of service
boundaries for difference services (say, one mapping
"urn:service:sos.fire" to "sip:fire@example.com" and one mapping
"urn:service:sos.police" to "sip:police@example.com"), the
intersection of those service boundaries is the region in which two
mappings are valid ("urn:service:sos.fire" maps to
"sip:fire@example.com" and "urn:service:sos.police" maps to
"sip:police@example.com"). Outside that area, one or more of the
mappings is invalid. Said differently, any region contained in an
intersection uniquely determines mappings for the services used in
the intersection, and any two locations within the same intersection
are equivalent for the purpose of LoST mapping (i.e., emergency call
routing).
A location filter is thus a set of regions (optionally, each region
may be assigned a list of (service URN, service URI) pairs). Each
region is the intersection of the service boundaries for all services
available within the region, and the lists represent the mappings
that are valid within that region. A filter is used to determine
whether a location is useable for emergency call routing in the
following way:
1. The location SHOULD be contained in exactly one of the regions in
the filter. This guarantees that LoST mappings are unique.
2. When the location of the endpoint is known, the provided location
MUST be contained in the same region(s) of the filter as the
known location. This guarantees that LoST queries with the
provided location return the same results as those done with the
known location
When the regions are bound to lists of URN-URI mappings, the
resulting filter can also be used as a cache for LoST mappings; the
LoST mappings for a location are the URN-URI pairs bound to the
region(s) containing it.
When the location of the endpoint is known to more precision than the
location provided to the endpoint, although any location meeting the
two criteria above is equivalent to the known location for purposes
of LoST, the provided location MUST contain the known location in
Barnes & Lepinski Expires August 21, 2008 [Page 5]
Internet-Draft ECRIT with Rough Location February 2008
order to avoid errors if the location is used for other purposes in
the course of an emergency (e.g., if the location is provided to
first responders for dispatch). This guarantee also allows the
endpoint to do some course verification that it is within the
provided location (in order to prevent very gross errors in routing).
Nonetheless, any location that (1) contains the known location and
(2) is contained in the same filter region as the known location is
allowable. Adding randomness to the provided locations may have
privacy benefits in some cases, as discussed in the security
considerations below.
3.2. Constructing and maintaining filters
For simplicity, we assume that the entity performing filtering will
only be using the filter to test locations contained within a
particular geographic "coverage area". Given a coverage area, server
operated by a location service provider can autonomously compute a
location filter using the following algorithm:
First, the server must obtain mappings for all services and for all
points within the coverage area. When the server uses a LoST server
that is configured to return all mappings for the indicated location,
mapping information for the coverage area can be obtained using a
LoST findService query of the following form:
<?xml version="1.0" encoding="UTF-8"?> <findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml" serviceBoundary="value">
<location id="6020688f1ce1896d" profile="geodetic-2d"> <!-- Coverage
Area --> </location> </findService>
When LoST is not configured to return all possible matches (or when
the above query would return more results than the LoST server is
willing to transmit), the server must obtain mapping information for
each service independently by sampling at points within the coverage
area. It must continue sampling until for each service, the union of
the service boundaries covers the coverage area. If the server is
unable to obtain a set of service areas that covers the coverage area
for a particular service, it MUST verify that the service is
unavailable in the uncovered area by performing LoST
listServicesByLocation queries within the uncovered area and
verifying that the service is not in the returned list of available
services. Note that this procedure for obtaining mappings is much
less reliable than allowing LoST to do the decomposition into service
boundaries, since a LoST client cannot establish definitively that a
service is not available throughout an un-covered area (it may be
available at some un-sampled point).
Barnes & Lepinski Expires August 21, 2008 [Page 6]
Internet-Draft ECRIT with Rough Location February 2008
The regions in the location filter are computed by means of URI
tuples: For each service URN, let uris(urn) be the set of PSAP URIs
for that service URN (collected from the mappings). The set of URI
tuples is then the cartesian product of these sets; if the set of
servuce URNs is {urn1,...,urnN}, then the set of URI-tuples is
uris(urn1) x ... x uris(urnN). The server computes the regions in
the filter by iterating through the set of URI tuples, either by
constructing the set of URI tuples and directly iterating, or by
using nested iteration through all the sets uris(urn).
For each URI tuple, the server compute the intersection of the
service boundaries for the URIs in the tuple. This becomes an entry
in the location filter: The stored region is the intersection of the
service boundaries, and the corresponding mapping table is the list
of (URN, URI) pairs, where the URIs are the URIs from the tuple and
the URNs are the services used to obtain them from LoST.
As the LoST mappings that underlie the filter change, the filter will
need to be updated. The entity maintaining the filter MUST obtain a
new mapping for a region when an existing mapping expires. The
service boundary from the new mapping is compared to the service
boundary from the old mapping: If they are the same, then the filter
need not be updated. If they differ, then regions in the filter that
are contained in either the old service boundary or the new service
boundary will need to be recomputed. Note that since this operation
only requires the server to determine if two service boundaries are
identical, the server need only store a hash of the old boundary (to
which it can compare a hash of the new boundary).
4. Requesting location-based services
When a location provider deliver endpoints location information that
is below its maximum feasible precision while still supporting
emergency calling, it MUST provide to the endpoint both a location
(by value) that is sufficient for emergency call routing (see above)
and a location reference (i.e., a URI) that can subsequently be used
by authorized parties to obtain more precise information about the
location of the endpoint. The endpoint then can then use both the
location value and the location reference to request location-based
services (LBS) as described below.
4.1. Emergency calling
The procedure for placing an emergency call is indentical to that
described in [I.D-ietf-ecrit-framework]. In particular, the endpoint
requirements in Sections 8 and 9 of [I.D-ietf-ecrit-phonebcp] still
apply to an endpoint that receives imprise location.
Barnes & Lepinski Expires August 21, 2008 [Page 7]
Internet-Draft ECRIT with Rough Location February 2008
In addition, it should be emphasized that an endpoint that receives
location both by value and by reference from its location provider
MUST include both the location value and the location reference in
the SIP INVITE message that initiates an emergency call, as specified
in [I.D-ietf-sip-location-conveyance]. When the endpoint supports
LoST, it SHOULD use the location value to obtain a PSAP URI for LoST
queries (as opposed to attempting to dereference the location
reference) (thus, it would also add the "used-for-routing" parameter
to the geolocation header that points to the location value as
inserted into the INVITE message). Note that this process crucially
relies on the location value having sufficient precision for routing
emergency calls (see Section 3 for techniques to ensure the location
value is suitable for emergency call routing).
When a PSAP receives a SIP INVITE that contains both a location value
and a location reference, if the value is too imprecise for use in
dispatch then the PSAP SHOULD dereference the LbyR to obtain more
precise information. In turn the location provided by the location
provider MUST allow access by all PSAPs whose service boundaries
overlap with the region served by the location provider. This means
that either the provider must supply a reference that can be
dereferenced by any party, or else the provider must establish
explicit authentication and authorization relationships with all PSAP
in its service area.
4.2. Non-emergency services
Non-emergency LBSs will generally require more precise information
than is required for emergency call routing. Therefore, when
requesting a non-emergency LBS, the endpoint SHOULD include the
location reference provided by its location provider, and MAY
additionally provide the location value. If the provided location
value is not sufficient precise to deliver the requested service,
then the LBS provider should then dereference the location value to
request location information of sufficient precision from the
location provider. If the dereference fails, then the request for
service may fail as well.
Note that when the location reference provided by the location
provider is access-controled, this dereference may require a pre-
existing authentication and authorization agreement between the LBS
provider and the location provider. In such a case, the endpoint may
not know whether a given non-emergency service is authorized to
obtain the endpoint's precise location using the location reference.
The endpoint is always capable of requesting services without knowing
whether they are authorized; in this way, the endpoint can discover
authorized services by trial and error. In order to simplify this
process, a location provider may supply the endpoint with references
Barnes & Lepinski Expires August 21, 2008 [Page 8]
Internet-Draft ECRIT with Rough Location February 2008
to authorized service providers, although there is currently no
standard protocol for this transaction.
5. Acknowledgements
This document generalizes the concept of "rough location" that was
originally discussed in the context of the location hiding problem.
This concept was put forward by Henning Schulzrinne and Andy Newton,
among many others, in a long-running ECRIT discussion.
6. Security Considerations
One reason for an LIS to provide location information below its
maximum precision is to protect the privacy of the target. Some
location provisioning protocols do not enable the location provider
to obtain strong assurance of the identity of the location recipient;
in particular, the location provider may be unable to verify that the
recipient is the target of the location being provided. Therefore,
there is a risk that a sufisticated attacker might be able to spoof
the identifier (e.g. IP address) used by the location provider to
identify the target, and obtain the target's location in this way.
One way to mitigate this risk is to provide only imprecise location
information to the end-point (without authentication), and to provide
precise information only to trusted entities that can authenticate
themselves to the location provider. Additionally, in some
deployment scenarios, location providers have concerns about the
comprimise of endpoint devices. Providing only imprecise location to
the endpoint, prevents malware on a comprised device from obtaining
the precise location of the target.
As described in Section 3.1 above, the location provider choosing to
provide a less precise location than a known location has a
significant amount of choice in deciding which location to provide:
Any location that contains the known location and is in the same
filter region will do. When the provider is reducing precision for
privacy purposes, there is a signficant benefit to choosing a random
location meeting these criteria. If a watcher is interested in
whether or not the endpoint is moving, an imprecise location may
still reveal that fact if it is constant when the endpoint is at
rest. If the provided location is randomized each time it is
provided, then the watcher is unable to obtain even this level of
information.
Barnes & Lepinski Expires August 21, 2008 [Page 9]
Internet-Draft ECRIT with Rough Location February 2008
7. IANA Considerations
This document makes no request of IANA.
8. References
8.1. Normative References
[I.D-ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet
Multimedia", September 2007.
[I.D-ietf-ecrit-lost]
Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", September 2007.
[I.D-ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
September 2007.
[I.D-ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", July 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
8.2. Informative References
[I.D-ietf-ecrit-mapping-arch]
Schulzrinne, H., "Location-to-URI Mapping Architecture and
Framework", September 2007.
Barnes & Lepinski Expires August 21, 2008 [Page 10]
Internet-Draft ECRIT with Rough Location February 2008
Authors' Addresses
Richard Barnes
BBN Technologies
9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046
USA
Phone: +1 410 290 6169
Email: rbarnes@bbn.com
Matt Lepinski
BBN Technologies
10 Moulton St
Cambridge, MA 02138
USA
Phone: +1 617 873 5939
Email: mlepinski@bbn.com
Barnes & Lepinski Expires August 21, 2008 [Page 11]
Internet-Draft ECRIT with Rough Location February 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Barnes & Lepinski Expires August 21, 2008 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 04:18:22 |