[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
ECRIT                                                      H. Tschofenig
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                            H. Schulzrinne
Expires: January 3, 2008                             Columbia University
                                                            July 2, 2007


   Emergency Services Architecture Overview: Sharing Responsibilities
          draft-tschofenig-ecrit-architecture-overview-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 January 3, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes the IETF emergency services architectures and
   illustrates the architectural principles and responsibilities of
   different parties.  For comparison, we also describe the emergency
   services architecture developed by 3GPP.






Tschofenig & Schulzrinne  Expires January 3, 2008               [Page 1]


Internet-Draft  Emergency Services Architecture Overview       July 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The IETF Emergency Services Architecture . . . . . . . . . . .  5
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  The 3GPP Emergency Services Architecture  . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 17





































Tschofenig & Schulzrinne  Expires January 3, 2008               [Page 2]


Internet-Draft  Emergency Services Architecture Overview       July 2007


1.  Introduction

   Summoning police, the fire department or an ambulance in emergencies
   is one of the fundamental and most-valued functions of the telephone.
   As telephone functionality moves from circuit-switched telephony to
   Internet telephony, its users rightfully expect that this core
   functionality will continue to work at least as well as it has for
   the older technology.  New devices and services are being made
   available that could be used to make a request for help, which are
   not traditional telephones, and users are increasingly expecting them
   to be used to place emergency calls.

   Existing emergency call systems are organized nationally; there are
   currently no international standards.  However, the Internet does not
   respect national boundaries, and thus international standards are
   required.  To further complicate matters, emergency services support
   needs to be added to a huge Internet where VoIP endpoints are subject
   to numerous access technologies and limitations, such as virtual
   private networks (VPNs), mobility protocols, firewalls, Network
   Address Translators (NATs), different IP versions including devices
   that translate from one to another version, different Voice over IP
   protocols, etc.  In addition to these technical obstacles, different
   business models exist where a Voice Server Provider (VSP) or an
   Application Server Provider (ASP) are separate from the Internet
   Service Provider (ISP) and the Internet Attachment Provider (IAP).

   This document describes the IETF emergency services architectures and
   illustrates the architectural principles and the responsibilities of
   different parties.

   The 3GPP emergency services architecture, summarized in Appendix A,
   splits responsibilities somewhat differently.


2.  Terminology

   This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps]
   and [I-D.ietf-ecrit-requirements].  To make this document self-
   contained we copy-and-paste the relevant terms into this section:

   Internet Access Provider (IAP):

      An organization that provides physical and data link (layer 2)
      network connectivity to its customers or users, e.g., through
      digital subscriber lines, cable TV plants, Ethernet, leased lines
      or radio frequencies.  Examples of such organizations include
      telecommunication carriers, municipal utilities, larger
      enterprises with their own network infrastructure, and government



Tschofenig & Schulzrinne  Expires January 3, 2008               [Page 3]


Internet-Draft  Emergency Services Architecture Overview       July 2007


      organizations such as the military.

   Internet Service Provider (ISP):

      An organization that provides IP network-layer services to its
      customers or users.  This entity may or may not provide the
      physical-layer and data link (layer-2) connectivity, such as fiber
      or Ethernet, i.e., it may or may not play the role of an IAP.

   Application Service Provider (ASP):

      The organization or entity that provides application-layer
      services, which may include voice (see "Voice Service Provider").
      This entity can be a private individual, an enterprise, a
      government, or a service provider.  An ASP is more general than a
      Voice Service Provider, since emergency calls may use other media
      beyond voice, including text and video.  For a particular user,
      the ASP may or may not be the same organization as his IAP or ISP.

   Voice Service Provider (VSP):

      A specific type of Application Service Provider which provides
      voice related services based on IP, such as call routing, a SIP
      URI, or PSTN termination.  In this document, unless noted
      otherwise, any reference to "Voice Service Provider" or "VSP" may
      be used interchangeably with "Application/ Voice Service Provider"
      or "ASP/VSP".

   Emergency Service Routing Proxy (ESRP):

      An ESRP is an emergency call routing support entity that invokes
      the location-to-PSAP URI mapping function, to return an
      appropriate PSAP URI, or the URI for another ESRP.  Client mapping
      requests could also be performed by a number of entities,
      including entities that instantiate the SIP proxy role and the SIP
      user agent client role.

   Public Safety Answering Point (PSAP):

      Physical location where emergency calls are received under the
      responsibility of a public authority.  (This terminology is used
      by both ETSI, in ETSI SR 002 180, and NENA.)  In the United
      Kingdom, PSAPs are called Operator Assistance Centres, in New
      Zealand, Communications Centres.  Within this document, it is
      assumed, unless stated otherwise, that PSAPs support the receipt
      of emergency calls over IP, using appropriate application layer
      protocols such as SIP for call signaling and RTP for media.




