Internet Protocol-basedEmergency Services

Hannes Tschofenig112 Rescue Forum, 11th October 2012, Žilina, Slovakia

Agenda

• Background

• NG112

• Location

• Security

What is EENA?

EENA, the European Emergency Number Association, is a Brussels-based NGO set up in 1999 dedicated to promoting high-quality emergency services reached by the number 112 throughout the EU. EENA serves as a discussion platform for emergency services, public authorities, decision makers, associations and solution providers in view of improving emergency response in accordance with citizens’ requirements. EENA is also promoting the establishment of an efficient system for alerting citizens about imminent or developing emergencies.

The EENA memberships include 700 emergency services representatives from 43 European countries, 57 solution providers, 9 international associations/organisations as well as 25 Members of the European Parliament.

EENA Structure

112 ESSNEmergency Services and Authorities (700 members in September 2012)

MEPs 112 ChampionsMembers of the European Parliament

+

EENA Advisory BoardPrivate Companies, International Organisations and Associations

Network of ResearchersResearchers on emergency services issues

NG112 Committee 112 Operations Committee Legal Committee

• Transition to Internet Protocol-based communication infrastructure is progressing world-wide.• Operators develop migration plans

– For cost efficiency reasons it is not reasonable to maintain two infrastructures in parallel • Many vendors discontinue support for legacy equipment

• End users are more and more familiar with the (mobile) Internet.• New communication techniques emerge all the time.

– Think about social networking, smart phone applications, and VoIP/IM systems.Industry Trends

• "It's hard to imagine that airlines can send text messages if your flight is delayed, but you can't send a text message to 911 in an emergency." • He continues, "The unfortunate truth is that the capability of our emergency-response communications has not kept pace with commercial innovation, has not kept pace with what ordinary people now do every day with communications devices." FCC Chairman Julius Genachowski

August 2011

• They decided to work together to ensure every European can access a 112 smartphone app, in their own language.• This announcement was made on the European 112 day when surveys revealed that "74 % of Europeans don't know what emergency number to call when traveling in the EU". EC VPs Neelie Kroes & Siim Kallas

February 2012

NG112

Why do you want IP?

• There are four reasons:

1. Lower CAPEX: commodity nature and competition lowers prices

2. Lower OPEX compared to legacy infrastructure

3. Future proof technology: The rest of the industry is moving to IP.

4. More functionality (e.g., multi-media support, data sharing) and better extensibility.

• It’s just an IP network, nothing at all special about the network.– It’s private and managed but it is not a walled garden.– Redundant links for improved availability.

• Allow PSAPs to get VoIP calls from VSPs and data from location servers.

• Connect PSAPs among each other for overload situations.

• Sometimes integrated into a larger public safety network. E.g., Finland

Emergency Services IP network (ESInet)

EENA NG 112Overview

EENA NG 112Overview, cont.

• The scope of the specification • starts with the Border Control Function (a IP-based application

layer firewall) or legacy network gateway, and • ends with the PSAP.

• As such, the initial call routing to the edge of the ESINet has already happened.

• Additional call routing may happen within the ESINet and the specification describes this functionality. Examples: overload handling, bridging, routing based on call taker skills.

• ESINet operator relies on external input (e.g., location, emergency call).

• ESINet offers functions to external entities (e.g., routing information).

In March 2011 we published the Introduction to the European Next Generation 112

A requirements analysis for NG112 was conducted and matched against the service requirements developed by the operations committee.

Mid 2011 we did a poll in the NG112 TC on the next steps for the work on the technical architecture.

Group reinforced the desire to progress the work on the NG112 LTD document.

NG112 Long Term Definition

Background

NG1-1-2 meets Operational Requirements

1. Standards based approach1. Geo-Location conveyance

2. PSAP – interface

3. Call Routing

2. Multi-Media communications

with citizens

3. Emergency Services

Interoperability

NG1-1-2 LTD Scope

Q13: 98% yes Q8: 100% yes

Q5: 95% yes

Q9: 72% yes

Q4 : 97% yes

Q11: Avg. 3,65(1 = less important; 5 = very important)

EENA Survey 8/11

Survey can be found here: http://www.eena.org/ressource/static/files/2011_09_08_ng112opreqsurvey_v1.2.pdf

NG112 Long Definition Document

Document Objectives

• Define a long term architecture for European Emergency Services based on the i3 architecture

• i3 was developed by the National Emergency Number Association (NENA)• http://www.nena.org/

• Compatible with NENA i3• Compatible with European Emergency Services

