IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-08-0219-00-00es Title: NENA i3 Architecture: An Overview Date Submitted: July, 15, 2008 Presented at IEEE 802.21 session #27 in Denver Authors or Source(s):  Vijay Patel, Andrews Abstract: NENA i3 Architecture: an Overview 21-07-0219-00-0000

IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. 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. 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 802.21. The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf>  IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. 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. 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 802.21. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html>  21-07-0219-00-0000

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 IEEE802.11 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 802.11 mechanism and specs. 21-07-0219-00-0000

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 21-07-0219-00-0000

Location CallbackNum ES-Nums ELT etc… PSAP1 VPC PSAP2 ESZ1 ESZ2 ESRN = X ESN = Y ES-Nums = n1, n2, n3… ELT = s1, s2, s3… ESZ3 ESZ4 ESZ5 ESZ6 ERDB Call Server ESGW Selective Router ALI 1 2 3 4 5 6 7 8 9 10 11 12 1a 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 LOsig Call setup, routing and query routing V0 V1 V2 V3 V4 E2 21-07-0219-00-0000

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 21-07-0219-00-0000

i3 Architecture: Functional Elements 21-07-0219-00-0000

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 21-07-0219-00-0000

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). 21-07-0219-00-0000

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. 21-07-0219-00-0000

i3 Architecture: A Typical Implementation 21-07-0219-00-0000

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! 21-07-0219-00-0000

References Interim VoIP Architecture for Enhanced 9-1-1 Services (i2), NENA 08-001, 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 21-07-0219-00-0000