Network to PSAP Interface: Signaling Needs

1. Network to PSAP Interface: Signaling Needs Prepared For:SBC and BellSouth In support of NENA Migration WG March 27, 2002 Telcordia Contacts:Nadine Abbott (732) 758-5257 nabbott@telcordia.com Selvam Rengasami (732) 758-5260 srengasa@telcordia.com Telcordia Technologies Proprietary – Internal Use Only This document contains proprietary information that shall be distributed, routed or made available only within Telcordia Technologies, except with written permission of Telcordia Technologies. An SAIC Company

2. Overview • Summary of E911 Functionality (from Bernard Brabant’s presentation to NENA TDC) • Summary of issues raised during Migration discussion at NENA TDC • Summary of signaling functions required by network to PSAP interface, extracted from Telcordia contribution

3. E911 Functionality (from Bernard Brabant summary at NENA TDC) • Voice grade quality line • ANI (or some other indicator or key) • Call Delivery (voice routed to designated SR) • Call Routing (routable number) • Call Priority (voice packets) • Selective Routing and Transfer (IP-based SR) • Default routing when ANI/KEY is not available • Security (voice/data content)

4. E911 Functionality (cont.)(from Bernard Brabant summary at NENA TDC) • Emergency Call Trace (power active or not) • Location Determination and Identification • Call Back (recall an IP-device) • Ringback, Caller Hold, • Reverse ALI Search • X & Y coordinates • TTY and TDD • Busy Line Verification and Busy Line Interrupt • etc. . .

5. Summary of Issues Identified during Q&A at NENA TDC • Location • Information for selective routing/assisted dispatch • Of PSAPs • Security • Database access • Calls • Power – sensitivity • Quality of Service • Voice call related (e.g., jitter, latency, delay) • Traffic related • Shortage of qualified staff/training to support VoIP? • Reliability/Outages • Bandwidth requirements • Availability of IP network access (geographic distribution is uneven)

6. Summary of Issues Identified during Q&A at NENA TDC • E9-1-1 PSAP Feature comparability with existing E911 tandems • E9-1-1 PSAP Feature uniformity • Interoperability with existing premise based ACDs • PSAP alarms • Overflow to alternate PSAPs • New PSAP operational and performance measurement requirements • Request for technical course in IP technology • Concern about possible additional delays for conversion of MF signaling to packet

7. Possible Motivations for Considering VoIP Access at PSAP (from Telcordia) • Convergence of Voice and Data on PSAP access • Efficient use of bandwidth on access to reduce costs? • Reduce number of equipment interfaces that have to be maintained and tested. • Support of multi-media calls (e.g., transferring CAD data with voice call to a secondary PSAP or dispatch center) • Possible to leverage public network facilities, while retaining secure access.

8. Some Strategic Issues (from Telcordia) • Network Terminating Office Functionality for converged voice/data access could be provided by, for example: • Legacy E911 Tandem [Selective Router] with traditional CAMA or Enhanced MF trunks (or Custom ISDN) terminated on an E911 capable Media Gateway. • Legacy E911 Tandem [Selective Router] with integrated E911 gateway functionality supporting converged access and VoIP signaling (Nortel proposal at NENA TDC) • AIN End Office with custom ISDN interface • Softswitch based VoIP network with Selective Routing functionality and E911 gateways • Additional delays for converting CAMA/Enhanced MF signaling to packet may be unacceptable—migration to converged access may not be feasible without changes to signaling from terminating office.

9. Some Strategic Issues (from Telcordia, cont.) • Will converged access support both emergency call terminations and administrative calling? • Quality of Service for emergency calls. • Support of voice call delivery to PSAPs should be provided over managed IP networks that can provide QoS guarantees. • Emergency calls are received in a distracting environment, and the effects of any degradation in voice quality would be unacceptable. • If VoIP is also implemented on the PSAP LAN, coordination of QoS measures is required among the public and private parts of the packet network. • Security • Need secure intranet for PSAPs that share information, e.g., via servers. • Various approaches have been proposed for providing security on VoIP networks. This will require careful evaluation. Some combination of approaches may be needed.

10. Some Strategic Issues (from Telcordia, cont.) • What are the survivability and real-time redundancy requirements for the IP PSAP and supporting packet network access? (E.g., component and route redundancy?) What impacts are there on the packet-based architectures?

11. Summary of Functions/Signaling Needs for Network to PSAP Interface (from Telcordia) • Delivery of call to appropriate work station • Interwork with existing Customer Premise Equipment (CPE) Automatic Call Distribution (ACD) functions • Interwork with existing CPE Key Telephone System arrangements • Interface support of network-based call distribution functions? • Need to signal called party number to distinguish emergency calls from administrative calls, if access is shared to support both. • Delivery of Callback Number to PSAP • Delivery of ANI/Location Information (Phase 1) • Delivery of Location Information (Phase 2) • Delivery of “flashing” indication with emergency call (e.g., to indicate alternate routing) • Ability to provide inband audible ringing tone toward emergency caller (provided today by PSAP equipment)

12. Summary of Functions/Signaling Needs for Network to PSAP Interface (from Telcordia, cont.) • ALI controller function—where? • ALI queries/responses • PSAP based queries (as today) • Network supported queries (e.g., via a server) to deliver ALI earlier • Ability to provide access for archival voice recording functions for emergency calls • Alternate Routing (to another PSAP) • Signaling to invoke/revoke alternate routing to pre-specified PSAP • Signaling to indicate request to accept alternate routing • Signaling to indicate alternate routing is active (to invoking and target PSAP) • (Future) Capability to specify target PSAP explicitly

13. Summary of Functions/Signaling Needs for Network to PSAP Interface (from Telcordia, cont.) • Support for Central Office Transfer capabilities • Signaling required to request transfer • Manual Transfer • Fixed Transfer • Selective Transfer • Conference bridge—where should this functionality be supported? By a server in the network? At the PSAP? • Transfer of associated data with COTs to other PSAPs • Via multi-media calls? • Via Server based sharing of data: e.g., sending of “key” with transferred voice call to allow retrieval of transfer-related data (e.g., from intra-net server/web site)

14. Summary of Functions/Signaling Needs for Network to PSAP Interface (from Telcordia, cont.) • Callback (to reach emergency caller) • Ringdown • PSAP Alarms • Support for TDD and TTY

15. Possible Future Functions/Signaling for Network to PSAP Interface • Requests by the IP PSAP for updates of location information for an emergency caller during a call?

16. Possible Next Steps? • Develop Motivations • Identify additional motivations for each step of migration strategy • Strategic Issues Analysis • Identify any other issues? • Prioritize • Plan for how strategic questions should be addressed? And by whom? • Signaling Needs Analysis • Identify any other feature/functions required for access interface? • Prioritize capabilities. • Draft Stage 1 service description, and Stage 2 description of functional elements and information flows. • Draft liason to be sent to IETF, ANSI T1S1, ITU, including above descriptions and requesting protocol support (Stage 3).