NextGeneration Emergency Calling NG 911 Henning Schulzrinne Dept

Next-Generation Emergency Calling (NG 911) Henning Schulzrinne Dept. of Computer Science, Columbia University, New York hgs@cs. columbia. edu (with Jong Yul Kim, Wonsang Song, Anshuman Rawat, Matthew Mintz-Habib, Amrita Rajagopal and Xiaotao Wu; Lo. ST is joint work with Hannes Tschofenig, Andrew Newton and Ted Hardie) SIP Workshop April 25, 2008 April 2008

Outline emergency call alert coordination • Emergency calling – the challenge of two transitions: mobility and Vo. IP – Emergency alerts • Emergency alerting – beyond siren replacement • Emergency coordination – going beyond ad hoc networks April 2008 2

Modes of emergency communications emergency call information “I-am-alive” emergency alert (“inverse 911”) dispatch civic coordination April 2008 3

Background on 9 -1 -1 • Established in Feb. 1968 – – 1970 s: selective call routing late 1990 s: 93% of population/96% of area covered by 9 -1 -1 95% of 9 -1 -1 is Enhanced 9 -1 -1 US and Canada • Roughly 200 mio. calls a year (6 calls/second) – 1/3 wireless • 6146 PSAPs in 3135 counties – most are small (2 -6 call takers) – 83. 1% of population have some Phase II (April 2007) • “ 12 -15 million households will be using Vo. IP as either primary or secondary line by end of 2008” (NENA) April 2008 http: //www. nena. org/ 4

Local Switch Automatic Number Identification Automatic Location Identification April 2008 Collaboration between local phone providers and local public safety agencies 5

Why is this a hard problem? • More than just installing software and buying new PCs – mapping (GIS systems can’t use Google Maps) – training • Decentralized system – 6000+ PSAPs – estimated cost of upgrade: $340 m (=> $57, 000/PSAP) • 233 million US mobile phone subscribers • Cost-plus ILEC MSAG – – • the MSAG update protocol: fax no incentive to upgrade no incentive to cooperate with CLECs and VSPs unclear ownership of database Issues of control and “turf” – consolidation • efficiency vs. local knowledge – funding: state vs. county vs. town (volunteer fire department) April 2008 6

What makes Vo. IP 112/911 hard? POTS PSTN-emulation Vo. IP (landline) phone number limited to limited area landline phone number no phone number or anywhere in US (cf. phone number German 180) anywhere around the world regional carrier national or continentwide carrier enterprise “carrier” or anybody with a peer-to -peer device voice provider = line provider (~ business relationship) voice provider ≠ ISP national protocols and call routing probably North America + EU international protocols and routing location = line location mostly residential or small business stationary, nomadic, wireless April 2008 end-to-end Vo. IP 7

More than pain… • Multimedia from the caller – video capture from cell phones – video for sign language – text messaging and real-time text for the deaf • Data delivery – caller data: floor plan, hazmat data, medical alerts – measurement data input: automobile crash data, EKGs, … • Delivering video to the caller – e. g. , CPR training • Load balancing and redundancy – currently only limited secondary PSAP – Vo. IP can transfer overload calls anywhere • Location delivery – carry location with forwarded and transferred calls – multiple location objects (civic + geo) April 2008 8

Four Phases of Emergency Calls Phase 1 April 2008 Phase 2 Phase 3 Phase 4 9

Emergency numbers • Each country and region has their own – subject to change • Want to enable – traveler to use familiar home number – good samaritan to pick up cell phone • Some 3/4 -digit numbers are used for non-emergency purposes (e. g. , directory assistance) April 2008 Emergency number 10

Service URN • Idea: Identifiers to denote emergency calls – and other generic (communication) services • Described in IETF ECRIT draft-ietf-ecrit-service-urn • Emergency service identifiers: sos General emergency services sos. animal-control Animal control sos. fire Fire service sos. gas Gas leaks and gas emergencies sos. marine Maritime search and rescue sos. mountain Mountain rescue sos. physician Physician referral service sos. poison Poison control center sos. police Police, law enforcement April 2008 11

