One document matched: draft-ietf-ecrit-rough-loc-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5222 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml">
<!ENTITY RFC4119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY phonebcp PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-phonebcp.xml">
<!ENTITY uncertainty PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-uncertainty.xml">
<!ENTITY policyuri PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.barnes-geopriv-policy-uri.xml">
<!ENTITY civicbound PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-ecrit-civic-boundary.xml">
<!ENTITY RFC6442 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6442.xml">
<!ENTITY RFC6443 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6443.xml">
<!ENTITY RFC6444 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6444.xml">
<!ENTITY RFC5582 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5582.xml">
<!ENTITY RFC5687 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5687.xml">
<!ENTITY RFC5808 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5808.xml">
<!ENTITY policy PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-policy.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-ecrit-rough-loc-05.txt"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="ECRIT with Rough Location">Using Imprecise Location for
Emergency Context Resolution</title>
<!--add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Richard Barnes" initials="R." surname="Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>9861 Broken Land Pkwy, Suite 400</street>
<!-- Reorder these if your country does things differently -->
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>USA</country>
</postal>
<phone>+1 410 290 6169</phone>
<email>rbarnes@bbn.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Matt Lepinski" initials="M." surname="Lepinski">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>10 Moulton St</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>USA</country>
</postal>
<phone>+1 617 873 5939</phone>
<email>mlepinski@bbn.com</email>
</address>
</author>
<date month="July" year="2012"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<abstract>
<t>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 describe
additional rules for networks and endpoints to enable emergency calling
by endpoints that do not have access to precise location.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Information about the location of an emergency caller is a critical
input to the process of emergency call establshment. 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 <xref target="RFC6443"/> and <xref
target="I-D.ietf-ecrit-phonebcp"/>.) This process is most likely to work
properly when the endpoint is provided with the most accurate and
precise information available about its location. Using location
information with maximal precision and accuracy minimizes the chance
that a call will be mis-routed.</t>
<t>When 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. Moreover, when endpoints have
access to location information, they can look up PSAP contact
information themselves, reducing dependence on other call-routing
elements in the network, and increasing the overall resilience of the
system.</t>
<t>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 a location provider
does not allow precise location to be provided to the endpoint. 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.</t>
<t>To put it another way, a need for emergency calling with imprecise
location can arise in two ways. Either the location of the endpoint is
not known to the location provider with a high degree of precision, or
the endpoint's precise location is known and the location provider
chooses to provide location with lower precision. In the former case,
the techniques described in this document can be used to determine
whether a given positioning mechanism provides sufficient precision to
support emergency calling. In the latter case, such techniques can be
used to determine how much a location value can be "fuzzed" before it
becomes unusable for emergency services.</t>
<t>This document is concerned with 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 <xref
target="RFC5222"/>). Depending on the the structure of the local
emergency service network, the location information provided to the
endpoint may also be used to route the call to an entity that is
authorized to request precise location, e.g., an Emergency Services
Routing Proxy. The requirements and processes described in this document
are the same for both cases. Detailed requirements are discussed in
<xref target="RFC6444"/></t>
<t>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.</t>
<t>This document describes the use of imprecise location information in
the emergency call routing system. <xref target="det-section"/>
describes how location providers can determine the precision necessary
to support emergency call routing, and how they can use this information
to optimize location delivery. <xref target="lbs-section"/> describes
how emergency calls are placed in such an environment, and how
non-emergency services can be invoked when precise location is not
available to the endpoint by value.</t>
</section>
<section anchor="term-section" title="Terminology">
<t>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 <xref
target="RFC2119"/>.</t>
<t>We consider in this document patterns of interaction as described in
<xref target="RFC6443"/>. 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 <xref
target="RFC5582"/>, and with emergency and non-emergency location-based
service providers.</t>
<t>For convenience, we say that location information, either in LoST
queries or in service boundaries, is provided "in geodetic form" if it
is provided in the "geodetic-2d" LoST location profile, and "in civic
form" if it is provided in the "civic" profile.</t>
<t>The term "precision" is not used in a quantitative sense in this
document. In general, the "precision" of a location value is determined
by the size of its uncertainty region. <xref
target="I-D.thomson-geopriv-uncertainty"/> Higher precision values have
small uncertainty regions and lower precision values have larger
uncertainty regions. The notion of "sufficient precision for emergency
services is defined in <xref target="det-section"/></t>
</section>
<section anchor="det-section" title="Location Precision Requirements">
<t>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 process 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.</t>
<t>There are three basic requirements for a location to be usable for
emergency call routing: <list style="numbers">
<t>The location SHOULD be sufficiently precise that a LoST request
with the location and any emergency service URN will return a unique
URI mapping value. This may not be possible in all cases, e.g.,
because of overlapping service boundaries creating areas with
non-unique mappings, or because of positioning limitations that
prevent sufficiently precise positioning.</t>
<t>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 emergency service URNs,
as the known location.</t>
<t>When the location of the endpoint is known by the provider to
greater precision than is being provided, the provided location MUST
contain the precise location (as a geographic subset).</t>
</list></t>
</section>
<section anchor="filter-use-section" title="Location Filtering">
<!-- Division of space into filter regions -->
<t>In effect, the first of these rules divide the world into regions
where each point is served by the same set of emergency services (i.e.,
the LoST mappings are the same). We call this division of space a
"location filter" and the consituent regions of uniformity "filter
regions". The second rule says that the rough location must be in the
same filter region as the precise location. (The third rule is unrelated
to filtering.)</t>
<t>A location filter is a collection of geographical regions satisfying
the following criteria: <list style="numbers">
<t>For any location value that is a subset of a filter region, a
LoST request for any service will return a unique mapping
result.</t>
<t>Any two locations within the same filter region receive the same
LoST results for all services</t>
</list> Given a location filter, it is easy to determine when a given
location value is sufficiently precise, or to create a less precise
version of location that is still precise enough. Namely, a location
value is precise enough when if fits within a given filter region, and
any superset of a location value (e.g., a polygon containing a point)
can be used as a less precise version of the location value, as long as
it still fits within the same filter region.</t>
<section anchor="filter-for-point-sec"
title="Filter Region for a Known Location">
<t>A simple fuzzing algorithm that maintains sufficient precision for
emergency services is to replace a given location value with the
filter region that contains it. Given a known location, a location
server can compute a filter region using a series of LoST queries.</t>
<t>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 different services, the intersection of those service boundaries
is the region in which all of the corresponding mappings are valid. If
one service boundary corresponds to the area where
"urn:service:sos.fire" is served by "sip:fire@example.com" and another
maps "urn:service:sos.police" to "sip:police@example.com", then the
intersection is the area where both of these 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. So as was suggested
above, the intersection of two service boundaries defines a set of
mappings, and any two locations within that intersection are
equivalent for the purpose of LoST mapping (i.e., emergency call
routing).</t>
<t>Filter regions can be deduced constructed from LoST mappings for a
sample location by intersecting all the service boundaries for
services available at that point. <xref target="sample-fig"/>
illustrates how the filter region containing the point X is the
intersection of the service boundaries for police and fire services
that serve X.</t>
<figure anchor="sample-fig"
title="Generating a Filter Region from a Sample Point">
<artwork><![CDATA[
sos.police sos.fire sos.ambulance
+-------+ +---------------+
| A | | B |
| | | | +-------+
| X | | X | | X |
+-------+ +---------------+ | |
| C |
+-------+
| | |
| | |
+-------------------+-------------------+
|
V
+-------+-------+
| A | B |
| +-------+ |
| | X | | |
+-------+-------+
| C |
+-------+
|
|
V
+---+
| X |
+---+
Resulting filter region
(police=>A, fire=>B, ambulance=>C)
]]></artwork>
</figure>
<t>In pseudocode form, algorithm for constructing a filter region from
a point is as follows:</t>
<figure>
<artwork><![CDATA[
function filterRegion(X):
Set REGION = the world
For each service URN S in the urn:service:sos namespace
Perform a LoST <findService> query for Y and S
If LoST returned an error
Continue
Set SB = <serviceBoundary> from LoST <findServiceResponse>
If SB is not provided, throw an error
Else set REGION = intersection( REGION, SB )
Return REGION
]]></artwork>
</figure>
<t>It is important that the filter take into account all emergency
services available in over the coverage area of the LIS. (That is, the
services listed in the LoST serviceList elements.) The feature is
necessary in order to ensure that calls to all available emergency
services can be routed correctly using rough location values provided
by the filter.</t>
<t>While in principle, a location server could execute this algorithm
to compute a fresh filter region on each query, it is much more
efficient to use the offline algorithm for computing an entire
location filter, described in the next section.</t>
</section>
<section title="Constructing a Location Filter">
<t>When a location server knows ahead of time that it will be
providing rough location values, it can pre-compute a location filter
that contains all the filter regions for locations it's concerned
with. Once the filter has been computed (as an off-line computation),
the filter region for a given precise location can be found by
searching for the pre-computed region that contains the precise
location. When precise location is not known, a complete filter can be
used to test evaluate the utility of an imprecise location by
determining the degree to which it overlaps with each filter
region.</t>
<t>For example, a simple fuzzing algorithm that maintains sufficient
precision for emergency services is to replace a given location value
with the filter region that contains it. This way, the server can
compute the filter off-line (as described below), then provision the
location of each possible device by storing a pointer to the filter
region that contains the device's location.</t>
<figure anchor="filter-fig"
title="Generating a Filter from Service Boundaries">
<artwork><![CDATA[
Service boundaries for individual services
urn:service:sos.police urn:service:sos.fire
+-------+ +-------+
| A | | C |
| +---+ | +---+---+
| | | | | |
+---+---+ | +---+ |
| B | | D |
+-------+ +-------+
| |
| |
+-----------+------------+
|
V
+-------+
| A,C |
| +---+
| | +---+
+---+ |A,D| +---+
+---+ | |
+---+ |
| B,D |
+-------+
Resulting Location Filter Regions
]]></artwork>
</figure>
<t>The filter regions in a filter can are constructed by taking
intersections of service boundaries. <xref target="filter-fig"/> shows
a simple location filter: Starting with a set of four service
boundaries for two different services. The filter that results from
taking intersections of these boundaries has three regions: <list
style="numbers">
<t>A region where police calls are directed to A and fire calls
are directed to C.</t>
<t>A region where police calls are directed to A and fire calls
are directed to D.</t>
<t>A region where police calls are directed to B and fire calls
are directed to D.</t>
</list> These regions satisfy the criteria for a location filter
because each one has a unique set of mappings and those mappings are
valid across the entire region. The service regions for B and C do not
overlap -- there is no place where police calls go to B and fire calls
to C -- so there is no (B,C) region.</t>
<t>More generally, a filter region is the intersection of the service
boundaries for all services available within the region. A filter can
be used to determine whether a location is usable for emergency call
routing in the following way:<list style="numbers">
<t>The location SHOULD be contained in exactly one of the regions
in the filter. This guarantees that LoST mappings are unique.</t>
<t>When the precise 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.</t>
<t>When the precise location of the endpoint is known, the
provided location MUST contain the precise location (as a
geographic subset).</t>
</list></t>
<t>Practically speaking, a location filter is built up by computing
filter regions for sample points, using the algorithm described above.
In the example of <xref target="filter-fig"/>, one would need to
sample three points: One in the (A,C) region, one in the (A,D) region
and one in the (B,D) region. The overall algorithm thus samples random
points until the computed filter regions cover the desired area. (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". In principle, this coverage area could be
the entire world, but assuming a more limited coverage area allows for
a filter to be built more quickly)</t>
<figure>
<artwork><![CDATA[
function filter(LS_AREA):
Set FILTER = the empty set
Set COVERAGE = the empty set
Set ERR_COUNT = 0
While COVERAGE < LS_AREA && ERR_COUNT < 100
Choose a random uncovered point X in LS_AREA
Compute R = filterRegion(X)
If R != the empty set
Add R to FILTER
Set COVERAGE = union(COVERAGE, R)
Else
ERR_COUNT += 1
Return FILTER
]]></artwork>
</figure>
<t>If the server also stores the lists of URN-URI mappings for each
region, then the filter can also be used as a cache for LoST mappings;
the LoST mappings for a location are the mappings bound to the
region(s) containing it.</t>
<t>If the LoST servers have been provisioned properly then this
algorithm will terminate successfully. If LoST mappings do not cover a
point X, then the filterRegion(X) will return the empty set, and the
algorithm will give up after 100 such queries. This limit on queries
introduces some risk that a small covered area will be left out of the
filter and marked as uncovered; if this is a concern, then the query
limit can be increased, or the algorithm can be explicitly directed to
sample certain specific points.</t>
<t>Of course, if the location server operator has information about
service boundaries through some channel other than LoST, then the LoST
queries above can be replaced by queries to a local store of mapping
information. The choice of random points can also be guided to ensure
that all mapped areas are covered even if there are some uncovered
areas. The location server can also cache service boundaries acquired
during the algorithm to avoid unnecessary LoST queries.</t>
</section>
<section title="Civic Address Considerations">
<t>This algorithm actually results in two filters -- one for geodetic
service boundaries and one for civic service boundaries -- since civic
and geodetic boundaries cannot be directly compared or intersected. It
is RECOMMENDED that location servers always compute a geodetic filter
for use with emergency services, since the notion of civic service
boundaries have some inherent ambiguity.</t>
<t>Indeed, the notion of intersection of civic service boundaries has
some dependence on the jurisdiction within which the service
boundaries are defined. Civic service boundaries are comprised of a
set of <civicAddress> elements, each defining a set of civic
addresses that are within the boundary, namely those that match the
civic elements provided.</t>
<t>When computing the intersection of two civic service boundaries,
any <civicAddress> elements that are shared between the two
service boundaries MUST be included in the resulting intersection.
When two <civicAddress> elements in the service boundaries being
compared are different from each other, then their intersection must
be computed according to local addressing standards.</t>
<t>Note that the resulting filter regions SHOULD still cover the
location server's coverage area, i.e., there should be a filter region
that contains every civic address within the coverage area. In
particular, the server SHOULD NOT use a specific address to represent
a filter region: Such an address would not include many points in the
service region (i.e., it would not meet the third rules from the lists
of rules above). If the server creates a PIDF-LO document describing a
civic address that does not contain the precise location of the
device, then it MUST set the 'method' element of the PIDF-LO it
returns to value 'area-representative' registered in <xref
target="iana-sec"/>.</t>
<t>If the above procedures are not workable for a given scenario, then
the server MAY fall back to geocoding of service boundaries, in which
case the above procedures for geodetic location can be used.</t>
<t>Geocoding may also be necessary in cases where the location of the
target is known as a civic address with limited granularity, with
which service boundaries do not align. For instance, the target's
location may be known to the level of a postal code, but postal code
regions may span multiple PSAP service areas or filter regions. In
such cases, the server MAY geocode the target's location to obtain a
rough geodetic position, which can be dealt with as discussed in <xref
target="sec-sec-applying"/> below.</t>
</section>
<section title="Privileged LoST Servers">
<t>In certain scenarios, it may be possible that some LoST servers are
authorized to access more precise location information than networks
are willing to reveal to endpoints. For example, a network operator
might allow a LoST server operated by a national authority to access
an endpoint's precise location, even if it does not allow the endpoint
access to this information.</t>
<t>In these situations, the precision required for emergency services
routing is different than in the base case considered above. Rather
than needing location precise enough to identify a given PSAP, the
location value provided to the endpoint only needs to be precise
enough to route the LoST request through the mapping infrastructure to
a LoST server that is authorized to access the endpoint's precise
location. Once the request reaches that server, the server can request
more precise location information and use that information to route
the request further.</t>
<t>Indeed, such privileged LoST server could even be operated by the
network itself. In this case, if an endpoint complies with requirement
ED-52 in <xref target="I-D.ietf-ecrit-phonebcp"/>, it will send its
LoST request directly to the network-provided LoST server, which can
look up the client's location and return mappings. However, it is
possible that clients will use an alternative LoST resolver, so it is
still beneficial to provide a rough location that can route the
request to a nearby privileged LoST server.</t>
<t>In cases where a network allows one or more privileged LoST servers
to access precise location information, the network MAY designate a
location that is precise enough to reach one of these LoST servers as
precise enough for emergency call routing.</t>
<t>This document does not specify how these privileged LoST servers
could obtain more precise location information from network operators.
One possible solution is to extend LoST to carry a location reference
in addition to a location by value.</t>
</section>
<section title="Maintaining Location Filters">
<t>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
intersect 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.</t>
</section>
<section anchor="sec-sec-applying" title="Applying Location Filters">
<t>After constructing a location filter, a location server can use it
to optimize how it delivers location. How this is done depends on
whether the location server is trying to reduce the precision of a
known precise location, or trying to determine whether an imprecise
position is good enough for emergency services.</t>
<t>When the location provider knows the precise location of the
caller, a location filter can also be used as a "location cache". That
is, the location provider can simply look up which of the filter
regions contains the caller's precise location and return that region
as the caller's location, or some subset that contains the precise
location.</t>
<t>This caching strategy allows an additional optimization in some
cases: If the location server knows that the caller's precise location
will be within the same region for a period of time, it can instruct
the client not to re-query in that time. For instance, if the server
is delivering location over HELD, then it can use the HTTP
cache-control headers (e.g., Expires). However, the location server
MUST NOT instruct the client to wait for longer than the current
filter is valid; the expiry time of the location MUST be before the
earliest expiry of a LoST mapping used in the filter.</t>
<t>When the location server starts with imprecise location, there are
different ways to apply the filter, depending on the positioning
technique being used. For example with a positioning algorithm that
grows more accurate with time, the filter can tell the server how long
to run the algorithm -- the algorithm can be terminated when the
estimated location (that is, an uncertainty region containing the
device's location) is within one of the regions in the filter.</t>
<t>A location filter can also be used to test whether a database of
rough locations for IP addresses (as is commonly used for web
localization today) contains precise enough values for use with
emergency services. To make this determination, each value in the
database woud be tested to see if it falls mostly or entirely within a
given filter region. Note, however, that this test does not address
concerns about the accuracy of location information, i.e., the
probability that the caller is actually contained within the specified
uncertainty region.</t>
<t>Note that the requirements for containment in a filter region
differ between these two use cases. When precise location is known,
the rough location that is returned MUST be contained within a single
filter region; otherwise, there will be an increased risk of
mis-routing. When the location server starts with imprecise location,
it may choose location values that are not entirely within one filter
region. The distribution of the imprecise location value among filter
regions corresponds to the risk that LoST routing will provide
incorrect information, so the choice of location value should balance
the risk of incorrect routing against the additional time needed to
obtain more precise location (which can translate to a delay in call
setup). In this case, it may not even be possible for a location
server to return a location value that is entirely within a single
filter region.</t>
</section>
</section>
<section anchor="lbs-section"
title="Additional Requirements for Networks and Endpoints">
<t>When a location provider wishes to deliver endpoints location
information that is below its maximum available precision while still
supporting emergency calling, it MUST provide to the endpoint a location
(by value) that is sufficient for emergency call routing (as defined
above) and MUST provide 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
emergency services and other location-based services (LBS).</t>
<t>This arrangement allows the client to provide rough location (by
value) to any entity, and to provide precise location (by reference) to
authorized parties. An assumption of this model, of course, is that
emergency authorities are authorized by the location provider to receive
precise location. Location providers may also authorize other entities
to receive precise location information (e.g., commercial services that
have agreed to pay for location). Authorization policy for location URIs
is set by the referenced location server; a mechanism for clients to
request information about this policy is described in <xref
target="I-D.barnes-geopriv-policy-uri"> </xref>.</t>
<t><list style="hanging">
<t hangText="ED-84:">When an endpoint has access to location both by
value and by reference, it MUST include both forms of geolocation in
the SIP INVITE message initiating an emergency call, each in a
separate Geolocation header. The endpoint SHOULD include a
Geolocation-Routing header with the value "yes".</t>
<t hangText="AN-30:">Networks providing imprecise location MUST also
provide location by reference.</t>
<t hangText="AN-31:">Networks providing imprecise location SHOULD
provide DHCP-based LoST discovery, advertising a LoST server that is
authorized to dereference location URIs issued by the network's
LIS.</t>
</list></t>
<t>The overall procedure for placing an emergency call is identical to
that described in <xref target="RFC6443"/>. In particular, the endpoint
requirements in Sections 8 and 9 of <xref
target="I-D.ietf-ecrit-phonebcp"/> still apply to an endpoint that
receives imprecise location, with the above modification (use of the
location URI in LoST).</t>
<t>In addition, 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 <xref target="RFC6442"/>.
Note that this process crucially relies on the location value having
sufficient precision for routing emergency calls (see <xref
target="det-section"/> for techniques to ensure the location value is
suitable for emergency call routing).</t>
<t>When a PSAP receives a SIP INVITE that contains both a location value
and a location reference, and 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 SHOULD 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 PSAPs in its service area. It
is RECOMMENDED that location providers establish similar relationships
with other PSAPs in adjoining jursidictions -- even if their service
regions do not overlap with the location provider's -- in case such a
PSAP needs access to precise location information, for example, if it is
acting as a backup for one of the location provider's normal PSAPs.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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. Thanks to Hannes
Tschofenig and Martin Thomson for detailed reviews of this document.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The use of imprecise location provides a security trade-off for
location providers. When location providers are required to provide
location in support of emergency services, they have to balance that
requirement against the risk that location information will be disclosed
to an unauthorized party. The use of location configuration protocols
inherently introduces some risk that an entity other than the device
will be able to masquerade as the device (e.g., another host behind the
same NAT or malicious software on the host) <xref target="RFC5687"/>. In
some cases, the location provider may not authorize the device itself to
access precise location. At the same time, because endpoints can roam
between networks, it is operationally difficult to have strong client
authentication for LCPs.</t>
<t>Using of rough location to support emergency calling enables a
location provider to provide low-precision location with low assurance
(e.g., without client authentication)and high-precision location with
higher assurance. Because lower-precision location generally has lower
value -- to location providers and LBS providers as a commercial asset,
and to devices as private information -- this trade-off allows a
location provider to avoid the cost of protecting location with
high-assurance access controls when this location has low value.</t>
<t>However, in order to support emergency services, location providers
cannot provide only low-precision location; they also have to provide
PSAPs with access to high-precision location information. Because PSAPs
require high-precision location for emergency response, a location
provider that normally provides imprecise location to clients MUST also
provide them a location URI that a PSAP can use to obtain high-precision
location. This constraint means that the provided URI MUST have either
no access control at all or a policy that allows access by appropriate
PSAPs and other emergency response systems, e.g., ESRPs. That is, if
such a location URI is access controlled, then the location provider
MUST be able to authenticate requests from PSAPs.</t>
<t>The use of location by reference introduces some risk that the
reference will be used by an attacker to gain unauthorized access to the
device's location. These risks are not specific to emergency service,
however; general risks and mitigations for location by reference are
discussed in <xref target="RFC5808"/></t>
<t>As described in <xref target="filter-use-section"/> 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 some privacy 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. An algorithm for securely fuzzing a device's location can
be found in <xref target="I-D.ietf-geopriv-policy"/>; for emergency
services, the additional constraint must be added that the fuzzed
location must remain in the same filter region as the original.</t>
</section>
<section anchor="iana-sec" title="IANA Considerations">
<t>This document requests that IANA register a new PIDF-LO 'method'
token in the registry defined by RFC 4119 <xref target="RFC4119"/> <list
style="hanging">
<t hangText="area-representative:">Location chosen as a
representative of a region in which the device is located; may not
be the device's location.</t>
</list></t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
&phonebcp;
&RFC5222;
&RFC4119;
</references>
<references title="Informative References">
&uncertainty;
&policyuri;
&civicbound;
&RFC6442;
&RFC6443;
&RFC6444;
&RFC5582;
&RFC5687;
&RFC5808;
&policy;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:47:41 |