organisations

• See also EENA publication about PSAP in Europe

Publication

Next Generation 112 Long Term Definition Document

• Final NG112 Long Term Definition document was approved by mid of April and officially published Link to the document

• A plenary session and a technical session were dedicated to this document during the EU Emergency Services Workshop 2012 in Riga (18-20 April).

Link to the plenary presentation

Link to the technical session presentation

• The document was also presented in the last Experts Group on Emergency Access (EGEA) meeting.

Link to the presentation

NG 112Overview, cont.

• If you do not want IP-based PSAPs then the NG 112 specification is not relevant for you.

• The NG112 specification helps you to deploy a system that • re-uses the work from various standards organizations

(e.g., 3GPP, IETF, OMA, OGC)• builds on IP, SIP & HTTP, • has gotten extensive reviews, and• lowers vendor lock-in.

Scope of EENA NG112

IP Phone

Smart Phone

DNS

WebServices

Cellular Phone

Location Information

Server MultimediaServices

ESRP

OriginatingBorder Control

Location ValidationWeb Interface

ESInet

Global Internet,Private Networks

or IMS

IP-based AccessNetworks

Software Clients on

Laptops, Desktops,

and Tablets

Instant Messaging

Clients

Legacy PSAP/Emergency Responders

Call Routing Server

GovernmentServices

SupplementalServices

Databases

IP-based PSAP

ESInet

Access NetworksCommunication Service

ProvidersEmergency Services IP Network (ESInet)

ESRPTerminating

Border Control

End Devices

Legacy Circuit-Switched Networks

PSTN Phone

Legacy PSAPGateway

E-CSCF(IMS)

LegacyNetworkGateway

ECRWeb

Interfaces

Private WebServices

IP-based PSAP

Emergency Call Routing &Location Validation

Databases

Copyright – Guy Caron (ENP)

Extensibility

Last Mile, Inc. (Internet Access Provider)

ISP, Inc. (Internet Service Provider)

VoIP, Inc. (Application Service Provider)Layer 7

Layer 1/2

Layer 3

End Host

Remember: Layering in the Internet Architecture

Interworking with other Systems

• Emergency services build on top of existing communication architectures.

• Standardized communication architectures are available with • SIP-based IMS (as defined by 3GPP)• SIP-based VoIP (as defined by IETF)• XMPP-based IM/VoIP (as defined by IETF & XSF)• RTCWeb (as currently work in progress by IETF &

W3C)• Also many non-standardized communication

architectures available (e.g., Skype, many Smart Phone Apps)

• http://www.amazon.com/SIP-Demystified-Gonzalo-Camarillo/dp/0071373403

• http://www.amazon.com/3G-IP-Multimedia-Subsystem-IMS/dp/0470516623

Are you familiar with SIP and IMS?

Interoperability

IP-based PSAPVSP

or Gateway

Emergency Call

Dial 1-1-2

Emergency Call

Skype, PSTN, eCall, Smart Phone App SIP based on NG112

Communication Architectures

Interoperability, cont.

• Three features have to be provided by a communication architecture in order to work (failure-free and robust) with the NG112 architecture:

(I) Ability to identifying an emergency call and to communicate the emergency call to the VSP.

(II) Ability to communicate location and/or a location key

(III) Ability to convey multi-media content (which is the actual emergency communication)

Location

Location

• Two types of usages:1. Location for routing of the call to the PSAP2. Location for dispatch of first responders.

• Requirements for the two vary considerably. • Two types of location formats:

• Civic Location Address• Geodetic Location Address

• Location encoding and formats had been standardized long before the EENA NG112 work started.

Location for Routing

Three approaches possible: (1) Use whatever you have and use it. (2) Use only those mechanisms that

always work. (3) Use no location: statically

provisioned routes

Location TechnologiesOverview

• User Provided• Example: User configures location with VSP when

registering for the service.

• Device-based • Example: GPS

• Network operator-based • Examples: ISP-operated location servers

• Third party services• Examples: WiFi SSID & Cell ID databases, IP-to-geolocation

databases

More detailed discussion about location technologies:http://www.eena.org/ressource/static/files/2011_05_27_2.2.2.cl_v1.3.pdf Subsequent pictures taken from Martin Dawson presentation: http://www.eena.org/ressource/static/files/commscope-eena-mobilelocation-april-2011.pdf

Difference in Location Technologies

Cell ID

Difference in Location Technologies

Enhanced Cell ID

Difference in Location Technologies

A-GPS

Call Routing

