1 / 34

VoIP/NG E9-1-1 IP-based E9-1-1 Migratory & Long Term Solutions – A Trial/Demo Update

VoIP/NG E9-1-1 IP-based E9-1-1 Migratory & Long Term Solutions – A Trial/Demo Update. Purpose of Project Conduct research in support of NENA’s Next Generation E9-1-1 initiative Conduct that research without endangering public safety

varden
Download Presentation

VoIP/NG E9-1-1 IP-based E9-1-1 Migratory & Long Term Solutions – A Trial/Demo Update

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. VoIP/NG E9-1-1 IP-based E9-1-1 Migratory & Long Term Solutions – A Trial/Demo Update

  2. Purpose of Project • Conduct research in support of NENA’s Next Generation E9-1-1 initiative • Conduct that research without endangering public safety • Share the results of that research with the public safety community

  3. Assumptions • Existing circuit switched 9-1-1 network will be replaced with a new network (NG E9-1-1) • PSAPs will have to be capable of handling calls via packet switched links • Independent research can help us to get ready

  4. Project Description • Extend prototype architecture into a campus environment and working PSAPs • Conduct tests of IP enabled emergency calling • Explore nomadic location services • Conduct long distance PSAP to PSAP transfers • Prove the value to public safety community of multimedia information data transfer

  5. Project Description (continued) • Explore lower cost off-the-shelf call taking equipment in Public Safety Answering Points, • Validate many of NENA’s requirements for the IP-enabled Public Safety Answering Point of the future, • Transfer knowledge to 9-1-1 community via presentations and workshops • Total project value - $1.5 million

  6. Partners • Columbia University, Texas A & M University, and University of Virginia • Internet2 • Texas and Virginia PSAPs • NENA • Texas and Virginia state 9-1-1 agencies • Cisco and Nortel • NTIA - grant funding

  7. Project Overview Columbia University Dr. Henning Shulzrinne • Internet Real-Time (IRT) labs • Developed prototype • Continue development work • Participate in testing • Draft RFC’s

  8. Project Overview (continued) Texas A & M University Dr. Walt Magnussen • Internet2 Technology Evaluation Center (ITEC) • Additional development • Coordinate field testing • Facilitate workshops and project demonstrations • Center for Distance Learning Research (CDLR) • Independent, outside evaluation of the project

  9. Project Overview (continued) University of Virginia • Coordinate testing of the remote PSAP routing capabilities Internet2 Consortium • Coordinate efforts of this project with other Internet2 projects • Disseminate information to other Internet2 members.

  10. Project Overview (continued) PSAPs • Brazos County Emergency Communication District • City of College Station, Texas • Charlottesville, Albemarle, UVA Emergency Communications Center • Call takers will participate in testing and provide feedback for the evaluation portion of the project

  11. Project Overview (continued) NENA • Coordinate user requirements in the development of the project • Coordinate information dissemination to the user community through white papers, workshops and seminars Texas and Virginia 9-1-1 Agencies • Funding Support • Information Dissemination

  12. Project Overview (continued) Cisco • Provide hardware and software • Provide access to one of their E-911 gateway solutions • Provide access to source code to Cisco equipment and applications Nortel Inc. • Provide a SIP based switching platform • Provide wireless system with the ability to provide location information about the Access Point being utilized for the connection

  13. Progress to Date • Initial Formation of Project Team • Acquired NTIA matching grant funding • Development of network architecture • Establishment of lab environment at Columbia University • Creation of preliminary PSAP call handling equipment to receive native VoIP • Demonstration of call processing at the National Press Club on May 26, 2005

  14. Next steps • Refine PSAP equipment configuration • Adding features and functionality • Improve reliability and diversity • Develop method for location validation • Address nomadic users

  15. Lessons Learned • VoIP can provide a strong foundation for PSAP call processing • PSAP equipment can be based on non-proprietary VoIP equipment • General location for routing can typically be determined by DNS

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

  17. What makes VoIP 112/911 hard?

  18. The core problem VSP sees emergency call but does not know caller location ISP/IAP knows user location but does not handle call

  19. 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)

  20. Core long-term requirements • Media-neutral • voice (+TDD) first, IM and video later • Work in systems without a voice service provider • many enterprises will provide their own local voice services • Allow down-stream call data access • as well as access to other “tertiary” data about the incident • Globally deployable • independent of national emergency number (9-1-1, 1-1-2, etc.) • respect jurisdictional boundaries – minimize need for cross-jurisdictional coordination • allow usage even if equipment and service providers are not local • travel, imported equipment, far-flung locations • Testable: • verifiable civic addresses (“MSAG validation”) • call route validation • Secure and reliable

  21. Three stages to VoIP 911

  22. I3: Location-based call routing – UA knows its location GPS INVITE sips:sos@ 48° 49' N 2° 29' E outbound proxy server DHCP 48° 49' N 2° 29' E  Paris fire department

  23. Location, location, location • Location  locate right PSAP & speed dispatch • In the PSTN, local 9-1-1 calls remain geographically local • In VoIP, no such locality for VSPs • most VSPs have close to national coverage • Thus, unlike landline and wireless, need location information from the very beginning • Unlike PSTN, voice service provider doesn’t have wire database information • VSP needs assistance from access provider (DSL, cable, WiMax, 802.11, …)

  24. Options for location delivery • L2: LLDP-MED (standardized version of CDP + location data) • periodic per-port broadcast of configuration information • L3: DHCP for • geospatial (RFC 3825) • civic (draft-ietf-geopriv-dhcp-civil) • L7: proposals for retrievals • by IP address • by MAC address • by identifier (conveyed by DHCP or PPP)

  25. DHCP for locations • modified dhcpd (ISC) to generate location information • use MAC address backtracing to get location information 8:0:20:ab:d5:d DHCP server CDP + SNMP 8:0:20:ab:d5:d 458/17 DHCP answer: sta=DC loc=Rm815 lat=38.89868 long=77.03723 458/17  Rm. 815 458/18  Rm. 816

  26. NG-911 prototype • Goal: build prototype VoIP SIP-based emergency calling system • including caller end system • call routing (DNS) • PSAP infrastructure • Use commodity components where possible • Test reliability and redundancy

  27. Call routing

  28. Components No endorsement implied – other components likely will work as well

  29. Call taker setup SIPc client receives calls GeoLynx software displays caller location

  30. GeoLynx displays location GeoLynx listens for commands from SIPc

  31. INVITE REFER INVITE media info INVITE INVITE REFER REFER INVITE media info Emergency call conferencing PSAP brings all related parties into a conference call Hospital Fire department INVITE Conference server Recorder 3rd party call control PSAP Caller

  32. Scaling • NENA: “estimated 200 million calls to 9-1-1 in the U.S. each year” •  approximately 6.3 calls/second • if 3 minute call, about 1,200 concurrent calls • typical SIP proxy server (e.g., sipd) on 1 GHz PC can handle about 400 call arrivals/second • thus, unlikely to be server-bound

  33. Current standardization efforts • NENA (National Emergency Number Association) • I2 and I3 architecture • requirements based on operational needs of PSAPs • ETSI OCG – EMTEL • exploratory – also emergency notification • NRIC • goals and long-term architecture • IETF: • individual and SIPPING drafts for identifier, call routing, architecture • SIP and DNS usage • possibly new protocols for lookups • ECRIT WG for mapping part just getting started

  34. Conclusion • Emergency calling services necessary condition for first-line wireline-replacement services • US: large numbers of PSAPs financially exhausted from Phase II wireless support • often 1970s technology – end of bailing wire reached • Long-term opportunity for better services

More Related