Tschofenig & Schulzrinne  Expires January 3, 2008               [Page 4]


Internet-Draft  Emergency Services Architecture Overview       July 2007


   Location Configuration Server (LCS):

      The term LCS refers to an entity capable of determining the
      location of an end point and of providing that location
      information, a reference to it, or both) via the Location
      Configuration Protocol (LCP) to the requesting party, in most
      cases to the end point itself or to an entity that acts on behalf
      of it.

   (Emergency) service dial string:

      The service dial string identifies the string of digits that a
      caller must dial to reach a particular (emergency) service.  In
      devices directly connected to the PSTN, the service dial string is
      the same as the service number and may thus depend on the location
      of the caller.  However, in private phone networks, such as in
      PBXs, the service dial string consists of a dialing prefix to
      reach an outside line, followed by the emergency number.  For
      example, in a hotel, the dial string for emergency services in the
      United States might be 9911.  Dial strings may contain indications
      of pauses or wait-for-secondary- dial-tone indications.

   (Emergency) service identifier:

      The (emergency) service identifier describes the emergency
      service, independent of the user interface mechanism, the
      signaling protocol that is used to reach the service, or the
      caller's geographic location.  It is a protocol constant and used
      within the mapping and signaling protocols.  An example is the
      service URN [I-D.ietf-ecrit-service-urn].

   For the purpose of this document we assume that the ISP and the IAP
   colaps into a single entity.  We use the term ISP only.  Furthermore,
   unless noted otherwise, any reference to "Voice Service Provider" or
   "VSP" may be used interchangeably with "Application/ Voice Service
   Provider" or "ASP/VSP".


3.  The IETF Emergency Services Architecture

   The emergency services architecture developed in the IETF Emergency
   Context Resolution with Internet Technology (ECRIT) working group,
   see [I-D.ietf-ecrit-framework], describes an architecture where
   location information is provided by the IAP/ISP to end points in
   order to determine the correct dial string and a Uniform Resource
   Identifier (URI) to route the call to a Public Safety Answering Point
   (PSAP) via the user's VoIP provider.  The Location-to-Service
   Translation (LoST) protocol [I-D.ietf-ecrit-lost] allows to determine



Tschofenig & Schulzrinne  Expires January 3, 2008               [Page 5]


