\section{Locating Emergency Callers}
\label{sec:locating}

Probably the most difficult aspect of an Internet-based emergency call
system is determining the civil (postal) or geographical (longitude,
latitude) user location.  The problem has two aspects, namely how the
end system or network determines the terminal's location
(Section~\ref{sec:determine}) and how the ECC obtains this information
(Section~\ref{sec:convey}).

\subsection{PSTN-only ECC}

\subsection{SIP-enabled ECC}

\subsection{Determining User Location}
\label{sec:determine}

End system
  privacy
  data in priv

End system + outbound proxy

Third party (non-SIP)
  privacy

First, devices or the network have to determine their geographic or
civil location.  This may well turn out to be easier for cellular
devices, where all the techniques suggested for second-generation
wireless systems can be applied.  These include GPS or radio-based
location \cite{Reed9804:Overview}.  For wireless LANs, the RADAR project
\cite{Bahl0003:RADAR} has shown that IEEE 802.11-based devices can be
located to room accuracy within a building if radio conditions are
modeled or surveyed.  However, GPS generally does not work within
buildings, so that even assuming desktop computers or Internet phones
could be economically equipped with GPS receivers, additional methods
have to be found.  Assisted GPS (APGS) \cite{Djuk0102:Geolocation} uses
location information for base stations to help mobile terminals acquire
location even within buildings or other conditions with degraded signal
strength.  (GPS systems presumably report a location just before
entering a building, which may well be sufficient.  This is less
satisfactory when entering a tunnel in the Alps or under the British
Channel since the old reading may be off by a whole country.  Also, GPS
location or triangulation is of limited usefulness within buildings due
to the large uncertainty in altitude.)

If the terminal obtains location information, it may need to update an
external server, such as DNS or a specialized location service
\cite{draft-tang-islf-req,draft-korkea-aho-isl-scenarios,draft-nyckelgard-isl-arch}.

For devices connected to local area networks, such as switched Ethernet,
it is suggested that each port periodically sends a message to the
attached devices indicating the geo or civil location.  The switch is
configured with this information via SNMP.  Since jacks are reasonably
stationary in most hard-wired installations, this requires only a
one-time effort, but would require a substantial upgrade effort for
existing installations.  However, due to the use of patch panels and
hubs, there is a chance that small-scale inaccuracies creep in, but
probably at the scale of room numbers rather than buildings.  (In
addition, this information could also be useful for asset management.)

Even for wireless LANs with base station connected to Ethernet switches,
this would provide location accuracy of about 100 to 300' and generally
within a single floor of a building.

Location information can also be configured directly into end systems,
preferably in a manner that allows all applications access to this
information.  This would allow SIP, for example, to simply add a header
or message body part to emergency call setup requests or mid-call
{\INFO} requests containing the geographic location.  However, the
likelihood that users will correctly enter or update this information is
low, even if, for example, operating systems would require entry of such
information.  Even with modestly mobile systems, such as PCs that are
moved from office to home or moved between homes, the information is
likely to be out of date in a significant fraction of cases.

This approach has the advantage that the end system controls the
delivery of information.  On the other hand, applications then have to
be aware when the user contacts the emergency address.

\subsection{Conveying User Location to the iPSAP}
\label{sec:convey}

The user location can be conveyed to the iPSAP in a number of different
ways, as illustrated in Fig.~\ref{fig:911_location}.  Generally, the
location information can be delivered directly by the end system into
application-layer protocols, inserted by SIP proxies or obtained by
the iPSAP from either the device or a database.  The first two methods
depend on the application-layer protocol, while the latter can be used
for any protocol employed to contact the iPSAP.  We evaluate some of the
alternatives below and summarize the options in Table~\ref{tab:convey}.

\txtpsfigsize{\textwidth}{!}{911_location}{Architecture for obtaining and
conveying location information to a PSAP}

\begin{table}[htpb]
\begin{flushleft}
\begin{tabular}{llll}
Method & Sec. & suitable for & modifications required?\\
\hline
DNS        & \ref{sec:dns}       & any & no\\
SLoP       & \ref{sec:slop}      & any & no\\
Identifier & \ref{sec:esid}      & any & yes\\
ISP        & \ref{sec:isp}       & any & true IP address\\
SIP URL    & \ref{sec:sip_url}   & SIP & \\
SIP proxy  & \ref{sec:sip_proxy} & SIP & \\
\end{tabular}
\end{flushleft}
\caption{Comparison of options for conveying system location to the iPSAP}
\label{tab:convey}
\end{table}

\subsubsection{DNS}
\label{sec:dns}

Network providers or terminals can store location information in DNS,
via dynamic DNS updates.  DNS-based schemes have been defined that yield
either a civil \cite{draft-costanzo-dns-gl} or a geographic location,
based on a caller's domain name.  For example,
\cite{draft-costanzo-dns-gl} defines DNS resource records of the form
below:

\begin{verbatim}
donuts A 192.188.192.1
       GL S3.US.45420.1910 "1425 Arbor Avenue, Dayton OH"
\end{verbatim}
From the record, the country (US), 9-digit zip code (45420-1910) and the
street address can be determined.

Alternatively, DNS can also contain geographic information, encoded either
as strings \cite{rfc1712}, e.g.,
\begin{verbatim}
<owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
\end{verbatim}
\begin{verbatim}
GPOS -32.6882 116.8652 10.0
\end{verbatim}
or as binary (RFC 1876 \cite{rfc1876}).  RFC 1876 \cite{rfc1876} also
offers an indication of the precision of the location, as well as the
circumference of the object.  An example RFC 1876 record might contain
\begin{verbatim}
cambridge-net.kei.com. LOC   42 21 54 N 71 06 18 W -24m 30m
\end{verbatim}

