Emergency Services

Document Sample
Emergency Services Powered By Docstoc
					                Emergency Services
                             ECC TRIS
                         Vienna, July 2004


                 Richard Stastny, ÖFEG*


   * The opinions expressed here may or may not be that of my company



July 2004                    Richard Stastny                     1
Introduction


   • The discussion in Europe on the treatment of
     Emergency Services with VoIP started:
        – with the Analysys Report to the EC, regarding access to ES
          and PATS
        – the activities in the US between IETF, NENA and the VON
          Coalition
   • One of the major issues is the provision of location
     information of the caller to be used for call routing and
     also to be displayed at the PSAP.
   • On the other hand a lot has been undertaken already in
     Europe, US and Japan to provide enhanced location
     information to PSAPs for calls from mobile phones
   • Many solutions proposed and implemented could be re-
     used also for calls from VoIP.




July 2004                     Richard Stastny                          2
Content


   •   Regulatory Status in Europe
   •   Basic Emergency Call Problems
   •   Work at IETF
   •   Major topics
   •   Emergency Services Obligations
   •   Proposal for a staged approach




July 2004            Richard Stastny    3
EU Position on Emergency Services*

   • Access to Emergency services is extremely important for
     citizens, irrespective of how a telephone service may be
     classified for legal and regulatory purposes.
   • The Universal Service Directive has an explicit requirement
     that access to emergency services has to be offered by
     providers of PATS, but there is no similarly explicit obligation
     for providers of ECS who may be offering a telephone service.
   • From a public policy point of view it is desirable that
     access to emergency services is available from as wide
     a range of electronic communications services as
     possible.
   • This calls for an evolutionary approach in cooperation with the
     emergency authorities.
   • In principle, National Regulatory Authorities could
     impose an obligation on certain „non-PATS‟ service
     providers to offer emergency service access, under
     Condition (8) of Annex A of the Authorisation Directive
     on “Consumer Protection Rules specific to the
     electronic communications sector”.

            * The Treatment of VoIP under the EU Regulatory Framework
            http://europa.eu.int/information_society/topics/ecomm/doc/useful_information/library/com
            miss_serv_doc/406_14_voip_consult_paper_v2_1.pdf

July 2004                            Richard Stastny                                            4
Proposal of consulation paper


   • However the practicalities of call routing and handling
     have not yet been resolved by the market, and until
     they are, such an obligation may not be technically
     feasible and could be disproportionate.
   • It is proposed that:
        – NRAs could require suppliers of VoIP services that include
          access to the public telephone network to give precise
          information to customers on how the VoIP supplier deals
          with access to emergency services and caller location.
        – Such information should be provided in the customer
          contract drawn up in accordance with Article 20 of the
          Universal Service Directive.
   • The Commission will regularly review evolution in this
     area.




July 2004                     Richard Stastny                          5
… on Routing of Emergency Calls


   • The possibility to route a call to the nearest Emergency
     Service centre implies that the service provider (either
     publicly available ECS or PATS) has sufficient
     information to allow the call to be correctly routed.
   • This is only possible if the location of the user making
     the emergency call is known in some way or another,
     and the service provider knows the nearest emergency
     service centre to which the call should be routed.
   • Currently, with some VoIP based services, in particular
     „nomadic‟ services, the VoIP service provider has no
     knowledge of the physical location of the caller nor of
     the nearest emergency service centre.
   • It would be disproportionate at the present stage of
     market development to impose such routing obligations
     on all VoIP providers.



July 2004                 Richard Stastny                       6
… on PATS and PAECS


   • in the case of PATS,
        – the actual making of an emergency call, and the
          provision of caller location information to emergency
          services, should be possible without the user having
          to input any location information either before
          making the emergency call or when initially installing
          the terminal device.
        – This probably means that the provider of such
          service needs to conclude some agreement
          with the provider of the underlying transport
          infrastructure (!)
   • in the case of publicly available ECS,
        – NRAs could require that the making of a call to the
          emergency services happens without the user having
          to provide any location information.
        – The user may be invited to provide location
          information when initially installing the terminal
          device at a particular location.

