1 / 66

Next-Generation Emergency Calling (NG911)

Next-Generation Emergency Calling (NG911). Henning Schulzrinne Dept. of Computer Science, Columbia University, New York hgs@cs.columbia.edu

chidi
Download Presentation

Next-Generation Emergency Calling (NG911)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Next-Generation Emergency Calling (NG911) 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; LoST is joint work with Hannes Tschofenig, Andrew Newton and Ted Hardie) IEEE NY Lecture October 18, 2007

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

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

  4. Outline • Emergency calling • the challenge of two transitions • mobility and VoIP • Emergency alerts • Emergency coordination

  5. Background on 9-1-1 • Established in Feb. 1968 • 1970s: selective call routing • late 1990s: 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 VoIP as either primary or secondary line by end of 2008” (NENA) http://www.nena.org/

  6. Local Switch Automatic Number Identification Automatic Location Identification Collaboration between local phone providers and local public safety agencies

  7. 911 technology failures • NY Times (“An S O S for 911 Systems in Age of High-Tech”), 4/6/07: • “40% of … counties, most of them rural or small-town …, cannot yet pinpoint the location of the cellphone callers, though the technology to do so has been available for at least five years.”“In … Okmulgee, Okla., last November, 4-year-old Graciella Mathews-Tiger died in a house fire after a 911 operator who lacked the technology to pinpoint the call misheard the address.” • Phase II wireless; billions of dollars spent • In Mississippi, only 1 of out 5 counties • “As it ages, it is cracking, with problems like system overload, understaffing, misrouted calls and bug-ridden databases leading to unanswered calls and dangerous errors.” • operator (CAMA) trunks, with 8-digit number delivery • MSAG and ALI databases

  8. 911 technology failures, cont’d • “In Cherokee County [OK], for instance, the volume has increased by 20 percent a year.”“… answer 911 lines, then transfer calls to dispatchers for individual fire and police departments in the county, a system that requires callers to repeat themselves.” • Inefficient call handling • Vermont dispatch-by-printer • “Officials in Riverside County, Calif., fed up with misrouted calls, have been advising residents to call the sheriff or local fire department directly.” • incomplete MSAG • cumbersome ALI update procedures

  9. 911 technology failures, cont’d. • “In Bessemer, Ala., city employees could not get through to their own 911 system when a colleague had a seizure, at a time when the city and others like it are struggling to upgrade their systems at a cost of hundreds of thousands of dollars.” • specialized technology supplied by small vendors • almost no R&D • “Yet even the newest systems cannot adequately handle Internet-based phone services or text messages, which emerged as the most reliable form of communication during Hurricane Katrina.” • mostly voice-only • plus TDD (TTY), plus deaf are switching to IM

  10. 911 problems • “Ellis is accused of a relatively new Internet-related crime called "swatting.” Police believe Ellis, of Mukilteo, Wash., used an online service for the hearing impaired and other high-tech methods to make false reports of escalating violence to police departments across the country. … The false reports ended with SWAT team members taking down innocent people at gunpoint and holding them for questioning.” (Erie Times News, Oct. 17, 2007) • no location reporting for TDDs • no user authentication or meta data

  11. Dept. of Transportation view • The 9-1-1 system • based on 30-year old technology • expensive for local 9-1-1 call centers to maintain • incapable of supporting the text, data, images, and video that are increasingly common in personal communications. • Travelers and other citizens cannot now use their “smart” technologies such as telematics, medical alert devices, or wireless computers to directly access 9-1-1 call centers and emergency responders. • Emergency centers cannot now send location-targeted hazard alerts and evacuation guidance to motorists or other mobile device users Next-Generation 9-1-1 Initiative slides

  12. VoIP emergency communications now transition all IP (“NG911”) Contact well-known number or identifier 112 911 112 911 112, 911 urn:service:sos dispatch Route call to location-appropriate PSAP LoST SR VPC Deliver precise location to call taker to dispatch emergency help phone number  location (ALI lookup) in-band  key  location in-band (SIP)

  13. 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: $340m (=> $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)

  14. What makes VoIP 112/911 hard?

  15. 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 • VoIP can transfer overload calls anywhere • Location delivery • carry location with forwarded and transferred calls • multiple location objects (civic + geo)

  16. Four Phases of Emergency Calls Phase 4 Phase 1 Phase 2 Phase 3

  17. IETF ECRIT working group • Emergency Contact Resolution with Internet Technologies • Solve four major pieces of the puzzle: • location conveyance (with SIP & GEOPRIV) • emergency call identification • mapping geo and civic caller locations to PSAP URI • discovery of local and visited emergency dial string • Not solving • location discovery --> IETF GEOPRIV WG, IEEE • inter-PSAP communication and coordination • citizen notification • Current status: • finishing general and security requirements • agreement on mapping protocol (LoST) and identifier (sos URN) • working on overall architecture and UA requirements

  18. 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) Emergency number

  19. Service URN • Idea: Identifiers to denote emergency calls • and other generic (communication) services • Described in IETF ECRIT draft 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

  20. ‘counseling’ services

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

  22. Location, 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

  23. Locating Caller using LLDP-MED LLDP-MED stands for: * Link Layer Discovery Protocol “a vendor-neutral Layer 2 protocol that allows a network device to advertise its identity and capabilities on the local network.” Media Endpoint Discovery “an enhancement to the LLDP that allows discovery of other things including location“ * From Wikipedia “I am LLDP-MED Capable. I can process location information.” “Your location is: 500 W 120TH st. New York NY 10027”

  24. DHCPINFORM [MAC=00:11:20:9d:a0:03] request or response DHCPACK [option=0:US:1:NY:2:NEW YORK: 3:NEW YORK:6:AMSTERDAM:19:1214] DHCP Server DHCP for Location • Use MAC address to get location information • Mainly for stationary users • We modified ISC’s dhcpd

  25. DHCP elements: Administrative Subdivisions support multiple character sets for each

  26. SkyHook for Location • Mainly for nomadic, mobile users • Wireless device receives signals from Wi-Fi sites in range • Skyhook compares signals to its database of geographically known locations • Location data is used to direct safety services Taken from http://www.skyhookwireless.com

  27. Location determination options

  28. Components of NG911 system • Location determination • Call identification --> service URNs • Call routing --> LoST • PSAP functionality • IVR, logging, multimedia conferencing, … LoST (public) LoST (private) ESN (county, state, …) PSAP PSAP Internet

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

  30. LoST: A Protocol for Mapping Geographic Locations to Public Safety Answering Points Henning Schulzrinne, Hannes Tschofenig, Andrew Newton, Ted Hardie

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

  32. LoST 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 LoST servers • Indicates errors in civic location data  debugging • but provides best-effort resolution • Supports overlapping service regions • e.g., contested regions (Kashmir, Palestine, Taiwan, ...)

  33. LoST: Location-to-URL Mapping VSP1 cluster serving VSP1 replicate root information cluster serves VSP2 123 Broad Ave Leonia Bergen County NJ US LoST root nodes NJ US NY US sip:psap@leonianj.gov search referral Bergen County NJ US Leonia NJ US

  34. LoST Architecture G tree guide G G G broadcast (gossip) T1: .us T2: .de G resolver T2 (.de) seeker 313 Westview Leonia, NJ US T3 (.dk) T1 (.us) Leonia, NJ  sip:psap@leonianj.gov

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

  36. LoST: Query example • Uses HTTP or HTTPS <findService xmlns="urn:…:lost1” recursive="true" serviceBoundary="value"> <location profile="basic-civic"> <civicAddress> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <A6>Neu Perlach</A6> <HNO>96</HNO> </civicAddress> </location> <service>urn:service:sos.police</service> </findService>

  37. LoST “Find Service” response/warning example <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"> <mapping expires=“1990-12-31T23:59:60Z” lastUpdated=“2006-11-01T01:00:00Z”> <displayName xml:lang="de">München Polizei-Abteilung</displayName> <service>urn:service:sos.police</service> <serviceBoundary profile=”civic”> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>Germany</country> <A1>Bavaria</A1><A3>Munich</A3><PC>81675</PC> </civicAddress> </serviceBoundary> <uri>sip:munich-police@example.com</uri> <serviceNumber>110</serviceNumber> </mapping> <path> <via source=“lost:esgw.uber-110.de.example”/> <via source=“lost:polizei.munchen.de.example”> </path> </findServiceResponse>

  38. 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 <locationValidation> <valid>country A1 A3 A6</valid> <invalid>PC</invalid> </locationValidation>

  39. Geo support • Which geo types should be supported? • Point (3D)  • Polygon?  may yield ambiguous answers • more complicated shapes? • Current proposal • always include 2D-point • may include other shapes • Caching of mappings • return service region • only query again if mobile leaves service region • open issue: “holes” in service region

  40. Advanced LoST functionality • Get list of (emergency) services supported • by server • for a region • Obtain service regions • identified by globally-unique tag <listServicesByLocationResponse> <serviceList> urn:service:sos.ambulance urn:service:sos.animal-control </serviceList> <path> <via source="auth.example"/> <via source="res.example"/> </path> </listServicesByLocationResponse> <listServicesByLocation> <location profile="geodetic-2d"> <p2:Point srsName="urn:4326"> <p2:pos>-34.407 150.883</p2:pos> </p2:Point> </location> <service>urn:service:sos</service> </listServicesByLocation>

  41. Server synchronization • Synchronization of forest guides and server clusters • push <mapping> information to peers • get list of new elements and retrieve mappings <getMappingsRequest> <m sourceId="lost.example" sourceId="abc123" lastUpdated=“..” /> </getMappingsRequest> existing server new server <getMappingsResponse> <mappings>...</mappings>

  42. Performance of CU LoST server roughly 170 req/sec --> ~17M / day dual-core P4/3.0 GHz Linux 2.6.19 Postgresql 8.1.4 Tomcat 4.1

  43. SIP message for Location Info. ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 Content-Type: application/pidf+xml Content-Transfer-Encoding: 8bit <?xml version="1.0" encoding="ISO-8859-1"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" entity="sip:calltaker_ny2@irt.cs.columbia.edu"> <tuple id="28185"> <status> <gp:geopriv> <gp:location-info> <cl:civilAddress> <cl:country>us</cl:country> <cl:A1>ny</cl:A1> <cl:A2>new york</cl:A2> <cl:A3>new york</cl:A3> <cl:A6>amsterdam</cl:A6> <cl:HNO>1214</cl:HNO> </cl:civilAddress> </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-26T15:57:34-04:00</timestamp> </tuple> </presence> ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=-- INVITE urn:service:sos SIP/2.0 request line 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 header fields ------ =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 content-Type: application/sdp Content-Transfer-Encoding: 8bit v=0 o=eddie 1127764654 1127764654 IN IP4 192.168.1.106 s=SIPC Call c=IN IP4 160.39.54.70 t=0 0 m=audio 10000 RTP/AVP 0 3 m=video 20000 RTP 31 SDP PIDF-LO

  44. NENA i3 architecture

  45. NENA i3 architecture

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

  47. Location Routing PSTN NG9-1-1 Prototype Architecture

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

  49. Calltaker screen • Columbia SIPc as SIP UA • Mapping software to display caller’s location • Geolynx • Google Maps

  50. Call logs and recorded sessions

More Related