Internet-Draft  Emergency Services Architecture Overview       July 2007


   the PSAP URI for a specific geographical location together with an
   emergency service identifier, see [I-D.ietf-ecrit-service-urn].  The
   basic architecture is shown in Figure 1.  Detailed message flows are
   illustrated in Figure 2 of [I-D.ietf-ecrit-framework].

   The obligations for the different parties are summarized below.  An
   IETF draft [I-D.ietf-ecrit-phonebcp] describes these in much more
   detail, including callback capabilities, support for certain codecs,
   and SIP call handling behavior specific to emergency calls.  The
   distributed mapping database may be operated by the ISP/IAP, the VSP,
   the PSAP operator, another independent entity or in parts by all
   these different entities.  A description of the mapping architecture
   can be found in [I-D.ietf-ecrit-mapping-arch].

   The obligations for the different parties are as follows:

   End Host:

      *  An end host, through its VoIP applications, has three main
         responsibilities: it has to obtain its own location, determine
         the URI of the appropriate PSAP for that location, and
         recognize when the user places an emergency call by examining
         the dial string.  The end host operating system may assist in
         determining the device location.

         The protocol interaction is shown as (A) in Figure 1.  A number
         of protocols have been developed to provide this capability, as
         listed in Section 4.2 of [I-D.ietf-ecrit-phonebcp].
         [I-D.ietf-ecrit-phonebcp] mandates support DHCP (see [RFC4776]
         and [RFC3825]), HELD (see
         [I-D.ietf-geopriv-http-location-delivery] and LLDP-MED (see
         [LLDP-MED]).

      *  A VoIP application needs to support the Location-to-Service
         Translation (LoST) protocol [I-D.ietf-ecrit-lost] in order to
         determine the emergency service dial strings and the PSAP URI.
         Additionally, the service identifiers, defined in
         [I-D.ietf-ecrit-service-urn], need to be understood by the
         device.

      *  In the current architecture, it is assumed that PSAPs can be
         reached by SIP and RTP, but may support other signaling
         protocols, either directly or through a protocol translation
         gateway.  The LoST retrieval results indicate whether other
         VoIP signaling protocols are supported.






Tschofenig & Schulzrinne  Expires January 3, 2008               [Page 6]


Internet-Draft  Emergency Services Architecture Overview       July 2007


   IAP/ISP:

      *  The IAP/ISP has to make location information available to the
         end point via one or more of the above-mentioned protocols,
         namely DHCP (see [RFC4776] and [RFC3825]), HELD (see
         [I-D.ietf-geopriv-http-location-delivery]) and LLDP-MED (see
         [LLDP-MED]).


            Emergency services need location information for two
            different purposes, first for routing the emergency call to
            the PSAP that is serving a specific geographical region for
            the emergency service requested and to dispatch emergency
            personnel to the scene of the accident, crime or other type
            of incident.  For the latter, the caller may be able to
            deliver this information orally, but it is generally agreed
            that emergency services protocols should deliver location
            information that is automatically generated, to increase
            accuracy and avoid dispatch delays when the caller is unable
            to provide location information due to language barriers,
            lack of familiarity with his or her surroundings or physical
            or mental impairment.

            The accuracy requirements for these two uses differ.  For
            call routing, city or county-level accuracy is often
            sufficient, while dispatch benefits greatly from having
            location that identifies a particular building or even room
            for indoor locations, or a radius of at most a few hundred
            feet for outdoor locations.

            In some cases, Internet Access Providers (IAPs) and/or the
            Internet Service Providers (ISPs) are afraid that allowing
            users to access location information for non-emergency
            purposes or prior to an emergency call will incur additional
            server load and thus costs.  Hence, they do not to disclose
            precise location information (at the quality suitable for
            dispatch emergency personnel by the PSAP operator) or not to
            disclose any location information.  The impact for the IETF
            emergency services architecture to support this type of
            functionality, referred as 'location hiding', is currently
            under investigation (see
            [I-D.schulzrinne-location-hiding-requirements].  It should
            be noted that the concept of hiding location information
            refers to call routing only.  ISPs have no interest or legal
            right to hide location information from emergency services
            personnel.





Tschofenig & Schulzrinne  Expires January 3, 2008               [Page 7]


Internet-Draft  Emergency Services Architecture Overview       July 2007


      *  The IAP/ISP may additionally operate a (caching) LoST server to
         improve the robustness and the reliability of the architecture.

      *  The IAP/ISP must allow signaling and media protocols used for
         emergency calls to traverse its network.

   VSP:

      *  The IETF emergency services architecture does not require the
         participation of a VSP as such.  However, if a caller uses a
         VSP, this VSP often forces all calls, emergency or not, to
         traverse an outbound proxy operated by the VSP.  Also, at least
         initially, customer equipment may not be able to perform LoST
         lookups and thus needs to rely on the VSP to recognize
         emergency calls and route them to the correct PSAP.

      *  If the VSP uses a signaling or media protocol that is not
         natively supported by the PSAP, it needs to offer protocol
         translation and gateway services.

      *  VSPs can assist the PSAP by providing identity assurance for
         emergency callers that are their customers.  Such identity
         assurance may assist with prosecuting prank callers.  However,
         identity assurance can only be effective if the VSP can
         authenticate their customers, e.g., by having a verifiable
         customer postal address.  (Verification by credit card usage
         fails when the credit card number has been stolen.)

   PSAP:

      *  The IETF architecture does not standardize PSAP architecture
         and only describes those aspects in [I-D.ietf-ecrit-phonebcp]
         that are necessary for emergency calls to be processed by the
         PSAP.  To make the overall architecture work, PSAPs must accept
         calls from any VSP/ASP in the world, as shown in protocol
         interaction (D) in Figure 1.  Since calls may come from
         anywhere, PSAPs must develop mechanisms to reduce the number of
         prank calls, particularly calls with spoofed location
         information.  [I-D.barnes-geopriv-lo-sec] discusses this
         problem.  The PSAP operator can expect to receive civic or
         geodetic location information in the format known as PIDF-LO,
         specified in [RFC4119], revised for civic location information
         by [I-D.ietf-geopriv-revised-civic-lo]) and profiled for
         geodetic information in [I-D.ietf-geopriv-pdif-lo-profile]).


   The distributed mapping database may be operated by the ISP/IAP, the
   VSP, the PSAP operator, another independent entity or in parts by all