July 2004                   Richard Stastny                        7
… expects solutions from market players


   • At the current state of the market, it is advisable not to
     present an undue burden on market players, but it will
     be necessary to follow developments in this area closely
     as the market evolves.
   • In the case of those ECS and PATS services where users
     have the possibility to move their terminal, and where
     this causes a problem for the undertaking to determine
     the users‟ location, users need to be warned that when
     moving their terminals from agreed fixed location, they
     can not be guaranteed to be provided with emergency
     services.
   • Market players offering VoIP based services are
     encouraged to devise and rapidly implement
     operational solutions for the effective handling of
     calls to emergency services (ok, will do).



July 2004                  Richard Stastny                        8
… on Caller Location

   • In the context of PATS, Member States are to ensure
     that undertakings that operate public telephone
     networks make caller location information available to
     authorities handling emergencies for calls to the
     European Emergency call number „112‟.
   • In the Directives the provision of this location
     information is made dependant of the technical
     feasibility.
   • Considering the importance of providing location
     information it is proposed that:
        – NRAs encourage all undertakings offering PATS at fixed
          locations to provide location information.
        – This may imply some form of agreement between the
          operator offering the PATS service and the underlying
          provider of the transport infrastructure.
   • The Privacy Directive foresees that, where Calling-Line
     Identification is offered, an undertaking may override a
     users‟ elimination of the presentation of this CLI, for
     calls to organisations dealing with emergency calls.

July 2004                     Richard Stastny                      9
… on Caller Location (cont.)


   • Given the importance for emergency services
     of both the location and CLI information,
     Member States should encourage the provision
     of this information, both for PATS and for
     publicly available ECS.
   • Market players offering VoIP based
     services are encouraged to devise and
     rapidly implement operational solutions
     for the effective transmission of caller ID
     and the provision of location information
     for calls to emergency services
   • The Commission will regularly review evolution
     in this area.


July 2004             Richard Stastny                 10
Or in other words


   • a flawed (best-effort) access to emergency
     services is better than none
   • new technologies should be given some time
     to evolve
        – e.g. mobile services took more than 10 years*
   • because they may finally provide better
     services then currently available and possible
   • much of the work done already for
     providing caller location to PSAPs for
     E112 could also be used for VoIP
     (databases, interfaces, …)


July 2004                  Richard Stastny                11
Status of mobile networks

   • Mobile phones have no power supply
   • Reachability of emergency services is
     not guarantied
   • Ok, could route the call to the correct
     ECC, but:
   • No location information for 10 years
   • No identification for SIM-less calls (on
     the contrary, this is a requirement)
   • 200.000.000 pre-paid cards out in
     Europe without identification

July 2004            Richard Stastny            12
Statements


   • “The ability to call for help in times of
     an emergency is not „voluntary‟ – it‟s
     mandatory.”
        – David F. Jones, VP NENA (Testimony at the
          FCC Hearing)
   • “The use of IP protocols could provide
     the emergency systems with …
     expanded services, more resilient
     networks and faster response times“
        – Henning Schulzrinne



July 2004               Richard Stastny               13
The basic Emergency Call Problems


   • Determine a call is an emergency call
   • 4 basic requirements:
        – Locate the caller
        – Route the call to the correct ECC (PSAP)
        – Include the location of the caller so help can be
          dispatched to the right place
        – Include a way to call back if disconnected
   • In addition:
        – Provide caller identity
        – Guaranty ECC (PSAP) reachability



July 2004                     Richard Stastny                 14
Some work has already be done


   • IETF
   • US
        – E911 (NENA, APCO, VON Coalition, …)
   • Europe
        – E112 (CGALIES, LOCUS, ETSI, LIF, …)
        – UK (EISEC)
        –…




July 2004              Richard Stastny          15
Current IETF drafts


   • draft-taylor-sipping-emerg-scen-01
        – scenarios, e.g., hybrid VoIP-PSTN
   • draft-schulzrinne-sipping-emergency-arch-00
        – overall architecture for emergency calling
   • draft-ietf-sipping-sos-00
        – describes „sos‟ SIP URI
   • draft-rosen-dns-sos-00
        – new DNS resource records for location mapping



