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 Share the results of that research with the public safety community

Assumptions Existing circuit switched 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

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

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 community via presentations and workshops Total project value - $1.5 million

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

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

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

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.

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

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 Agencies Funding Support Information Dissemination

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

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

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

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

Components of emergency calling Contact well-known number or identifier Route call to location-appropriate PSAP Deliver precise location to call taker to dispatch emergency help nowtransitionall IP dial 112, 911 signal selective router VPCDNS phone number  location (ALI lookup) in-band  key  location in-band

What makes VoIP 112/911 hard? POTSPSTN-emulation VoIPend-to-end VoIP (landline) phone number limited to limited area landline phone number anywhere in US (cf. German 180) no phone number or phone number anywhere around the world regional carriernational or continent-wide 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 locationmostly residential or small business stationary, nomadic, wireless

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

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)

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

Three stages to VoIP 911 spec. available? use 10- digit admin. number? mobilitycallback number to PSAP? caller location to PSAP? PSAP modificatio n ALI (DB) modification new services I1 nowallowedstationaryno none I2 June 2005 nostationary nomadic yes no (8 or 10 digit) updatenone I3 2005nostationary nomadic mobile yes IP-enabledALI not needed MSAG replaced by DNS location in- band GNP multimedia international calls

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

Location, location, location Location  locate right PSAP & speed dispatch In the PSTN, local 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, , …)

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)

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

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

Call routing

Components sipdSIP proxy server database-backed DNS server SIP phone web server SQL database for call routing sipcSIP user agent geo-coding, PSAP boundaries GIS software for call location plotting No endorsement implied – other components likely will work as well

SIPc client receives callsGeoLynx software displays caller location Call taker setup

GeoLynx listens for commands from SIPc GeoLynx displays location

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

Scaling NENA: “estimated 200 million calls to 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

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

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