DNS mechanisms work only if the mapping between device and location is
correct.  If given an IP address in the SIP request, e.g., in the SDP
``c='' line or the SIP \header{Contact} header, it does an reverse
address lookup first to obtain a domain name.  As long as both the
reverse mapping and location part of the DNS entry is updated
dynamically by the network provider or end system, this also works when
IP addresses are assigned dynamically.  It gets significantly more
complicated if NATs or NAPTs are used since several different devices, in
different locations, may share the same IP address.  If mobile IP is
used, the visited network has to do the DNS updates.

If IP addresses are assigned dynamically, the mapping becomes
significantly more difficult, also requiring dynamic DNS updates. For
IPv6, if the host portion of the IP address remains constant, it may be
usable as a key.

DNS information, including location information, is available to
anybody, raising serious privacy concerns.  DNS is fundamentally not
designed to limit the distribution of information, although access
control additions to DNS may be feasible.

\subsubsection{SLoP (Spatial Location Protocol)}
\label{sec:slop}

A specialized protocol for obtaining location information is being
discussed within the IETF \cite{draft-korkea-aho-isl-scenarios}.  It
relies on a globally unique identifier for network objects. This
identifier in turn is used as a key into one of several databases
containing location information.

\subsubsection{End System Identifier}
\label{sec:esid}

An end system identifier such as a MAC address or the identifier
proposed by the SLoP effort \cite{draft-tang-spatial-target} is mapped
to a location in one or more global databases maintained by civil
authorities.  The database may be accessed, for example, through LDAP
\cite{rfc1777} or whois \cite{rfc954,rfc1714}.  This identifier would
then have to be conveyed in IP or application-layer messages such as SIP
{\INVITE} or {\INFO}.  However, such an identifier raises privacy
issues, even though access to the location database can be more readily
secured.  For non-stationary devices, the database still needs to be
updated by the end system or system administrator.

\subsubsection{Location Information Provided by ISP}
\label{sec:isp}

Since network access providers generally identify their customers via
PPP authentication, or by setting up a key for cable modems or via the
physical line for a digital subscriber line, they have the necessary
location information as part of their normal billing and maintenance
records.  Thus, they appear to be in the best position to supply this
information.  One model has the iPSAP use reverse address mapping on the
IP address of the request (or some other identifier at the application
layer) to the organization that was delegated this address or
identifier.  (This information can be obtained via whois from {\tt
whois.arin.net}, {\tt whois.apnic.net} or {\tt whois.ripe.net}.) This
organization then maintains a server that maps addresses to customer
locations, using any remote query protocol.  This clearly imposes
additional requirements on the coupling between DHCP and customer
databases.  If a permanent customer identifier, scoped by AS, is
conveyed by application-layer protocols making emergency calls, the
mapping is static, but additional changes to DHCP and application
support is needed.

The above outline of a solution glosses over a number of potential
problems.  For dial-in users, the calling number is needed; it is
available to the modem pool unless the caller suppresses caller id and
so it could be propagated along with the billing/``home'' location.

NATs would have to update the organization's customer-to-IP-address
database on a connection-by-connection basis.  However, NATs can be
ignored in many residential and small-business access networks, as each
household or business is assigned one IP address, shared by a number of
devices.

\begin{changebar}
Depending on whether reverse tunneling is used or not, mobile IP may
also obscure the ``physical'' IP address.  For SIP, the network address
of the SIP request is likely to identify the outbound proxy or some
other proxy in the call path, not the IP address of the caller.  Thus,
the iPSAP should use the address in the SDP message instead.
\end{changebar}

\subsubsection{Location Derived from SIP URL}
\label{sec:sip_url}

This approach is specific to SIP-based emergency calls.  The iPSAP could
also query the domain indicated in the SIP URL in the request's
\header{From} header.  However, this is not likely to work since the SIP
URL may be provided by a service provider that has no direct transport
relationship with the user and, in all likelihood, does not have correct
address information since it may not have a billing relationship to the
user.  Even assuming that this service provider has a correct address
record for the customer, this approach fails for users that move.  For
example, a user logging in from a hotel room would still be located as
being at home.

\subsubsection{SIP Proxy Inserts Location Information}
\label{sec:sip_proxy}

The outbound SIP proxy can insert the information obtained from the
local authentication database into SIP requests, assuming again that all
(911) SIP requests use an outbound proxy associated with a
transport-based ISP that has accurate customer records.

For example:
\begin{verbatim}
GPos: 42 21 54 N 71 06 18 W -24m 30m
GL: S3.US.45420.1910 "1425 Arbor Avenue, Dayton OH"
\end{verbatim}
This approach has the advantage that it looks the same to the iPSAP
whether information is derived via GPS or by the proxy.

\subsubsection{Summary}

It is likely that a combination of mechanisms will need to be deployed.
For wireless end systems, either the end system or the wireless network
operator can readily offer location information, either reflected back
through the end system into application-layer protocol or via a system
identifier and a database accessible to iPSAP authorities.

For landline devices attached to LANs, it appears easiest to enhance
Ethernet switches to provide location information to their ports, as all
other mechanisms are likely to be difficult to maintain as devices move
from place to place.
