doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 1 NENA i3 Architecture: An Overview Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at. Date: Authors:

doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 2 Abstract The National Emergency Number Association (NENA) is developing the Stage 2 framework document to facilitate implementation of IP-based multi-media emergency services in North America. In December 2005, NENA had earlier already published the interim i2 architecture that served as the first migratory step in order to bring the emergency services in line with the IP proliferation in the field of communication. Earlier this year, NENA had requested that IEEE review its working document on i3 framework for compatibility, for the two initiatives have impact on each other. This presentation, then, is an overview of the salient features of NENA approach to all IP-based emergency services architecture (that it calls i3). Additionally, an attempt has also been made to highlight the issues and concerns in areas that most likely would interact with mechanism and specs.

doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 3 NENA defined (i2) migratory architecture Note boundaries of responsibility! ALI Local National PAM CAMA IP ISUP Call Server LIS VPC – VoIP Position Centre LIS – Location Identification Server Selective Router VPC E2+ ESGW VSP ISP Global ESZ boundary data Call Handling Call routing and location delivery Location determination Geodetic & Civil loc,n locn call Civic addr MSAG validation VDB ERDB Emergency network 911

doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 4 PSAP1 VPC PSAP2 PSAP1 ESZ1 ESZ2 ESRN = X ESN = Y ES-Nums = n1, n2, n3… ELT = s1, s2, s3… ESZ3 ESZ4 ESZ5 ESZ6 ERD B Call Server ESGW Selective Router ALI a LIS CallbackNum LO|LK LO request LO LO identified with applicable ESZ ESRN ESN ES-Nums ELT… ESRN ESQK ESQK Location CallbackNum ES-Nums ELT etc… ESGW chosen based on ESRN SR chosen on ESRN and trunk selection rules specified by SR operator PSAP route selected based on ESQK from SRDB VPC selected based on ESQK 911 LO sig Call setup, routing and query routing V0 V1 V2 V3 V4 E2

doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 5 Major i2-to-i3 Differential Legacy Emergency Network is now fully IP-based, including i3 PSAPs Some legacy nodes--such as Selective Router, legacy PSAP, and ALI--as well as concept of Emergency Service Zone (ESZ) are no longer needed Call signaling is IP-based; primarily SIP, although other protocols could also be supported A fully end-to-end multimedia infrastructure for emergency calls Location, by reference or by value, transported in the signaling itself; thus, the IP end-point provides location with the emergency call

doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 6 i3 Architecture: Functional Elements

doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 7 i3 Architecture - General NENA & ESIF (Emergency Services Interconnection Forum) –NENA develops requirements (Stage 1), and Stage 2 architectural framework and design definitions –ESIF (Emergency Services Interconnection Forum), under ATIS, develops the specs for pertinent interfaces i3 conceptualizes Emergency Services IP internetwork (ESInet) –Multimedia SOS calls are accepted and processed –Examples of emergency call source: audio/video handset (phone, PDA), SMS, IM, or telematics terminal –End-to-end IP-based with i3 PSAPs as responders, and includes gateways to provide access to non IP-based callers –Primarily based on IETF’s SIP but could as well work with any VoIP protocol

doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 8 i3 Functional Elements & Interfaces Location of an IP end-point: –Determination covers those functions which are necessary to accurately and automatically determine the position of an user device, and associate it uniquely with the device –Acquisition relates to functions needed to make that positioning information available to the device on request, or to a Proxy acting on behalf of the device which are not location-aware. Location Information Server (LIS) Functions: –Storage of a wiremap of physical end-point termination and location (civil or geo-coordinates), after required validation against MSAG (Master Street Address Guide) –Support for position determination of an end-point, and acquisition by it or on behalf of the end-point –Assignment of a location query-key to a particular IP device, allow downloading of the query-key to the device to facilitate subsequent queries for the location information by other network elements (useful for location updates on mobile terminals).

doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 9 i3 Functional Elements, Interfaces (contd) Border Control Function (BCF): –Provides secure entry into the ESInet with respect to presented emergency calls –Incorporates firewall, and admission control –Mechanisms to thwart deliberate or malicious attacks on PSAPs and other entities connected to ESInet. Emergency Call Routing Function (ECRF): –Receives (geo or civic) location, provides a URI for routing the call to correct PSAP --- directly, or via an Emergency Services Routing Proxy (ESRP). i3 PSAP: –Operates on IP-based (such as SIP) signaling for delivery of emergency calls, and IP-based data protocols for other information exchange.

doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 10 i3 Architecture: A Typical Implementation

doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 11 Food for Thought LIS functionality in the access network remains the same in both i2 & i3 IP-based location acquisition protocol is assumed on LIS-endpoint (V0 in i2 / K0 in i3) interface that is independent of Link Layer technology. A liaison statement was sent, early this year, by the Next Generation Emergency Services (NGES) Subcommittee of ESIF/ATIS to many SDOs, including IEEE802, requesting input with regard to their evaluation of Location Acquisition Protocols!

doc.: IEEE /0794r0 Submission May 2007 Vijay Patel, Andrew CorporationSlide 12 References Interim VoIP Architecture for Enhanced Services (i2), NENA , Issue 1, December 06, 2005 Functional and interface Standards for Next Generation 9-1-1, Version 1.0 (i3), NENA 08-0XX, Issue 0.1 DRAFT, April 10, 2007