Vo IP NG E 9 -1 -1 IP-based E

Vo. IP/NG E 9 -1 -1 IP-based E 9 -1 -1 Migratory & Long Term Solutions – A Trial/Demo Update

Purpose of Project • Conduct research in support of NENA’s Next Generation E 9 -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 9 -1 -1 network will be replaced with a new network (NG E 9 -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 9 -1 -1 community via presentations and workshops • Total project value - $1. 5 million

Partners • Columbia University, Texas A & M University, and University of Virginia • Internet 2 • Texas and Virginia PSAPs • NENA • Texas and Virginia state 9 -1 -1 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 • Internet 2 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 Internet 2 Consortium • Coordinate efforts of this project with other Internet 2 projects • Disseminate information to other Internet 2 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 9 -1 -1 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 Vo. IP • 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 • Vo. IP can provide a strong foundation for PSAP call processing • PSAP equipment can be based on nonproprietary Vo. IP equipment • General location for routing can typically be determined by DNS

Components of emergency calling now Contact well-known number or identifier 112 911 transition all IP 112 911 dial 112, 911 signal 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

What makes Vo. IP 112/911 hard? POTS PSTN-emulation Vo. IP end-to-end Vo. IP (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 carrier national or continent-wide carrier enterprise “carrier” or anybody with a peer-to-peer device voice provider = line provider voice provider ≠ ISP (~ 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

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 • Vo. IP 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 crossjurisdictional 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 Vo. IP 911 spec. available? use 10 digit admin. number? mobility callback number to PSAP? caller location to PSAP? PSAP modificatio n ALI (DB) modification new services I 1 now allowed stationary no no none I 2 June 2005 no stationary nomadic yes no (8 or 10 digit) update none I 3 2005 no stationary nomadic mobile yes IP-enabled ALI not needed MSAG replaced by DNS location inband GNP multimedia international calls

I 3: 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

Location, location Location locate right PSAP & speed dispatch In the PSTN, local 9 -1 -1 calls remain geographically local In Vo. IP, 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, Wi. Max, 802. 11, …)

Options for location delivery L 2: LLDP-MED (standardized version of CDP + location data) • periodic per-port broadcast of configuration information L 3: DHCP for • geospatial (RFC 3825) • civic (draft-ietf-geopriv-dhcp-civil) L 7: 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 8: 0: 20: ab: d 5: d DHCP server CDP + SNMP 8: 0: 20: ab: d 5: d 458/17 Rm. 815 458/18 Rm. 816 DHCP answer: sta=DC loc=Rm 815 lat=38. 89868 long=77. 03723

NG-911 prototype Goal: build prototype Vo. IP 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 sipd SIP proxy server database-backed DNS server SIP phone web server SQL database for call routing sipc SIP user agent geo-coding, PSAP boundaries GIS software for call location plotting No endorsement implied – other components likely will work as well

Call taker setup SIPc client receives calls Geo. Lynx software displays caller location

Geo. Lynx displays location Geo. Lynx listens for commands from SIPc

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

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

Current standardization efforts NENA (National Emergency Number Association) • I 2 and I 3 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 1970 s technology – end of bailing wire reached Long-term opportunity for better services