Tschofenig & Schulzrinne  Expires January 3, 2008               [Page 8]


Internet-Draft  Emergency Services Architecture Overview       July 2007


   these different entities.  A description of the mapping architecture
   can be found in [I-D.ietf-ecrit-mapping-arch].


                  +---------------------------+
                  |                           |
                  | Emergency Network         |
                  | Infrastructure            |
                  |                           |
                  | +----------+ +----------+ |
                  | | PSAP     | | ESRP     | |
                  | |          | |          | |
                  | +----------+ +----------+ |
                  +-------------^-------------+   (D)
                                +----------------------+
                                                       |
   +--------------+                              +-----+--------+
   |              |              ----            |     |        |
   | ISP/IAP      |          ///-    -\\\        |     | VSP    |
   |              |         /            \\      |     |        |
   | +----------+ |        |  Distributed |      | +---+------+ |
   | | LCS      | |       |   Mapping      |     | | SIP      | |
   | |          | |       |   Database     |     | | Proxy    | |
   | +----------+ |        |              |      | +----------+ |
   |     ^        |         \            //      |     ^        |
   |     |        |          \\\-    -///        |     |        |
   |     |        |              ----            |     |        |
   +-----+--------+    (B)        ^              +-----+--------+
         |  +---------------------+                    |
      (A)|  |                                          |
         |  |  +---------------------------------------+
         |  |  |                    (C)
         v  v  v
     +----------+
     | End      |
     | Host     |
     +----------+

      Figure 1: Overview of the IETF Emergency Services Architecture


4.  Security Considerations

   This document does not describe the security aspects of the two
   architectures.  The protocol documents and the ECRIT security
   requirements [I-D.ietf-ecrit-security-threats] describe potential
   threats, and make protocol, implementation and operational
   recommendations to minimize these threats.



Tschofenig & Schulzrinne  Expires January 3, 2008               [Page 9]


Internet-Draft  Emergency Services Architecture Overview       July 2007


5.  Acknowledgments

   We would like to thank the ECRIT working group their work on the IETF
   ECRIT emergency services architecture.  Additionally, we would like
   to thank the participants of various emergency services workshops,
   meetings and phone conferences for sharing their view with us.

   The authors would particularly like to thank Alain Van Gaever from
   the European Commission for pushing us to write such a document.

   Dirk Kroeselberg, Leopold Murhammer, Richard Barnes, and James
   Winterbottom provided us review comments for the pre-00 version.


6.  Open Issues

   Currently, the IETF emergency services architecture does not describe
   how to handle calls that are not authorized to access a network due
   to lack of proper credentials or that are not configured with a
   particular VSP.

   There is currently no mechanism for prioritizing access to network
   resources for emergency calls, e.g., during mass casualty event.


7.  References