July 2004                 Richard Stastny                 16
Major topics


   • Common URI for emergency calls
     sip:sos@home.domain (and 112 and 911)
   • Use the global DNS to store information on
     emergency numbers, ESRP, ECC service areas
   • Use different means to retrieve location
     information (DHCP, GPS, RFID, GSM, …)
   • Push location information to ECC or let ECC
     subscribe to location information
   • Use authentication and TLS during call setup
   • For more info see presentations of Brian Rosen
     and the current work of IETF


July 2004             Richard Stastny                 17
Architectural assumptions and goals by
IETF


   • SIP-based for interchange
   • International (global)
        – devices bought anywhere can make emergency calls
          anywhere
        – limit biases in address formats, languages, …
        – avoid built-in bias for “911” or “112” (mostly)
   • Support other communications modes
        – IM, SMS, MMS, video, email
   • Support access for callers with disabilities
        – real-time text
        – video for sign language



July 2004                   Richard Stastny                  18
Common URL for emergency services

   • Emergency numbers may be dialed from many different
     places
        – about 60 (national) different emergency service numbers in the
          world
        – many are used for other services elsewhere (e.g., directory
          assistance)
   • IETF draft suggests “sip:sos@home-domain”
        – home-domain: domain of caller
   • Can be recognized by proxies along the way
        – short cut to emergency infrastructure
   • If not, it reaches home proxy of subscriber
   • Call can be routed from there easily
        – global access to routing information (see later)
   • allows also service identification “sip:sos.fire@home-domain”
   • 112 and 911 should always be available (VoIP dialing plans
     needed)
   • Default configuration if no other information available:
        – 000, 08, 110, 999, 118 and 119
        – needs definitely further study



July 2004                        Richard Stastny                           19
Using the global DNS


   • Emergency number configuration
   • Determining the PSAP/ECC where the
     call should be routed to
   • service area of PSAP/ECC
   • new infrastructure domain sos.arpa
     proposed




July 2004         Richard Stastny         20
Determining locations

   • Either network-provided or terminal-provided
   • Conveyed via DHCP from IP-level provider
        – Formats:
            • geospatial (longitude, latitude, altitude or floor)
            • civil (country, administrative units, street)
        – Provider usually knows
        – Does not depend on being a voice service provider
   •   802.11 triangulation
   •   GPS (for ALL mobile devices)
   •   RFID tags in rooms
   •   Via configuration protocol (XCAP)
        – relies on VSP having accurate service location
          information
   • User-configured (last resort)


July 2004                       Richard Stastny                     21
How does the ECC find the caller‟s
location?

   • Largest difference to existing E911 system
   • In-band, as part of call setup
        – carried in body of setup message
        – rather than by reference into external database
   • May be updated during call
        – moving vehicles
        – late availability of information (GPS acquisition
          delay)
   • Also possible: subscribe to location
     information (proposed method – see below)




July 2004                    Richard Stastny                  22
Privacy and authentication


   • Want to ensure privacy of call setup
     information
   • prevent spoofing of call origins
        – but can‟t enforce call authentication
   • need to authenticate call destination
        – ideally, certificate for ECCs
        – but initially just verify that reached DNS-indicated
          destination
   • use TLS (SSL), as in https://
   • host certificates widely available
        – just need a domain name and a credit card




July 2004                    Richard Stastny                     23
Testing emergency calls


   • Current E911 system has no good way
     to test 911 reachability without
     interfering with emergency services
   • With VoIP, more distributed systems 
     more need for testing
   • Use SIP OPTIONS request  route
     request, but don‟t reach call taker
   • Also, DNS model allows external
     consistency checking
        – e.g., nationwide 911 testing agency



