Emergency Services ECC TRIS Vienna, July 2004

1
Emergency ServicesECC TRISVienna, July 2004

• Richard Stastny, ÖFEG

The opinions expressed here may or may not be
that of my company
2
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.

3
Content

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

4
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
Frameworkhttp//europa.eu.int/information_society
/topics/ecomm/doc/useful_information/library/commi
ss_serv_doc/406_14_voip_consult_paper_v2_1.pdf
5
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.

6
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.

7
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.

8
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).

9
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.

10
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.

11
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, )

12
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

13
Statements

• The ability to call for help in times of an
  emergency is not voluntary its 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

14
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

15
Some work has already be done

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

16
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

17
Major topics

• Common URI for emergency calls sipsos_at_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

18
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

19
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 sipsos_at_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
  sipsos.fire_at_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

20
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

21
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)

22
How does the ECC find the callers 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)

23
Privacy and authentication

• Want to ensure privacy of call setup information
• prevent spoofing of call origins
• but cant 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

24
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
  dont reach call taker
• Also, DNS model allows external consistency
  checking
• e.g., nationwide 911 testing agency

25
How does VoIP (IPC) differ from landline and
wireless PSTN?

• Telephone companies are no longer needed
• there are still carriers for DSL and cable IP
  dial tone
• but unaware of type of data carried
• IPCSP may be in another state or country
• Corporations and universities dont have email
  carriers, either
• even residential users may have servers
• Addresses (Names) may be non-numeric (not E.164)
• Media is not necessarily voice

voice service provider (RTP)
Yahoo
Backbone (IP)
MCI
Access(WiFi
Starbucks
User
26
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

27
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

28
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

29
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.

30
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

31
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?

32
Stage 0
IPCSP need access to local gateway operators
Gateway Operator
DNS
Internet
PSAPs/ECCs
PSTN
IPCSPs
Terminal Adapter with FXO life-line
fixed users
nomadic users
33
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

34
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

35
Stage 1 direct
ECC looks up name and location information
ESRP
Gateway Operator
DNS
IPCSP
CLI presented to ECC
lookup ECC
Internet
PSAPs/ECCs
PSTN
location
Terminal Adapter with FXO life-line
36
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
  ND10132002/11

37
Stage 1 via IPCSP
lookup ECC
ECC looks up name and location information
ESRP
Gateway Operator
DNS
IPCSP
CLI presented to ECC
location and identity
Internet
PSAPs/ECCs
PSTN
location
Terminal Adapter with FXO life-line
38
Forward to foreign ESRP
ECC looks up name and location information
foreign ESRP
lookup ECC
DNS
Gateway Operator
home ESRP
CLI presented to ECC
Internet
PSAPs/ECCs
PSTN
location
Terminal Adapter with FXO life-line
39
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

40
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

41
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.

42
The End

• Thank you

Richard Stastny ÖFEG 43 664 420
4100 richard.stastny_at_oefeg.at