Services under discussion • “ 211” (social service referral), “ 311” (non-emergency government services) • Emergency services (first responders) – used by PSAP, not civilians – e. g. , urn: service: es: police • Non-emergency commercial services – urn: service: restaurant. italian – urn: service: transportation. taxi April 2008 12

Location, location, . . . Voice Service Provider (VSP) sees emergency call but does not know caller location ISP/IAP knows user location but does not handle call April 2008 13

Location determination options Method CDP or LLDPMED DHCP HELD GPS manual entry Layer L 2 L 3 L 7 (HTTP) - user advantages • simple to implement • built into switch • direct port/room mapping • simple to implement • network locality • traverses NATs • can be operated by L 2 provider • accurate • mobile devices • no carrier cooperation • no infrastructure changes • no carrier cooperation problems may be hard to automate for large enterprises mapping MAC address to location? mapping IP address to switch port? • indoor coverage • acquisition time • fails for mobile devices • unreliable for nomadic Use Ethernet LANs Enterprise LANs Some ISPs DSL, cable mobile devices fall back April 2008 14

Components of NG 911 system • • Location determination Call identification --> service URNs Call routing --> Lo. ST PSAP functionality – IVR, logging, multimedia conferencing, … Lo. ST (public) Lo. ST (private) ESN (county, state, …) Internet April 2008 PSAP 15

UA recognition & UA resolution location information mapping DHCP LLDP-MED 9 -1 -1 (dial string) INVITE urn: service: sos To: urn: service: sos Route: sip: psap@leonianj. gov <location> April 2008 leonianj. gov identification TBD mapping may recurse INVITE urn: service: sos To: urn: service: sos Route: sip: fire@leonianj. gov <location> 16

Lo. ST: A Protocol for Mapping Geographic Locations to Public Safety Answering Points Henning Schulzrinne, Hannes Tschofenig, Andrew Newton, Ted Hardie April 2008

Problem: Finding the correct PSAP • Which PSAP should the e-call go to? – – April 2008 Usually to the PSAP that serves the geographic area Sometimes to a backup PSAP If no location, then ‘default’ PSAP solved by Lo. ST 21

Lo. ST functionality • Mapping of location to parameters (e. g. , URL) • Civic as well as geospatial queries – civic address validation • Recursive and iterative resolution • Pre-querying and caching for efficiency and robustness – query ahead of emergency call (e. g. , at boot time for stationary devices) – no re-querying while moving • Fully distributed and hierarchical deployment – can be split by any geographic or civic boundary – same civic region can span multiple Lo. ST servers • Indicates errors in civic location data debugging – but provides best-effort resolution • Supports overlapping service regions – e. g. , contested regions (Kashmir, Palestine, Taiwan, . . . ) April 2008 22

Lo. ST: Location-to-URL Mapping VSP 1 cluster serving VSP 1 replicate root information cluster serves VSP 2 123 Broad Ave Leonia Bergen County NJ US Lo. ST NJ US sip: psap@leonianj. gov root NY US nodes search referral Bergen County NJ US Leonia NJ US April 2008 23

Lo. ST Architecture G tree guide G G G T 1: . us G broadcast (gossip) T 2: . de resolver seeker 313 Westview Leonia, NJ US T 2 T 1 April 2008 (. us) (. de) T 3 (. dk) Leonia, NJ sip: psap@leonianj. gov 24

Lo. ST Properties • Minimizes round trips: – caching individual mappings – returns coverage regions (“hinting”) • civic (“all of C=US, A 1=NY”) or geo (polygon) • Facilitates reuse of Transport Layer Security (TLS) • Returns emergency service numbers for a region • Query for supported Service URN types April 2008 25

Lo. ST: Query example • Uses HTTP or HTTPS <find. Service xmlns="urn: …: lost 1” recursive="true" service. Boundary="value"> <location profile="basic-civic"> <civic. Address> <country>Germany</country> <A 1>Bavaria</A 1> <A 3>Munich</A 3> <A 6>Neu Perlach</A 6> <HNO>96</HNO> </civic. Address> </location> <service>urn: service: sos. police</service> </find. Service> April 2008 26