7.1.  Normative References

   [I-D.ietf-ecrit-lost]
              Hardie, T., "LoST: A Location-to-Service Translation
              Protocol", draft-ietf-ecrit-lost-05 (work in progress),
              March 2007.

   [I-D.ietf-sip-location-conveyance]
              Polk, J. and B. Rosen, "Session Initiation Protocol
              Location Conveyance",
              draft-ietf-sip-location-conveyance-07 (work in progress),
              February 2007.

   [I-D.ietf-ecrit-service-urn]
              Schulzrinne, H., "A Uniform Resource Name (URN) for
              Services", draft-ietf-ecrit-service-urn-06 (work in
              progress), March 2007.

   [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4776, November 2006.



Tschofenig & Schulzrinne  Expires January 3, 2008              [Page 10]


Internet-Draft  Emergency Services Architecture Overview       July 2007


   [RFC3825]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
              Configuration Protocol Option for Coordinate-based
              Location Configuration Information", RFC 3825, July 2004.

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

   [I-D.ietf-geopriv-pdif-lo-profile]
              Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification,
              Considerations and Recommendations",
              draft-ietf-geopriv-pdif-lo-profile-07 (work in progress),
              April 2007.

   [I-D.ietf-geopriv-revised-civic-lo]
              Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for PIDF-LO",
              draft-ietf-geopriv-revised-civic-lo-05 (work in progress),
              February 2007.

   [LLDP-MED]
               ,  ., "ANSI/TIA-1057, Link Layer Discovery Protocol for
              Media Endpoint Devices (aka LLDP-MED)", April 2006.

7.2.  Informative References

   [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-02 (work in
              progress), April 2007.

   [I-D.ietf-ecrit-framework]
              Rosen, B., "Framework for Emergency Calling in Internet
              Multimedia", draft-ietf-ecrit-framework-01 (work in
              progress), March 2007.

   [I-D.marshall-geopriv-lbyr-requirements]
              Marshall, R., "Requirements for a Location-by-Reference
              Mechanism used in Location  Configuration and Conveyance",
              draft-marshall-geopriv-lbyr-requirements-01 (work in
              progress), March 2007.

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-00 (work in
              progress), June 2007.

   [I-D.ietf-ecrit-mapping-arch]



Tschofenig & Schulzrinne  Expires January 3, 2008              [Page 11]


Internet-Draft  Emergency Services Architecture Overview       July 2007


              Schulzrinne, H., "Location-to-URL Mapping Architecture and
              Framework", draft-ietf-ecrit-mapping-arch-01 (work in
              progress), December 2006.

   [I-D.ietf-ecrit-phonebcp]
              Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in support of Emergency  Calling",
              draft-ietf-ecrit-phonebcp-01 (work in progress),
              March 2007.

   [I-D.ietf-ecrit-requirements]
              Schulzrinne, H. and R. Marshall, "Requirements for
              Emergency Context Resolution with Internet Technologies",
              draft-ietf-ecrit-requirements-13 (work in progress),
              March 2007.

   [I-D.ietf-ecrit-security-threats]
              Taylor, T., "Security Threats and Requirements for
              Emergency Call Marking and Mapping",
              draft-ietf-ecrit-security-threats-04 (work in progress),
              April 2007.

   [I-D.schulzrinne-location-hiding-requirements]
              Schulzrinne, H., "Location Hiding: Problem Statement and
              Requirements", July 2007.

   [I-D.barnes-geopriv-lo-sec]
              Barnes, R., "GEOPRIV Security Requirements", July 2007.

   [TS-24.229]
              "TS 24.229, 3rd Generation Partnership Project; Internet
              Protocol (IP) multimedia call control protocol based on
              Session Initiation Protocol (SIP) and Session Description
              Protocol (SDP); Stage 3, (Release 7)", June 2007.

   [TS-23.167]
              "TS 23.167, 3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; IP
              Multimedia Subsystem (IMS) emergency sessions (Release
              7)", June 2007.


Appendix A.  The 3GPP Emergency Services Architecture

   The description in this section re-uses terminology introduced in
   this document rather than using native 3GPP introduced terminology.

   The basic idea of the 3GPP emergency services architecture, based on



Tschofenig & Schulzrinne  Expires January 3, 2008              [Page 12]


Internet-Draft  Emergency Services Architecture Overview       July 2007


   [TS-24.229]/[TS-23.167], is shown in Figure 2 and is characterized by
   the difference that emergency services support is provided by the
   ISP/IAP (or a closely associated entity).  This has the following
   consequences:


   o  A SIP-based signaling profile needs to be standardized for
      interaction between the SIP UA and the SIP proxy in the ISP/IAP/
      visited VSP/ASP.  For the 3GPP emergency architecture IMS was
      chosen as the profile, i.e., a flavor of IETF SIP.  This exchange
      is shown in (1).

   o  The SIP proxy responsible for emergency call routing needs to
      determine location information of the end point.  Since the SIP
      proxy and the location server are both located in the ISP/IAP (or
      in a closely associated entity) local information, such as IP
      addresses, cell identifiers, MAC addresses or similar identifiers
      are sufficient.  Determining the address of the PSAP is also a
      local matter since there is a relationship between the ISP/IAP and
      the PSAP operator responsible for a specific geographic region.
      This exchange is shown in (2).

   o  To provide identity information for the emergency call to the PSAP
      operator it is necessary to interact with the user's home VSP/ASP
      (in the roaming case).  This is shown with the message interaction
      in (3).

   o  The interaction between the ISP/IAP/visited VSP/ASP and the PSAP
      operator is a national matter and is currently not specified.

   The obligations for the different parties are as follows:
   End Host:

      *  The end host needs to support the IMS-specific SIP profile.
         The detailed steps are described in Section 6.1 of [TS-23.167].
         End hosts that do not support this specific version of SIP
         (including the specific authentication mechanisms) cannot be
         supported.

      *  PIDF-LO [RFC4119] may need to be supported to allow the end
         host to attach GPS available location information.  Other
         location protocols, such as the Secure User Plane Location
         protocol (SUPL), may be needed in special cases.  See Section
         7.6 of [TS-23.167] for a detailed considerations on how to
         retrieve location information.