July 2004               Richard Stastny         24
How does VoIP (IPC) differ from
landline and wireless PSTN?

   • Telephone companies are no longer
     needed
        – there are still carriers for DSL and




                                                 Yahoo
          cable “IP dial tone”                               voice service provider
        – but unaware of type of data carried                       (RTP)
        – IPCSP may be in another state or
          country
        – Corporations and universities don‟t                    Backbone




                                                 MCI
          have email carriers, either                              (IP)
        – even residential users may have
          servers
   • Addresses (Names) may be non-




                                                 Starbucks
                                                                   Access
     numeric (not E.164)
                                                                    (WiFi
   • Media is not necessarily voice


                                                                     User



July 2004                     Richard Stastny                                         25
Take away messages


   • Phones (terminals) must change
        –   Learn location (GPS, DHCP,..)
        –   Learn local emergency number from DNS
        –   Recognize emergency call
        –   Include location on the emergency call
   • Proxy servers must change
        – Recognize emergency call
        – Route to ECC based on location (using DNS)
   • All elements must implement sips: (TLS)
   • ISPs must implement DHCP location




July 2004                   Richard Stastny            26
Emergency Services Obligations


   • Currently telephony service providers have
     obligations regarding emergency services
   • This should be reconsidered with VoIP
     (IP Communications in general) and
     especially if Broadband may be
     considered as the Universal Service of the
     future
        – In this case contact to emergency services could also
          be multimedia and made in addition to voice also by
          messaging, video and even via a web browser
        – depending on terminal capabilities




July 2004                   Richard Stastny                       27
There will be obligations to

   • terminal providers:
        – to receive, store and forward location information (GPS)
   • access providers, ISPs and enterprises:
        – to provide location information via DHCP and/or other
          means (mobile)
   • operating systems and application SW:
        – to provide minimum set of capabilities and recognize
          emergency requests (sos in browser?)
   • building infrastructure:
        – to provide RFIDs in rooms
   • DNS infrastructure (sos.arpa.):
        – to provide ECC/PSAP locations and emergency numbers
   • communications service providers:
        – to handle and route emergency calls properly
   • emergency routing proxies
        – to feed location databases, provide pseudo CLIs, route
          calls to ECC/PSAPs or other ESRP.
   • ECC/PSAPs:
        – be able to use information provided

July 2004                     Richard Stastny                        28
How location information is retrieved


   • All location information is gathered by the
     terminal
   • either network provided
        – DHCP
        – Mobile triangulation
        – WiFi triangulation
   • or by the terminal itself
        – From the user
        – Via GPS
        – Via RFID
   • and transmitted in an emergency call at call
     setup (INVITE) or during the call (NOTIFY)
   • together with the location information also the
     source is transmitted, multiple information is
     possible.
July 2004                   Richard Stastny            29
Proposal for a staged approach

     to access emergency services from IP-
     based networks

 0. the existing situation
 1. from the Internet via VoIP to PSAPs/ECCs on
    the PSTN/ISDN with enhancements
 2. from the Internet to PSAPs/ECCs also
    connected to the Internet using IPC
 3. both PSAP/ECC and User are using NGN



July 2004           Richard Stastny           30
Stage 0

 • No problem for VoIP provided at a fixed location using
   geographic numbers or for users with FXO life-line
 • For nomadic users:
    – Emergency calls always routed to home PSAP/ECC for a
      given subscriber or
    – emergency calls only possible if location is provided to
      VoIP SP manually, but
            • how can this information be provided to PSAP/ECC in time?
      – recognition by PSAP/ECC via CLI of non-geographic
        number
            • better then nothing
            • but problem of call routing to correct PSAP/ECC still exists
 • No access to emergency services for IP-only providers with
   no E.164 number?



July 2004                        Richard Stastny                             31
 Stage 0


                                IPCSP need access to local gateway operators
                                              Gateway
                    DNS
                                              Operator


                      Internet                                           PSAPs/
IPCSPs                                                          PSTN
                                                                          ECCs



                                           Terminal Adapter
                                           with FXO life-line



    nomadic users         fixed users

 July 2004                        Richard Stastny                              32
Proposed Architecture Stage 1

   • PSAPs/ECC still on PSTN, using existing technology
   • All emergency calls are routed via the (Home)
     Emergency Service Routing Proxy (ESRP)
   • Users may subscribe directly, giving his
     preferences
        – in this case the ESRP is also a SIP- and presence server
   • Subscriber needs to identify himself at subscription
     time
   • ESRP guaranties the subscriber to disclose identity
     and location information only to emergency
     services (or on user push)
   • ESRP implements the local (national) policy



July 2004                    Richard Stastny                         33
Stage 1 (cont.)
   • Location information is either entered manually by user
     or transmitted from the device
   • ESRP is able to map location information to routing
     information to proper PSAP/ECC by using local
     databases or the DNS
   • ESRP is able to provide PSAP/ECC with screened CLI
   • For calls from users without E.164 number a pseudo
     number (CLI) may be set up
   • PSAPs/ECCs need only to have narrow-band Internet
     access to retrieve the presence information indexed by
     CLI (watcher)
   • If location of user is out-side of ESRP boundary, the call
     may be routed easily (and trusted) to other ESRPs
   • These ESRP may be found via sos.arpa
   • Devices or applications need to be able to support more
     then one line – indication of availability of ES
     recommended
July 2004                   Richard Stastny                       34
Stage 1 direct


                              ECC looks up name and location information
                       ESRP
                                         Gateway
            DNS
                                         Operator
   IPCSP
                                               CLI presented to ECC
              lookup ECC
              Internet                                                PSAPs/
                                                           PSTN
                                                                       ECCs

                  location
                                      Terminal Adapter
                                      with FXO life-line




July 2004                    Richard Stastny                               35
Usage of existing databases


   • If a database for providing location
     information for fixed and mobile calls is
     already existing
   • this database and the related interfaces
     may be used for VoIP too
   • e.g. in UK
        – Enhanced Information Service for
          Emergency Calls (EISEC SIN 278) and
        – Emergency Location Information Interface
          ND1013:2002/11



July 2004               Richard Stastny              36
Stage 1 via IPCSP


            lookup ECC                 ECC looks up name and location information
                           ESRP
                                          Gateway
               DNS
                                          Operator
   IPCSP
            location and                        CLI presented to ECC
              identity
                   Internet                                              PSAPs/
                                                            PSTN
                                                                          ECCs

location
                                       Terminal Adapter
                                       with FXO life-line




July 2004                     Richard Stastny                                  37
Forward to foreign ESRP


                                         ECC looks up name and location information
                          foreign
      lookup ECC
                   DNS     ESRP              Gateway
   home                                      Operator
   ESRP                                            CLI presented to ECC

                   Internet                                                 PSAPs/
                                                               PSTN
                                                                             ECCs

                      location
                                          Terminal Adapter
                                          with FXO life-line




July 2004                        Richard Stastny                                 38
Advantages of this approach

   • IPCSP need not to be involved in
     emergency services
   • Users may not trust IPCSP regarding
     identity and location information
   • Reachability of ES may be better
     guarantied
   • No E.164 number required
   • Identity also possible with prepaid services
   • Global connectivity achieved more easily
   • Implementation of local policies possible
   • Call back to contact address possible

July 2004             Richard Stastny               39
Migration to Stage 2


   • No or minor changes required in ESRP
   • If PSAP/ECC decides to migrate to VoIP,
     calls are not routed via the gateway,
     but directly to the SIP-server of the
     PSAP/ECC
   • Name and location information will be
     transmitted directly
   • Location information may be dispatched
     directly to emergency vehicles


July 2004           Richard Stastny            40
Stage 3


   • Left to ETSI and EMTEL
   • Stage 3 would be the full support of
     emergency services in NGN
     environments for which various work
     items have been opened. ETSI needs to
     ensure that they are aligned with NENA
     for this future network scenario.




July 2004          Richard Stastny            41
The End



              Thank you

             Richard Stastny
                      ÖFEG
              +43 664 420 4100
            richard.stastny@oefeg.at




July 2004          Richard Stastny     42

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:12
posted:7/26/2011
language:English
pages:42