Lo. ST “Find Service” response/warning example <find. Service. Response xmlns="urn: ietf: params: xml: ns: lost 1"> <mapping expires=“ 1990 -12 -31 T 23: 59: 60 Z” last. Updated=“ 2006 -11 -01 T 01: 00 Z”> <display. Name xml: lang="de">München Polizei-Abteilung</display. Name> <service>urn: service: sos. police</service> <service. Boundary profile=”civic”> <civic. Address xmlns="urn: ietf: params: xml: ns: pidf: geopriv 10: civic. Addr"> <country>Germany</country> <A 1>Bavaria</A 1><A 3>Munich</A 3><PC>81675</PC> </civic. Address> </service. Boundary> <uri>sip: munich-police@example. com</uri> <service. Number>110</service. Number> </mapping> <path> <via source=“lost: esgw. uber-110. de. example”/> <via source=“lost: polizei. munchen. de. example”> </path> </find. Service. Response> April 2008 27

Validation • Determine if civic location is (partially) valid • Returns XML tag names of components: – validated and used for mapping – no attempt to validate (and not used) • e. g. , house number – known to be invalid • Return (default) PSAP based on validated elements • May return list of guesses for correct addresses, if requested <location. Validation> <valid>country A 1 A 3 A 6</valid> <invalid>PC</invalid> </location. Validation> April 2008 28

Advanced Lo. ST functionality • Get list of (emergency) services supported – by server – for a region • Obtain service regions – identified by globally-unique tag <list. Services. By. Location> <location profile="geodetic-2 d"> <p 2: Point srs. Name="urn: 4326"> <p 2: pos>-34. 407 150. 883</p 2: pos> </p 2: Point> </location> <service>urn: service: sos</service> </list. Services. By. Location> April 2008 <list. Services. By. Location. Response> <service. List> urn: service: sos. ambulance urn: service: sos. animal-control </service. List> <path> <via source="auth. example"/> <via source="res. example"/> </path> </list. Services. By. Location. Response> 29

SIP message for Location Info. INVITE urn: service: sos SIP/2. 0 To: urn: service: sos Call-ID: 763782461@192. 168. 1. 106 Via: SIP/2. 0/TCP 192. 168. 1. 106: 4064; rport Content-Type: multipart/mixed; boundary From: sip: caller@irt. cs. columbia. edu Contact: <sip: eddie@160. 39. 54. 70: 5060> CSeq: 1 INVITE Content-Length: 1379 request line header fields ------ =_ZGY 1 NTFl. ZDJk. MDkx. Y 2 Fk. MTIx. MWI 2 Mz. Iz. Nj. E 1 M 2 U 0 OTY= MIME-Version: 1. 0 content-Type: application/sdp Content-Transfer-Encoding: 8 bit v=0 o=eddie 1127764654 IN IP 4 192. 168. 1. 106 s=SIPC Call c=IN IP 4 160. 39. 54. 70 t=0 0 m=audio 10000 RTP/AVP 0 3 m=video 20000 RTP 31 SDP April 2008 ------- =_ZGY 1 NTFl. ZDJk. MDkx. Y 2 Fk. MTIx. MWI 2 Mz. Iz. Nj. E 1 M 2 U 0 OTY= MIME-Version: 1. 0 Content-Type: application/pidf+xml Content-Transfer-Encoding: 8 bit <? xml version="1. 0" encoding="ISO-8859 -1"? > <presence xmlns="urn: ietf: params: xml: ns: pidf" xmlns: gp="urn: ietf: params: xml: ns: pidf: geopriv 10" xmlns: cl=" urn: ietf: params: xml: ns: pidf: geopriv 10: civil. Loc" xmlns: gml="urn: opengis: specification: gml: schema-xsd: feature: v 3. 0" entity="sip: calltaker_ny 2@irt. cs. columbia. edu"> <tuple id="28185"> <status> <gp: geopriv> <gp: location-info> <cl: civil. Address> <cl: country>us</cl: country> <cl: A 1>ny</cl: A 1> <cl: A 2>new york</cl: A 2> <cl: A 3>new york</cl: A 3> <cl: A 6>amsterdam</cl: A 6> <cl: HNO>1214</cl: HNO> </cl: civil. Address> </gp: location-info> <gp: method>Manual</gp: method> </gp: geopriv> </status> <contact priority="0. 8">sip: eddie@160. 39. 54. 70: 5060</contact> <timestamp>2005 -09 -26 T 15: 57: 34 -04: 00</timestamp> </tuple> </presence> ------- =_ZGY 1 NTFl. ZDJk. MDkx. Y 2 Fk. MTIx. MWI 2 Mz. Iz. Nj. E 1 M 2 U 0 OTY=-- PIDF-LO 30

