1. 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 session #27 in Denver
Authors or Source(s):
 Vijay Patel, Andrews
Abstract: NENA i3 Architecture: an Overview

2. IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE 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
The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws < and in Understanding Patent Issues During IEEE Standards Development
IEEE presentation release statements
This document has been prepared to assist the IEEE 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
The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual < and in Understanding Patent Issues During IEEE Standards Development

3. 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.

4. 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

5. 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

6. 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

7. i3 Architecture: Functional Elements

8. 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

9. 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).

10. 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.

11. i3 Architecture: A Typical Implementation

12. 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!

13. 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