Emergency Call RoutingMain Options

I) End host driven Model • End host obtains location• End host triggers resolution (which also provides

information about the supported emergency services numbers)

II) Proxy driven Model• VSP obtains location• VSP determines ESRP/PSAP.

• Various variants possible and described later.

1. Calling device discovers the location server and gets location

2. Calling device discovers routing server and gets correct emergency service gateway address

3. Calling device address call to the emergency service gateway, includes location and sends to the voice provider.

4. Voice provider routes the call to the emergency service gateway

5. Emergency service gateway gets an updated location

6. Emergency service gateway uses the route server to get the correct PSAP to send the call to.

7. Emergency service gateway routes the call to the PSAP

8. PSAP gets an updated location if required.

Access Network

CommunicationNetwork

EmergencyNetwork

LocationServer

Caller

EmergencyServiceGateway

VoiceProvider

PSAP

RouteServer

1

2

3

4

56

7

8

Emergency Call RoutingDevice Centric Model

Emergency Call RoutingSwitch Centric Model

1. Caller makes a call2. Voice provider determines

correct LIS and requests location

3. Voice provider determines route server and requests a route to the emergency service gateway

4. Voice provider routes the call to the emergency service gateway including location.

5. Emergency service gateway gets an updated location

6. Emergency service gateway uses the route server to get the correct PSAP to send the call to.

7. Emergency service gateway routes the call to the PSAP

8. PSAP gets an updated location if required.

Access Network

CommunicationNetwork

EmergencyNetwork

LocationServer

Caller

EmergencyServiceGateway

VoiceProvider

PSAP

RouteServer

7

8

1

2

3

4

5

6

Emergency Call RoutingVariations

A) Single PSAP or PSAP operating for the entire country.

In this case the granularity of the location information only needs to be on a country level. This can easily provided by many of today’s location based services (e.g., IP-to-geolocation).

Example: UK

Emergency Call RoutingVariations, cont.

B) Emergency Services Routing Proxies (with many PSAPs per country)

Only country-level location granularity is needed to find one of the ESRPs. ESRPs can (automatically and without human involvement) retrieve more accurate location from ISPs/IAPs, when needed.

Example: Variation of the Swedish deployment. German eCall approach in HeERO project.

• Currently discussions ongoing in the ETSI M493 group on call routing architectures. • More details:

– http://www.112.be/ressource/static/files/m493_en.pdf– ”The objective of this Mandate is to stimulate further standardization work in this field to support harmonized European solutions also with regard to cost effective implementations.”

• My personal opinion: – Challenges are on the regulatory side (and not on the technical side).

Emergency Call RoutingStill work in progress

Security

• Approaching security follows a process:– 1. What are your threats?– 2. What security requirements can you derive from these threats?– 3. What ways to fulfill the security requirements do you have at your disposal?

• The EENA NG112 LTD document has an extension security chapter:– 15+ pages in Section 6

• The existence of malware botnets has to be considered as well. (not just a theoretical threat)

SecurityOverview

• Resource consumption at the PSAP based on false calls is one biggest security threats: – See also EENA publication on this topic:

http://www.eena.org/ressource/static/files/2011_03_15_3.1.2.fc_v1.0.pdf

• Many of the reasons for false calls cannot be “solved” via technical means only.

• Note: Problem is not unique to IP-based emergency services. Legacy networks also suffer from these problems.

SecurityFalse Calls

• Location is spoofable to a certain degree– Location configuration steps are vulnerable to

manipulation.– Particularly true for location determination

techniques that provide better location accuracy.

• Focusing only on network provided location rules out – many practical deployments, and – many high quality location techniques.

SecurityLocation Spoofing

• Before the Fact: Prevention or degradation– Example: Disallow SIM-less emergency calls

• Ongoing: Attribution as a part of normal activity– Example: Education about cost of emergency

services infrastructure.• During the Fact: Mitigation

– Example: Signal ‘false call’ warning to caller.• After the Fact: Retribution

– Example: Prosecute

SecurityWhen to react?

• Design for global interoperability to gain from the economic benefits and to better support citizens.– Consider how to interwork with out-of-country VSPs

• Location:– Participate in the ongoing EC location accuracy discussion.

• Routing:– Join the discussions at the EENA NG112 and the M493 group on

emergency call routing.• Security:

– A complex topic that requires more discussion. Help us to improve the state of the art

• The number of VoIP/Real-Time Text/Instant Messaging emergency calls will be low at the beginning.– Start early with a small deployment.

Conclusions