STANDARDS PROJECT: IP Telephony Support for Emergency Calling Service

th FINAL (5 ) DRAFT TR-41.4/02-05-022

TITLE: IP Telephony Support for Emergency Calling Service

SOURCE:

EDITOR: Mo Zonoun Phone: 408-495-7406 Nortel Networks Fax: 408-495-1100 4301 Mission College Blvd. Email: [email protected] Santa Clara, CA 95052

DATE: May, 2002 ` DISTRIBUTION TO: TIA TR-41.4

The contributor grants a free, irrevocable license to the Telecommunications Industry Association (TIA) to incorporate text contained in this contribution and any modifications thereof in the creation of a TIA standards publication; to copyright in TIA's name any standards publication even though it may include portions of this contribution; and at TIA's sole discretion to permit others to reproduce in whole or in part the resulting TIA standards publication. PN-3-4726

IP Telephony Support For Emergency Calling Service

Formulated under the cognizance of TIA Subcommittee TR-41.4, IP Telephony Infrastructure and Interworking Standards

With the approval of TIA Engineering Committee TR-41, User Premises Telecommunications Requirements PN-3-4726 (to be published as TIA/EIA/TSB-xxx TABLE OF CONTENTS

1. INTRODUCTION...... 3 2. SCOPE...... 4 3. REFERENCES...... 6 3.1. Informative References...... 6 4. DEFINITIONS, ABBREVIATIONS AND ACRONYMS...... 8 4.1. Abbreviations and Acronyms...... 8 5. REGULATORY CONSIDERATION...... 9 6. VOICE OVER IP NETWORKS...... 10 7. REQUIREMENTS SUMMARY...... 11 7.1 Basic...... 11 7.2 Dialing...... 11 7.3 Originating Call Blocking...... 12 7.4 Alternate Routing...... 12 7.5 Attendant/Staff Notification...... 12 8. SOLUTIONS...... 13 8.1. Determining Caller Location...... 13 8.1.1. Network Based Solutions to IP Telephony Caller Location...... 13 8.1.1.1 Enterprise Application (with Call Agent)...... 13 8.1.1.1. 1 SNMP Basic Components...... 14 8.1.1.1.1.1 Managed Device...... 14 8.1.1.1.1.2. Agent...... 14 8.1.1.1.1.3. Network Management System (NMS)...... 14 8.1.1.1.2. Call Agent...... 15 8.1.1.1.3 Location Information Server (LIS)...... 15 8.1.1.1.3.1 Location Information (LIS) Configuration...... 15 8.1.1.1.4. Operation...... 16 8.1.1.1.5. Enterprise Wide-Area Network...... 22 8.1.1.1.6. The Transient User...... 22 8.1.1.2 Centrex Application (Hybrid Approach)...... 22 8.1.2. Set-based Solutions...... 24 8.1.2.1. Architecture...... 25 8.1.2.2. Positioning Beacon...... 25 8.1.2.2.1. Beacon Signaling...... 25 8.1.2.2.1.1. Bluetooth...... 25 8.1.2.2.1.2. GPS...... 26 8.2. Location Information Format...... 26 9. RELATED ACTIVITIES...... 27

1 PN-3-4726 (to be published as TIA/EIA/TSB-xxx)

FOREWORD

This Telecommunication System Bulletin (TSB) contains information concerning IP Telephony support for Emergency Calling Service (ECS), better known as Enhanced 911 in US and Canada. It addresses calls placed from IP Telephone terminal connected to an Enterprise IP. This document prepared by subcommittee TR-41.4 (IP Telephony Infrastructure) of TIA. A TSB is not an industry standard, and compliance with its contents in not mandatory. This information is an extension to the current TIA/EIA 689 – 1997, for IP Telephony support of ECS. We encourage parties with additional information or contrary views to contact us so that all concerns may be addressed in an open process.

2 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) 1. Introduction

This TSB reviews the problems that must be solved to support Emergency Calling Service from IP Telephony terminals connected to an Enterprise IP network. It addresses various Enterprise Network (EN) topologies, and describes possible solutions.

The ECS in US and Canada is known as E911. An explanation of how E911 calling works may be found in TSB103-1993 [Reference 1]. That TSB provided information that was used to develop TIA/EIA-689-1997 [Reference 2], a standard for PBX and KTS support of enhanced 911 calling. But, that standard was written before IP Telephony was a practical consideration. This TSB provides information that should be useful in addition to referenced standards.

IP Telephony, sometimes called Voice-over-Internet-Protocol (VoIP), is a new and evolving technology. When an EN allows IP Telephony, it must solve the same E911 support problems faced by conventional telephony. It must have the capability of determining the caller's location and call back number, routing the call to the appropriate Public Safety Answering Point (PSAP), and conveying the location and call back information to that PSAP. But, IP Telephony must use new solutions to accommodate its unique features.

3 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) 2. Scope

This TSB covers issues associated with support of ECS from IP Telephony terminals connected to an Enterprise Network (EN). It describes new network architecture elements needed to support ECS, and the functionality of those new elements. Many countries have similar ECS requirements. Portions of this document may be applicable in providing solutions for those requirements.

This TSB addresses ECS calls placed from fixed, mobile, remote dial-in, or wireless access VoIP terminals, as shown in Figure 1. This figure also illustrates similar access scenarios for ECS calls placed directly through an ISP. Solutions contained within this TSB may apply to the non-enterprise environment as well. This TSB does not address scenarios for devices connected to VoIP networks through gateways.

Many ECS support issues will require further investigation, and are beyond the scope of this document. These include for example:

 Dialing procedures  Call Reliability  Call set-up delay  Call queuing  Calling feature override (e.g. call forwarding, call waiting, call conferencing, caller ID suppression, and do not disturb.)  Access by persons with disabilities (e.g. TDD devices and support of Total Conversation [See Reference x})  Language-based call routing  Use of a Private Safety Answering Point  Transmission of supplementary call data (e.g. biometrics)

remote user vpn

Internet Service Provider

Telephone fixed local ALI terminal PSAP 'A' Database Terminal

1 SS Router /D A PSTN M Mobile User Enterprise IP A Network C E911 Tandem Switch Telephone ALI Public PSAP 'B' Database Gateway Switched Terminal Telephone Network

Wireless User

Telephone ALI PSAP 'C' Database remote user Terminal vpn

Figure 1 - ECS Network configuration

5 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) 3. References

The following standards and TSBs contain provisions, which are referenced in this document. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this document are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. ANSI and TIA maintain registers of currently valid national standards published by them.

1. PBX and KTS Support of Enhanced 9-1-1 Calling Service, EIA/TIA TSB 103, November 1993.

2. PBX and KTS Support of Enhanced 9-1-1 Emergency Service Calling, TIA/EIA-689-1997.

3. Network Interfaces for E9-1-1 and Emerging Technologies, NENA Technical Information Document, Issue 2.0, February 18, 2001

4. 5. TAPI (Telelephony API)

6. JTAPI (The Java Telephony)

7. Lightweight Directory Access Protocol (v3), (http://www.ietf.org/internet-drafts/draft-ietf- ldapbis-protocol-02.txt

8. SNMP Management Frameworks, RFC 2271 (http://www.ietf.org/rfc/rfc2271.txt?number=2271)

9. SNMP Message Processing and Dispatching, RFC 2272 (http://www.ietf.org/rfc/rfc2272.txt?number=2272)

10. SNMPv3 Applications, RFC 2273 (http://www.ietf.org/rfc/rfc2273.txt?number=2273)

11. SNMPv3 User-based Security Model (USM), RFC 2274 (http://www.ietf.org/rfc/rfc2274.txt? number=2274)

12. SNMP View-based Access Control Model (VACM), RFC 2275 (http://www.ietf.org/rfc/rfc2275.txt?number=2275)

13. Definitions of Managed Objects for Bridges, RFC 1493 (http://www.ietf.org/rfc/rfc1493.txt? number=1493)

14. Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions, RFC 2674 (http://www.ietf.org/rfc/rfc2674.txt?number=2674)

15. Emergency Calling Service (ECS), ANSI T1.628, August 1999

3.1. Informative References

1. TIA/EIA 464B-1996 2. T1.607/t1.628, T1.411 CAMA 3. NENA model Legislation 4. Providing Emergency Call Services for SIP-based Internet Telephony, Internet Engineering Task Force, Internet-Draft, draft-schulzrinne-sip-911-00.txt, July 13, 2000 (Work in Progress)

5. International Telecommunications Union-Telecommunications (ITU-T) specification H.323, Series H: Audiovisual and Multimedia Systems: Packet-based multimedia communications systems, March 1999 6. NENA Technical Information Document on Network Interfaces for E9-1-1 and Emerging Technologies, Issue 2.8, December 4, 2001, plus changes for draft Issue 2.9.

7 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) 4. Definitions, Abbreviations and Acronyms

For the purposes of this TSB, the following definitions, abbreviations and acronyms apply.

4.1. Abbreviations and Acronyms Abbreviations and acronyms, other than in common usage, are defined below.

ALI Automatic Location Identification ATIS Alliance for Telecommunications Industry Solutions CF Call Forwarding CW Call Waiting CID Caller Identification CLID Calling Line Identification DND Do Not Disturb DNS Domain Name Service ERL Emergency Response Location E911 Enhanced 911 Emergency Service Calling ELIN Defined by NENA, a valid North America Numbering Plan format telephone number EN Enterprise Network ERL Defined by NENA, location to which ECS response team may be dispatched FCC Federal Communications Commission ITU International Telecommunications Union IETF Internet Engineering Task Force IP Internet Protocol KTS Key Telephone System LAN Local Area Network LIF Location Interoperability Forum LIN Location Identification Number LIS MGCP Media Gateway Control Protocol NENA National Emergency Number Association PBX Private Branch Exchange PSAP Public Safety Answering Point

PSTN Public Switched Telephone Network SIP Session Initiation Protocol SNMP Simple Network Management Protocol TDD Telecommunications Device for the Deaf VoIP Voice over Internet Protocol WAN Wide Area Network

8 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) 5. Regulatory Consideration

In 1994, the Federal Communications Commission (FCC) proposed regulations requiring PBX and KTS support of E911 calling. But, the proposed regulations were impractical, and subsequently withdrawn.

In the absence of federal regulations, many States, including Washington, Texas, and Illinois, enacted such legislation. But the regulations varied considerably, and applied only to selected installations, most notably schools and shared tenant buildings.

An ad hoc group was formed under the auspices of the National Emergency Number Association (NENA), and given the responsibility to develop "model Legislation" for the support of E911 calling by MLTS installations. That legislation contains compromises on many controversial issues, and specifically exempts IP Telephony support of E911 until two years after appropriate standards for such support are developed.

The model legislation has been approved by NENA, and will be forwarded soon to State legislatures and the FCC for consideration.

The design of the current public 911 networks are such that each political region consists of it’s own network. These regional networks do not communicate with all other 911 networks, therefore if an emergency call arrives at the wrong PSAP, the PSAP operator may not be able to transfer the call to the proper PSAP. It is this design dilemma that will cause an enterprise customer to locate a VoIP E911 gateway in every 911 political region that VoIP terminals are located for that enterprise. This restriction may be removed when the public networks are enhanced in the future.

9 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) 6.

10 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) 7. Voice over IP Networks

Voice-over-IP (VoIP) enables carrying voice traffic (for example, telephone calls and faxes) over an IP network. This support is implemented using voice packet technology. In VoIP, the digital signal processor (DSP) segments the voice signal into frames and stores them in voice packets. These voice packets are transported using IP in compliance with one of several signaling specifications. The signaling specifications include, but not limited to, The International Telecommunications Union- Telecommunications (ITU-T) specification H.323, the specification for transmitting multimedia (voice, video, and data) across a network; the Internet Engineering Task Force (IETF) RFC 2543, SIP: Session Initiation Protocol; the IETF RFC 2705, Media Gateway Control Protocol (MGCP); or the ITU-T Megaco specification. Because VoIP is a delay-sensitive application, you need to have a well-engineered, end-to-end network to successfully use VoIP. Fine-tuning your network to adequately support VoIP involves a series of protocols and features to improve quality of service (QoS). Traffic shaping considerations must also be taken into account to ensure the reliability of the voice connection.

Enterprise customers are implementing VoIP networks to decrease the costs associated with maintaining multiple networks and increase productivity as new applications are brought to market extending the application of voice communication.

11 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) 8. Requirements Summary

7.1 Basic

For an Enterprise IP network to properly support ECS, it must achieve the following: Identify the location of ECS caller and dispatch help to correct location within a limited time.

 Connect the ECS call to the appropriate PSAP jurisdiction. The correct PSAP is usually the one nearest the caller.

 Call back Information – Provide correct number for calling back the ECS caller in case the call is disconnected.

 Additional capabilities also may be required:

o holding the ECS calls up until disconnected by PSAP ringback

The key to supporting the first two requirements is EN determination of the caller's location, regardless of the terminal access scenario (See Figure 1). The key to supporting the last requirement is provision of a PSTN call back procedure to an IP Telephony terminal.

7.2 Dialing

The IP Network should allow a user to dial 9-1-1 without having to dial a “trunk-access code” or other code to access the public telephone network. This code is typically the digit 9, but sometimes others are used, such as *9 (star-nine). The IP Network should be capable of properly routing ECS calls, whether or not the 9-1-1 digits are preceded by a valid outgoing trunk-access code. The IP Network should recognize the dialed digits, 9-1-1 and (trunk-access code)-9-1-1, as quickly as possible, ignoring any interdigital time-out interval that may be used to determine the end of address signaling when fewer than a prescribed number of digits are dialed.

7.3 Originating Call Blocking

Businesses may administer their IP Network to block outgoing calls from certain telephones. This blocking may prevent all originating calls or only those to the public telephone network. The IP Network should be capable of supporting 9-1-1 calls from these telephones without compromising the protection afforded by “originating call blocking” features.

7.4 Alternate Routing

It is possible that the IP Network may have several distinct ways to reach the appropriate PSAP for an ECS call. Examples are:

 Multiple ECS trunk groups, e.g., both ISDN and 911 CAMA, equipped at the same Gateway.

 Multiple Gateways having ECS trunk groups that can route calls to the same PSAP.

Alternate routing to other appropriate ECS trunk groups should be possible when a call encounters out-of-service or busy trunk groups.

7.5 Attendant/Staff Notification

Many campus environments, hotels, military installations, and large businesses have on-premises personnel who need to know when a 9-1-1 call is dialed from an IP telephone. They need to know the number and location of the telephone from which the call was dialed. These personnel are frequently able to assist a caller, and in many cases help the emergency response team quickly locate the caller. The IP Network should be capable of alerting an attendant or other staff personnel to provide calling station and location information when an ECS call is originated. Because many installations have automated entry means, e.g., badge readers, used both during working and non- working hours, it should be possible to send the Attendant/Staff Notification to the same location, when staffed, and to a (centralized) staffed location so that they can arrange to have someone at the remote installation when the emergency response team arrives.

Conferencing of the attendant/staff into the ECS call is not required. Some jurisdictions prohibit attendant "bridge-on" to a 9-1-1 call because this has created some confusion for the answering PSAP agent.

13 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) 9. Solutions

As was stated earlier, the key ECS requirements are determining the location of ECS caller, routing the call to the appropriate PSAP and providing a callback number to the PSAP.

8.1. Determining Caller Location

Cellular and wireless have addressed the issue of location discovery for the past few years and are ahead of IP industry for identifying the location of ECS caller as well as supporting the new Location Based Services (LBS). IP telephony issues are more complex, however, similar approach may be applicable.

In the Cellular domain, there are two basic types a of technology alternatives for locating mobile phones: network-based and handset-based. The latter builds intelligence into the handset to achieve location discovery and largely uses GPS, the former builds more intelligence into the mobile network infrastructure for calculating the handset’s position. The most common technology for network-based is triangulation which is based on radio signal measurement, e.g. timing or angle of signal transmission and reception at the handset (E-OTD, TOA) and Cell Of Origin (COO) information.

For IP Telephony location discovery a parallel approach could be taken, as follow:

 Network-based solution – uses network management protocol (SNMP Trap) to discover location of the end-point devices. This provides capability for locating devices connected to a switched LAN. This method does not address the hub LAN.  Handset-based solution – uses handset devices such as Beaco in conjunction with GPS or Bluetooth, to identify the location of the IP device.

There are advantages to each location mechanism. The decision to utilize either technology will be determined by the complexity of the end-user network/voice application.

Table 1 Network-Based and Set-Based Comparison Attribute Network-Based Solution Set-Based Solution simple administration more administration required less administration required new set-based hardware required no yes emergency call server required yes yes vendor time to market quick longer – new hardware required Supports all types of voice No – cannot accurately Should be able to handle all terminals located a wireless set – only types of handsets. Fixed, to wireless base station. wireless, etc. Interworking with Cellular No Should be able to handel

8.1.1. Network Based Solutions to IP Telephony Caller Location 8.1.1.1 Enterprise Application (with Call Agent)

IP networks and their underlying technologies have over time evolved to a well-known industry standard management protocol, Simple Network Management Protocol (SNMP). SNMP was developed in 1988 and has become the de facto standard for internetwork management. The requirements that SNMP have on network entities is small, therefore vendors of network hardware can implement SNMP relatively easy. SNMP is extensible, allowing vendors to add the necessary network elements for their respective products. SNMP employs an architecture that removes the

14 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) management from the hardware devices, which allows for wide acceptance from manufacturers. SNMP is widely implemented and supported by most vendors of networking equipment. This discussion of Network Based Caller Location relies on SNMP being deployed, and in some instances, customized, in all Ethernet Switch devices within a network.

SNMP has gone through several updates, and the current version, SNMPv3 and its architecture are defined in RFC 2271 thru RFC 2275. SNMPv3 is backward compatible with earlier versions of SNMP. The most wide deployed version of SNMP in use today is SNMPv2, as most vendors are now developing products to be compatible with SNMPv3. SNMPv3 basically adds authentication, privacy, authorization and access control to the earlier versions. These enhancements deal with the way SNMP data is handled and does not interfere with the basic function of SNMP, the gathering of data pertinent to the health of a network. It is this data that we are interested in, as we can ascertain the physical location of a network node, given a few preliminary procedures.

8.1.1.1. 1 SNMP Basic Components There are three key components of an SNMP managed network:

8.1.1.1.1.1 Managed Device

A managed device is a network node that contains an SNMP agent and resides on a managed network. Managed devices collect and store management information and make this information available to network management systems (NMSs) using SNMP. Managed devices, sometimes called network elements, can be routers and access servers, switches and bridges, hubs, computer hosts, or printers, etc.

8.1.1.1.1.2. Agent

An agent is a network management software module that resides in a managed device. It has local knowledge of management information and translates that information into a form compatible with SNMP.

8.1.1.1.1.3. Network Management System (NMS)

An NMS executes applications that monitor and control managed devices. They provide the bulk of the processing and memory resources required for network management. One or more NMSs must exist on any managed network.

For the purposes of IP Telephony device location, it is assumed that the vendor of Ethernet network switches used in a modern IP network, a network that includes advanced applications providing Voice communication, has implemented SNMP Agents in their devices to the extent that they support IETF RFC 1493 and RFC 2674. These Bridge MIBs will allow the forwarding table that tracks Ethernet MAC address to port assignments to be polled by a Network Management System (NMS) entity. An additional feature needed would be the ability to generate SNMP traps to a NMS based upon the addition or deletion of Ethernet devices on the network. This trap mechanism is outlined in RFC 2863, The Interfaces Group MIB. Otherwise stated, the Network Based Solution to IP Telephony Caller Location utilizes the Ethernet Switch MIB object to poll the bridge forwarding table and the trap function allowing for real-time updates of Ethernet device moves-adds-changes. It is recommended that the polling of the Forwarding Table only happen during off-peak hours as this process could take a considerable amount of time in a large network. This SNMP information will be used by the Location Information Server (LIS) to cross reference with a database to determine host location, which then can be used for deriving proper PSTN gateway and port and calling number information.

Figure 2 - shows the relationship between these three components:

8.1.1.1.2. Call Agent

A Call Agent or Server for the purpose of this discussion, is defined as the routing intelligence within an IP Telephony network. Depending on the underlying protocol technologies used, a Call Agent would perform tasks ranging from simply performing an E.164 to IP address resolution, all the way to transcoding the actual media stream from one compression algorithm to another. Other uses of Call Agents include providing a control point for all calls both within and outside of the Enterprise network. It is believed that most implementations currently use a Call Agent. Although it is possible to employ intelligent end devices that do not require the use of a Call Agent, it is believed that most Enterprise IP Telephony systems will be designed utilizing Call Agents. Populating end devices with enough network knowledge to survive without using a Call Agent would not be practical with today’s technology.

8.1.1.1.3 Location Information Server (LIS) The location Information Server (LIS) is an ECS entity that in conjunction with wiremap information automatically associates an IP device to its physical LAN jack within an enterprise. The LIS provides the location information in a appropriate format (This could be either geodetic latitude/longitude representing the position of the physical jack, or detailed address information, for examples.) for inclusion in the PSAP ALI database. Or alternatively, provides the DID number of the emergency caller for conversion into a physical address by the PSAP database.

LIS may be deployed as a separate entity or combined with other ECS functionalities. The LIS interfaces with Call Agent providing database support to maintain various type of location information necessary to query “911” calls, including PSAP jurisdiction, ANI and ALI. Also, Automatic database updates and maintenance to accommodate IP Phone moves and address changes.

The LIS will interface with the Call Agent via LDAP or TAPI.

8.1.1.1.3.1 Location Information (LIS) Configuration

Generally, each enterprise maintains and administers its own local LIS. Once a new association has been made between a switch port number and physical location, the Local LIS may upload location information updates to the PSAP ALI DBMS.

To reduce the number of enterprises interfaces that must be supported by the ALI DBMS, a Network LIS may be deployed as a “front end” to collect the updates from a number of Local LISs as they occur and upload to the ALI DBMS. This is illustrated in Fig 3. The Local LIS sends updates to the Network LIS as changes occur. The Network LIS should provide the IP security functions of authenticating the sources. Either the Local LIS or the Network LIS could perform the functions of validating contents and formats of the information provided by the Local LISs. If not supported by the Local LIS, the Network LIS could provide the functions of converting from a standard NENA data exchange format received from the Local LISs to a standard format supported by the ALI DBMS.

Updates can be uploaded from the Network LIS to the ALI DBMS on a periodic scheduled basis or alternatively network to query the Network LIS for updates as desired. Then, when an emergency call is originated from an IP device in the Enterprise and routed through the network, the Automatic Number Identification (ANI) information can be populated with the Calling Party Number of the emergency caller’s IP device. With periodic scheduled updates, normal network procedures for updating selective routing information can be followed. PSAP callback calls can also be terminated normally to the IP device via the Callback Number provided as ANI with the emergency call, without any qualifications about how long the number can be available for callbacks. With this approach, ELINs do not have to be allocated for location information / callback numbers, preserving DN resources. Existing selective routing and ALI DBMS procedures can be used, although a trend toward more frequent updates of selective routing information from the ALI DB would improve the probability that location information would be up-to-date, and emergency calls from IP Enterprise networks properly routed.

In some IP Centrex architectures, the Local LIS may not be aware of the TN associated with the IP device. In these architectures, it is assumed that the Local LIS is aware of a unique identifier for the IP device, for example, a global IP address or an H.323 “alias”, that it can use to derive the TN. (H.323 is a specification for transmitting multimedia [voice, video, and data] across a network, and is used in some VoP networks.) If the Local LIS does not provide the correlation between the unique identifier for the IP device and the TN, then it is assumed that the Network LIS will need to be configured with information to correlate this unique identifier with a TN that will be sent as the Calling Party Number when an emergency call is originated from that IP device. For IP devices that support more than one TN, it is assumed that these devices will send its primary TN to the Local LIS for correlation with location, and the “primary TN” will be used as the Calling Party Number on emergency calls. This is similar to an approach supported by ISDN telephones that support more than one directory number. (The IP device may also include a list of “non-shared” TNs when sending the primary TN to the Local LIS, if desired. A non-shared TN is only used for calls to/from one device.)

Enterprise LAN Network A Local PS-ALI ALI LIS Network DBM LIS PS-ALI LEC Packet Enterprise LAN Network Network B ALI – Automatic Location Identification Local DBM – Data Base Manager LIS LAN – Local Area Network LEC – Local Exchange Carrier LIS – Location Information Server PS-ALI – Private Switch ALI interface

Figure 3. Automatic Upload of Location Information

8.1.1.1.4. Operation

The database that resides on the LIS will include all data required to properly route the 9-1-1 calls. The information to properly derive a user’s location, decide which route (gateway) to utilize, and keep all pertinent 9-1-1 related information may be stored on the LIS. An example of this type of data base is shown in the tables below.

Table 1 below shows the correlation between wall jack location, Ethernet switch port, IP address, telephone number, ELIN, and emergency services zone.

Table 2. LIS Data Base END USER ETHERNET IP PHONE IP TELEPHON ELIN ESZ JACK SWITCH/POR MAC ADDRESS E EMERG. NUMBER T ADDRESS NUMBER SRV. ZONE 2A57 SW16/73 Abc067854dea 10.1.1.26 408-555- 408-555- 124 6789 1212 4F98 SW07/19 e10f4598d3ba 10.6.3.2 408-555- 408-555- 348 5378 1234 3Z103 SW113/147 e10f4597ab6f 192.168.2.1 5467 408-555- 763 7564

Column 1 Column 2 Column 3 Column 4 Column 5 Column 6 Column 7

The major function of the LIS will be to gather all pertinent information, then match the IP/MAC address to a particular Ethernet switch port. When this is done, the location of the physical user will be known. During normal operation of the Enterprise network, columns 1-2-6-7 will stay constant and associated with each other. The dynamic information will be columns 3-4-5, derived by the LIS

18 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) via communication with the Call Agent and matched to the other group of columns via the MAC address to Ethernet switch port polled via SNMP from the various switches. Column 1 – This static entry that will be a physical inventory of wall jack identifications that an IP telephony device could be connected to. Column 2 – This is static entry that shows Ethernet switch and port number corresponding to the wall jack. This information is derived manually and entered into the database. This information will need to be updated as wire closet patch cords are rearranged. For purposes of database stability, it is recommended that a set of Ethernet switch ports be used for IP telephony devices. These ports should be marked in the wire closet to discourage rearrangement of this jack to port pairing. The goal is to keep changes to this database to a minimum. Column 3 – This is the Ethernet MAC layer address for the IP telephony device. This information is derived either via communication with the Call Agent, by examining the arp cache within the local machine (LIS), the arp cache of the default router for the subnet the telephony device resides on or directly from the VoIP terminal. When matched with the SNMP data gathered from the Ethernet switches, this data can be placed properly into the database. Column 4 – This is the IP address of the IP telephony device, derived via communication with the Call Agent. Column 5 – This is the known telephone number for the IP telephony device, derived via communication with the Call Agent. It is not required that this number be a valid E.164 address.

Column 6 – This is the ELIN to use for the Emergency Response Location (ERL) that the IP telephony device currently resides in. The LEC is responsible for the issuing of ELINs to individual customers, but it is the end-user’s responsibility to assign the ELINs to the ERLs. The local fire officials, prior to being submitted to the ALI database, should approve this ELIN/ERL assignment. It is possible to have multiple ELINs per ERL. This information is derived manually for each wall jack location. The administrator of the IP telephony system must decide what ERL to place each wall jack in, then manually assign at least one ELIN to each ERL. It is this ELIN to ERL description that is eventually supplied for the PSAP ALI database.

Column 7 – This is the Emergency Service Zone that will stay constant with the ERL. This number should be used as a routing identifier for the Call Agent for proper outbound gateway selection.

Table 2 is the ELIN to ERL mapping. This information is supplied to the service provider that maintains the ALI database for the PSAP. It is suggested that the LIS provide an automatic mechanism to transmit this information to the service provider. Geodetic location information is an upcoming feature that PSAPs will use for location purposes and is shown for future use.

Table 3. ELIN to ERL Mapping ELIN ERL GEODETIC LOCATION INFORMATION 408-555-1212 170 W. Tasman Dr., 3rd floor, NW corner 408-555-1234 170 W. Tasman Dr., 2nd floor, SE corner 408-555-5432 170 W. Tasman Dr., 4th floor, room 415

Table 3 is used by the LIS for the purpose of understanding the IP address scheme within an Enterprise network. This table is derived manually by the administrator and needs to be changed only when the IP addressing/routing structure within the organization changes. This table will be used by the LIS when the Call Agent does not maintain knowledge of the MAC layer address for an IP telephony device.

Table 4. IP Address/Router resolution

START IP ADDRESS END IP ADDRESS DEFAULT ROUTER 10.1.1.1 10.1.1.254 10.1.1.1 10.6.3.1 10.6.3.254 10.6.3.1

After the manual portion of the database is built, the goal is for the day-to-day administration to be kept to a minimum. The dynamic piece of the database will be that of IP telephony users relocating their devices from one to another jack across campus or across the Enterprise network to a different location. This relocation will be captured via the LIS that maintains constant communication with both the Call Agent and the Ethernet switches.

The LIS will poll the

Fixed Telephone SNMP Agent in each Mobile User fixed local terminal Ethernet Switch for it's Forwarding Table Fixed Telephone As well, the SNMP Agent in each switch must notify the LIS when Router Ethernet stations connect Fixed Telephone Switch and disconnect from the network. Ethernet Switch

Gateway remote user dial-in vpn Ethernet Switch

Location Information Server Wireless User

Fixed Telephone fixed local terminal Figure 4 –LIS Logical Processing

Figure 4 shows the logical process of the LIS communicating with the SNMP agent within the Ethernet switches to gather both a full forwarding table and random MAC address changes as ports are disconnected and connected.

SNMP data utilizes UDP as a transport mechanism that results in the non-guarantee of delivery. Although lost packets are not common in a IP network, a periodic gathering of all MAC address to port information would be used to ‘sanitize’ the database and ensure that any information missed due to lost packets is recovered.

Fixed Telephone Mobile User fixed local terminal

Fixed Telephone

Router

Fixed Telephone S te Ethernet p Switch 3 Ethernet 2 Switch p

S Gateway remote user dial-in vpn Ethernet Switch

ep 1 St Call Agent

Location Wireless User Information Server Fixed Telephone fixed local terminal

Fig 5 – LIS Communications

Figure 5 - shows the communication between the LIS and the Call Agent, IP Telephony device, and the default router associated with the telephony device. This communication is for the purpose of maintaining the database.

Step 1 - The LIS will poll the Telephony device information from the Call Agent. Expected response is the telephone number matched with either MAC address or IP address or both.

Step 2 – If the Call Agent does not return the MAC address of the Telephony device, other means can be used to derive this address. If the LIS resides on a different IP subnet from the Telephony device, the arp cache of the router for that particular IP subnet could be polled to gather the MAC address.

Step 3 – The LIS could send a ping to the Telephony device resulting in populating it’s own arp cache with the IP to MAC address information. The LIS would then examine it’s own arp cache to gather the needed MAC address of the Telephony device.

Fixed Telephone

Router S Fixed Telephone te Ethernetp Switch1

Ethernet Step 4 Switch CAMA/ISDN

Gateway remote user dial-in Step 3 vpn Ethernet Switch Step 2 Call Agent

Location Wireless User Information Server Fixed Telephone fixed local terminal

Figure 6 - 911 Call Progression Fig 6 shows the steps taken when a user calls ECS

Step 1 – the user dials 9-1-1

Step 2 – The Call Agent supplies the LIS with the information about the user, user IP address or telephone number. The LIS returns to the Call Agent the ELIN and ESZ associated with the user.

Step 3 – the Call Agent uses this ELIN/ESZ information to make a gateway/port choice for this user.

Step 4 - The call Agent instructs the gateway to setup the call using the ELIN for the calling number field (ANI) instead of the caller’s telephone number.

8.1.1.1.5. Enterprise Wide-Area Network The typical Enterprise Wide-Area Network should be designed the same for 9-1-1 purposes as the Call Agent layout. If a Call Agent at headquarters is used for IP telephony devices at a remote

22 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) location over the WAN, then the LIS located at headquarters should also control the 9-1-1 calls at the remote location. Since SNMP is IP based, deriving the location of IP devices across a WAN link will operate the same as it does on a local network. Therefore, a single LIS can operate multiple remote locations. A remote location that resides outside the political boundaries of the headquaters location would most likely require it’s own PSTN gateway for calls to 911. This is due to the nature of the PSTN 911 networks; they are regionalized with no/limited capabilities to pass calls between political areas. In this case, the LIS would simply advise the Call Agent to direct the 911 call out the respective gateway at the corresponding remote location.

8.1.1.1.6. The Transient User

Several issues arise when contemplating a user that has a Telephony device installed in a laptop computer, or other portable device, and uses that device to call ECS when connected to the Enterprise network in any of several different fashions used today. This would include users dialing in via modem from a remote location like home, airport, hotel, etc. This would include users dialing in via a 3rd party service provider or users connecting via Virtual Private Network utilizing one of many services offered today. The ability to derive the physical location of this user is not a capability of the Network Based Solution discussed here. This coupled with the ‘local design’ of the public ECS network, restricts the ability to provide this service in those scenarios.

It is recommended for the above scenarios that enterprises advise end-users that this functionality will not be supported. As an alternative, the enterprise could receive the ECS call via an internal answering point, but would then take on the responsibility of assisting the end-user with getting emergency help. This action may be beyond the scope of the enterprise’s desired responsibilities. It is within the regulatory realm to identify telephony terminals as ‘not able to call 911’, which may be the best solution for this situation.

8.1.1.2 Centrex Application (Hybrid Approach) An alternative approach for the association between the IP device and the physical location information uses many of the same principles and procedures of the approach described in Section 8.1.1.1 This approach introduces additional functionality in the IP devices and the Location Information Server on the enterprise customer’s LAN, but it does not require the participation of a Call Agent, or as much polling activity on the LAN for the location discovery process.

It is assumed that the IP Enterprise will support a Local LIS that is administered by the Enterprise, and configured with wiremap data that provides the association between physical jack locations and location information, as described in Section 8.1.1, with the exception that it is assumed that the location information is of a form appropriate for inclusion in the ALI Data Base. (This could be either geodetic latitude/longitude representing the position of the physical jack or port, or detailed address information, for example.)

It is assumed that the local Enterprise network will support SNMP procedures that allow the MAC Address of an IP device to be automatically associated with the location information that corresponds to a physical location that is associated with the indicated LAN switch port ID, as described in Section 8.1.1.

In this approach, the Ethernet switches and the Local LIS on the Enterprise LAN follow the procedures described in Section 8.1.1 for trapping the MAC Address of an IP device and associating that MAC Address with a port ID and associated location information in the data base on the Local LIS. The following new requirements are placed on the IP devices:

 The IP devices on the Enterprise LAN should be able to be configured automatically with the IP address of the Local LIS, e.g., via a configuration server (could be a DHCP or TFTP server, for example).  After an IP device is moved to a new location (plugged in to a physical jack) and is registered with the serving network, the IP device must signal its MAC address and its Telephone Number(s) to the Local LIS. This could be done via a TAPI application, or possibly via a “call” to the Local LIS. (If an IP device is configured with more than one TN, it must send a particular TN, its “primary TN”, to the Local LIS for identification purposes, and the primary TN should be used for emergency calling. The IP device may also send a list of its non- shared TNs to the Local LIS, if these can be used to originate emergency calls. However, a TN that is shared by multiple devices should not be sent to the Local LIS or used for emergency calling, unless that TN is the primary TN for the IP device.) When the Local LIS receives the MAC address and TN of the IP device, it can make the association between that TN and the location information that corresponds to the MAC address. Note that in some public network based architectures, the IP device may not be aware of the TN associated with the IP device. In these architectures, it is assumed that the IP device is aware of some unique identifier for the IP device, e.g., one used in Local Exchange Carrier (LEC) service provisioning. This could be, for example, an “alias” for the TN. In such cases it is assumed that one of the following two solutions will be implemented:  The Local LIS will be able to derive a TN from the unique identifier, or the Local LIS will be provisioned with information to correlate the unique identifier with a TN.  A network functional element will need to be provided by the LEC network that will be configured to provide the correlation between the IP device’s unique identifier and a TN. LIS processing is as shown in Figure 3 in Section 8.1.1. The following figure illustrates the steps in determining location information.

Fixed Telephone Step 1

Router Configuration Ethernet Server Fixed Telephone Switch

Ethernet Switch Step 2

Gateway remote user dial-in vpn Ethernet Switch

Location Information Server Wireless User

Fixed Telephone fixed local terminal “Figure 7. Hybrid Approach – IP Device and LIS Communications” Figure 7 - shows the communication between the IP Telephony device and a configuration server, and between the LIS and the IP Telephony device. This communication is for the purpose of maintaining the database.

Step 1 -- The IP Telephony device will obtain the IP address of the LIS from a configuration server, upon connection and/or registration with the gateway. The IP device is provisioned with a unique identifier, either a Telephone Number, or an identifier from which the Telephone Number (TN) can be derived

Step 2 -- The Telephony device signals its MAC address and its unique identifier to the LIS. (The Local LIS should be able to accept more than one such identifier/TN from a device, and be able to associate each with the provided MAC address and location.)

8.1.2. Set-based Solutions An advantage of IP sets is that they can be moved without any administrative intervention. This allows user freely to roam among various networks such as IP, cellular and wireless. Also, telecommuters, working from home, hotel room or airport connected (tunneled) to their corporate network via an ISP (DSL, Cable or Wireless LAN).

In these cases, the Set-based solution eliminates some of the limitation and complexity of the Net- based solution. The Set-based uses the networks only for carry the data stream to and from the positioning device. If the network has hub configuration, dynamically changing or the adjacent networks do not deploy compatible solution, positioning becomes very difficult, complicated and inaccurate.

One other issue of importance is privacy. The Net-based solution provides the service provider capability to maintain a data base location for commercial proposes. The information then can be sold to the location-based-service provider without user having any control over it. On the other hand, the Set-based solution provides more control to the local network or the user for the transport of their location information to other entities.

8.1.2.1. Architecture

Cellular phones have been deploying Set-based solution for E911 calls for a while. Basically, the VoIP Terminal uses a positioning device, such as GPS, to determine the VoIP Terminal geographical coordinates. The service provider retrieves the physical address from the location parameters and sends it to the appropriate PSAP jurisdiction. A similar concept can be used for IP Telephony. However, the problem is that GPS do not work very well indoor, particularly, in a dense metropolitan environment or in high raise buildings. This problem can be overcome by retrieving the position information from the nearby devices or a beacon, which is accurate, secure and trusted.

8.1.2.2. Positioning Beacon

The beacon is a stationary device, installed at various locations (offices, hotels and homes) separately, similar to the smoke alarm, or integrated into the wall mounted LAN connector. When is activated, by an E911 call from an IP set equipped with the same signaling capability, provides physical location information. The location information provided may be in form of position coordinates or a unique code.

The beacon can be deployed in several ways. For example, it can provide a repeater function for amplifying the GPS timing signals; in a high raise building, from the satellites or inserting the floor number into the GPS signals. Or, it can be programmed to originate and transmit a new timing signal (emulating its physical location coordinates) when activated by an E911 call. The coordinates then are cross-referenced to an actual physical address for PSAP.

8.1.2.2.1. Beacon Signaling

Several options are available for the signaling between beacon and IP Telephony, including: Bluetooth, GPS, and others. When an E911 call is placed a functional entity (E911 server or call server) transmits an activation signal. The nearby beacon becomes activated (if the signaling provides the capability for the control of individual beacon. If not, all the beacons become activated). Once the beacon is activated it transmits its preprogram coordinates or a unique code to the E911 server, which then is mapped into a physical address for PSAP. The beacon(s) is (are) de-activated by the E911 server when the call is answered by the PSAP.

8.1.2.2.1.1. Bluetooth

Bluetooth is a new technology with a very large industry support (over 2100 members). It provides 1 Mbps radio link with a single asymmetric channel at 723 kbps (57k return) or bi-directional 434 kpbs, supporting up to 3 voice (full duplex) channels. Bluetooth range is from 10m to about 100m with capability to connect to any portable and stationary communication devices.

Bluetooth connections are instant and are maintained even when devices are not within line of sight. It provides instant connection to another Bluetooth radio as soon as it comes into range. It supports both point-to-point and point-to-multipoint connections. Several Pico nets can be established and linked together. It supports email, two way messaging, LAN and IP access . Bluetooth is fully functional in noisy environment and data are protected by advance error- correction method, encryption and authentication routine for privacy. For more information see (http://www.bluetooth.com).

8.1.2.2.1.2. GPS

The commercial GPS system determines its location from the satellite timing signals it receives and provides four primary functions: determining the code phases (pseudoranges) to the various GPS satellites, determining the time-of-applicability for the pseudoranges, demodulating the satellite navigation message, and computing the position of the receiving antenna using these pseudoranges, timing, and navigation message data.

Bluetooth Call Location Beacon Server Server PSAP

E911 Call E911 Call Loc. Request Activated Beacon Loc Code Loc. Code

Appropriate Juridiction tel.no.

E911 Call with Embebed Loc & Call back #

E911 call establishment De-activate Transmit ter

Figure 8 – shows the message follow among various components of Set Based Soultion

8.2. Location Information Format One available format is T1.628

Standard encoding WGS84-based coordinates

27 PN-3-4726 (to be published as TIA/EIA/TSB-xxx) 10.Related Activities

Following is a list of forums that are working issues related to the support of E911 calling:

1. The Internet Engineering Task Force (IETF) - especially the SIP-911 working group 2. ITU-T SG 11 - especially the ISUP working group 3. T1, especially committees T1S1 and T1M1 4. The National Emergency Number Association (NENA) - especially the technical requirements and model legislation working groups 5. The Location Interoperability Forum (LIF) - working on standards to support a variety of wireless device location applications. 6. The Public Safety Partnership Project (PSPP) - A joint ETSI/TIA project