1 / 27

NG911 - Next-Generation Emergency Calling

NG911 - Next-Generation Emergency Calling. Henning Schulzrinne (with Jong Yul Kim, Wonsang Song, Anshuman Rawat, Matthew Mintz-Habib, Amrita Rajagopal and Xiaotao Wu) Dept. of Computer Science Columbia University. Introduction. Emergency calling is a necessary part of consumer voice service

dino
Télécharger la présentation

NG911 - Next-Generation Emergency Calling

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. NG911 - Next-Generation Emergency Calling Henning Schulzrinne (with Jong Yul Kim, Wonsang Song, Anshuman Rawat, Matthew Mintz-Habib, Amrita Rajagopal and Xiaotao Wu) Dept. of Computer Science Columbia University

  2. Introduction • Emergency calling is a necessary part of consumer voice service • citizen calls PSAP (public safety answering point) for assistance • Existing solutions are insufficient • may deliver call to wrong PSAP • particularly for nomadic and mobile users • may not deliver location to PSAP • makes it difficult to move call information around • e.g., call location to first responder • voice only (+ TDD) NG - November 2006

  3. VoIP emergency communications emergency call emergency alert (“inverse 911”) dispatch civic coordination NG - November 2006

  4. Components of emergency calling now transition all IP Contact well-known number or identifier 112 911 112 911 dial 112, 911 urn:service:sos Route call to location-appropriate PSAP selective router VPC DNS Deliver precise location to call taker to dispatch emergency help phone number  location (ALI lookup) in-band  key  location in-band NG - November 2006

  5. What makes VoIP 112/911 hard? NG - November 2006

  6. The core problem Voice Service Provider (VSP) sees emergency call but does not know caller location ISP/IAP knows user location but does not handle call NG - November 2006

  7. Staged deployment • ~6,134 PSAPs in North America • average 2-3 active call takers each • some serve town, some large parts of a state • only ~30% of PSAPs can receive geo coordinates • 30-40% may be voice only • many using 1970s telecom technology • “CAMA” (operator) trunks • limited to delivering 8 (regional) or 10 digits (national) of information • already facing pressure from supporting cellular services • Phase I (cell tower and face) and Phase II (caller geo location) • EU: smaller number of PSAPs, but often without location delivery NG - November 2006

  8. Components • 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 NG - November 2006

  9. 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) NG - November 2006

  10. IETF ECRIT working group • Emergency Contact Resolution with Internet Technologies • Solve four major pieces of the puzzle: • location conveyance (with SIPPING & GEOPRIV) • emergency call identification • mapping geo and civic caller locations to PSAP • discovery of local and visited emergency dial string • Not solving • location discovery • inter-PSAP communication and coordination • citizen notification • Current status: • finishing general and security requirements • tentative agreement on mapping protocol and identifier • later, to work on overall architecture and UA requirements NG - November 2006

  11. Service URN • Idea: Identifiers to denote emergency calls • and other generic (communication) services • Described in draft-ietf-ecrit-service-urn-05 (passed WGLC; sent to the IESG) • Document defines the following 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 NG - November 2006

  12. ‘counseling’ services NG - November 2006

  13. 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 NG - November 2006

  14. 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 NG - November 2006

  15. UA recognition & proxy resolution mapping 9-1-1 (outbound proxy) provider.com INVITE urn:service:sos To: urn:service:sos <location> INVITE urn:service:sos To: urn:service:sos Route: sip:psap@leonianj.gov <location> NG - November 2006

  16. UA recognition & proxy resolution(proxy location determination) mapping 9-1-1 provider.com INVITE sip:psap@leonianj.gov To: urn:service:sos Geolocation: <location> INVITE urn:service:sos To: urn:service:sos NG - November 2006

  17. Proxy recognition & proxy resolution mapping 9-1-1 provider.com INVITE urn:service:sos To: sip:911@provider.com;user=phone Geolocation: <location> Route: sip:psap@leonianj.gov INVITE sip:911@provider.com;user=phone To: sip:911@provider.com;user=phone NG - November 2006

  18. 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 NG - November 2006

  19. LoST functionality • Satisfies the requirements (draft-ietf-ecrit-requirements) for mapping protocols • Civic as well as geospatial queries • civic address validation • Recursive and iterative resolution • 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 NG - November 2006

  20. 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 NG - November 2006

  21. Protocol request (mapping) <findService xmlns="urn:ietf:params:xml:ns:lost1" recursive="true" include="serviceBoundary invalid valid unchecked"> <location profile="urn:ietf:params:lost:location-profile:basic-civic"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <country>Germany</country> <A1>Bavaria</A1> <A3>Munich</A3> <A6>Neu Perlach</A6> <HNO>96</HNO> <PC>81675</PC> </civicAddress> </location> <service>urn:service:sos.police</service> </findService> NG - November 2006

  22. LoST “Find Service” response/warning example <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"> <mapping ttl=“1990-12-31T23:59:60Z”> <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> <uri>xmpp:munich-police@example.com</uri> <serviceNumber>110</serviceNumber> </mapping> <validation><unchecked/></validation> <warnings> <locationProfileUnrecognized profile=“martian-civic”/> </warnings> <via>lost:esgw.uber-110.de.example</via> <via>lost:polizei.munchen.de.example</via> </findServiceResponse> NG - November 2006

  23. 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 NG - November 2006

  24. 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 NG - November 2006

  25. LoST architecture VSP1 cluster serving VSP1 replicate root information cluster serves VSP2 123 Broad Ave Leonia Bergen County NJ US root nodes NJ US NY US sip:psap@leonianj.gov search referral Bergen County NJ US Leonia NJ US NG - November 2006

  26. 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 NG - November 2006

  27. Conclusion • Opportunity to fundamentally restructure emergency communications • higher reliability with large-scale disasters • lower cost • richer interaction • IETF ECRIT and SIP working group converging on core protocols • service URNs • SIP location conveyance • LoST NG - November 2006

More Related