Emergency Services Telecom Policy Europe VON Europe 2004

1
Emergency ServicesTelecom Policy EuropeVON
Europe 2004

• Richard Stastny, ÖFEG

The opinions expressed here may or may not be
that of my company
2
The Major Problems in Europe with Emergency
Services

• Flawed definition concerning access to Emergency
  Services in the Universal Service Directive
• No common approach within Europe for emergency
  services, regarding
• architecture
• technology
• requirements
• administration
• Lack of co-ordination, in some cases even on
  national basis and between different emergency
  response organizations

3
Publicly available telephone service (PATS)

• A service available to the public for
  originating and receiving national and
  international calls and access to emergency
  services through a number or numbers in a
  national or international telephone numbering
  plan,
• and in addition may, where relevant, include one
  or more of the following services the provision
  of operator assistance, directory enquiry
  services, directories, provision of public pay
  phones, provision of service under special terms,
  provision of special facilities for customers
  with disabilities or with special social needs
  and/or the provision of non-geographic services

• This definition is flawed, some say
• if you do not provide access to emergency
  services, you are not PATS
• if you provide access, you are PATS

This leads to
4
e.g. the UK OFCOM View

• In Questions and Answers on Voice over IP and
  Voice over Broadband services
• 10. Can VoIP services offer best efforts 999
  access without having to comply with all the
  conditions that apply to PATS services?
• In the forthcoming consultation document Ofcom
  also proposes to consult on whether it is
  desirable for providers of non-PATS VoB services
  to offer best efforts 999 access rather than
  none at all. Best efforts in this context means
  offering 999 access in the knowledge that VoIP
  services may not be sufficiently robust to
  guarantee instant or uninterrupted access to 999.
• Ofcoms interim position is that services that
  match the PATS definition (i.e. those which offer
  any access to emergency organisations), would be
  PATS and hence be regulated as such.

5
Quackphones

• If it looks like a duck, quacks like a duck, it
  is a duck.

So are these phones or ducks?
6
leads to the result

• that many providers are NOT providing access to
  emergency services, just to avoid being regulated
  like PATS

7
BUT

• a flawed (best-effort) access to emergency
  services is better than none
• new technologies should be given some time to
  evolve
• mobile services (quod licet jovi, not licet
  bovi?)
• because they may finally provide better services
  then currently available and possible

8
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

9
Ok, we can do better and faster

• Hopefully in less then 10 years

So what are the basic requirements?
10
The basic Emergency Call Problems

• Determine a call is an emergency call
• 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
• Provide caller identity
• Guaranty ECC reachability

11
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

12
Major topics
See presentation of Brian Rosen

• 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

13
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

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

15
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
16
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

17
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
  temporary (virtual) 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

18
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
19
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
20
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
21
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

22
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

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

24
The End

• Thank you

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