Using Lo. ST for non-emergency services • Emergency services: “who serves location X” – one answer desired • Non-emergency services: “what services are within radius R of location X” – restaurants, banks, ATMs, hospitals • Can use Lo. ST with minor extensions: – shapes allow queries like “show restaurants within Prague city limits” (polygon) or “within 5 miles of where I am” (circle) – restrict number of responses – allow multiple responses April 2008 31

Current activities • IETF ECRIT working group – finishing Lo. ST, architecture, synchronization • NENA – architecture – transition documents – web services for queries • DOT – NG 911 project with BAH, Columbia & TAMU as sub-contractor – building proof-of-concept, based on earlier NTIA work – “National architecture for NG 9 -1 -1 system” & “Transition plan for NG 9 -11 implementation” • Lots of other activities – e. g. , semi-annual Emergency Services Coordination Workshop April 2008 32

NG 9 -1 -1 Prototype Architecture Location Routing PSTN April 2008 33

Emergency Call Flow (2) Location + Service Identifier (1) Location Lo. ST Cluster (3) PSAP URL + emergency dial-string INVITE call taker From: caller (7) <Location> (6) (4) SOS caller (5) dial emergency dialstring or INVITE PSAP URL To: urn: service: sos SIP proxy INVITE PSAP URL To: urn: service: sos <Location> push emergency button call taker Media Stream April 2008 Media Stream 34

Calltaker screen • • Columbia SIPc as SIP UA Mapping software to display caller’s location – Geolynx – Google Maps April 2008 35

Call logs and recorded sessions April 2008 36

NG 911 trial: Lessons learned • • Tested NG 911 prototype in 3 PSAPs in TX and VA Surprise: PSAP is really a conferencing system – Language. Line, first responders, … • Surprise: no uniform incident description – every jurisdiction uses their own variation and level of detail • What is desirable behavior – rather than current behavior – e. g. , for transfer, overflow • Need to integrate call taker management – presence (availability) – a specialized call center • Special requirements: partial mute – not typically supported on conference servers April 2008 37

Conclusion • Need for loosely-coupled suite of tools for emergency coordination – connecting rather than stovepipe systems – narrow interfaces rather than global master architecture • NG 911 as opportunity to update emergency calling – robustness – features (multimedia, connectivity) – COTS • Need for large-scale experiments, not yet another ad-hoc network paper – cooperation with non-technical users April 2008 38

More information • A Vo. IP Emergency Services Architecture and Prototype – M. Mintz-Habib, A. Rawat, H. Schulzrinne, and X. Wu, ICCCN 2005, Oct. 2005 • An Enhanced Vo. IP Emergency Services Prototype – Jong Yul Kim, Wonsang Song, and Henning Schulzrinne, ISCRAM 2006, May 2006 • Providing emergency services in Internet telephony • – H. Schulzrinne & K. Arabshian, IEEE Internet Computing, May/June 2002 Requirements for Emergency Context Resolution with Internet Technologies, draft-ietf-ecritrequirements Dynamic Host Configuration Protocol (DHCPv 4 and DHCPv 6) Option for Civic Addresses Configuration Information, RFC 4776 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information, RFC 3825 A Presence-based GEOPRIV Location Object Format, RFC 4119 A Uniform Resource Name (URN) for Services, draft-ietf-ecrit-service-urn Lo. ST: A Location-to-Service Translation Protocol, draft-ietf-ecrit-lost Best current practices for third party call control (3 pcc) in the session initiation protocol (SIP), RFC 3725 GETS: http: //gets. ncs. gov/ • Lo. ST server at http: //honamsun. cs. columbia. edu/lost_homepage/ • NG 911 project information at http: //ng 911. tamu. edu and • • April 2008 DOT 911 project 39