Tschofenig & Schulzrinne  Expires January 3, 2008              [Page 13]


Internet-Draft  Emergency Services Architecture Overview       July 2007


   ISP/IAP/visited VSP/ASP:

      *  The SIP proxy in the access network needs to understand the
         IMS-specific SIP profile and the protocols used for (2), (3)
         and (4), whereby (4) is not specified.  The detailed steps are
         described in Section 6.2.1, Section 6.2.2, 6.2.3 of
         [TS-23.167].  On a high-level basis, the responsibility is
         mainly to understand the SIP protocol (and the corresponding
         extensions), to determine the end host's location information,
         to perform the necessary interaction for verifying the
         emergency caller's identity via the interaction with the home
         VSP and finally to route the emergency call to the correct
         PSAP.

   Home VSP/ASP:

      *  The home VSP/ASP needs to provide SIP call back functionality
         and asserts the identity of the emergency caller.  A roaming
         agreement is assumed to be in place between the home and the
         visted VSP/ASP.  Note that the security mechanism used to
         authenticate the end host to the Home VSP needs to prevent the
         visited VSP from being able to later impersonate the user.
         Note that this authentication procedure is likely be done
         during the network access authentication procedure rather than
         during the SIP signaling exchange.

   PSAP:

      *  This protocol interaction is not specified but assumed to be
         based on SIP.





















Tschofenig & Schulzrinne  Expires January 3, 2008              [Page 14]


Internet-Draft  Emergency Services Architecture Overview       July 2007


              +---------------------------+
              |                           |
              | Emergency Network         |
              | Infrastructure            |
              |                           |
              | +----------+ +----------+ |
              | | PSAP     | | ESRP     | |
              | |          | |          | |
              | +----------+ +----------+ |
              +-------------^-------------+
                            |
                            | (4)
   +------------------------+-------+       +-----------------------+
   | ISP/IAP                |       |       | Home VSP/ASP          |
   | Visited VSP/ASP        |       |       |                       |
   |+----------+            v       |       |    +----------+       |
   || LCS      |  (2)  +----------+ |   (3) |    | Identity |       |
   ||          |<--+-->| ESRP /   |<+-----+-+--->| Provider |       |
   |+----------+   |   | SIP Proxy| |     | |    +----------+       |
   |+----------+   |   +----------+ |     | |    +----------+       |
   || Mapping  |<--+        ^       |     | |    | SIP      |       |
   || Database |            |       |     +-+--->| Proxy    |       |
   |+----------+            |       |       |    +----------+       |
   +------------------------+-------+       +-----------------------+
                            |
                            | (1)
                            |
                            |
                            v
                       +----------+
                       | End      |
                       | Host     |
                       +----------+

      Figure 2: Overview of the 3GPP Emergency Services Architecture


Authors' Addresses

   Hannes Tschofenig
   Nokia Siemens Networks
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.com




Tschofenig & Schulzrinne  Expires January 3, 2008              [Page 15]


Internet-Draft  Emergency Services Architecture Overview       July 2007


   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Phone: +1 212 939 7004
   Email: hgs+ecrit@cs.columbia.edu
   URI:   http://www.cs.columbia.edu









































Tschofenig & Schulzrinne  Expires January 3, 2008              [Page 16]


Internet-Draft  Emergency Services Architecture Overview       July 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).





Tschofenig & Schulzrinne  Expires January 3, 2008              [Page 17]