Download 1. Introduction - Telecommunications Industry Association

TR41.4-03-11-052
Project :
PN-3-4726-RV1 (To be published as future TIA TSB-146-A bulletin)
Title : IP Telephony Support for Emergency Calling Service
Source :
Alcatel
1 Route du docteur Albert Schweitzer
67408 Illkirch
France
Contacts :
Raymond Gass
Phone : +33 3 90 67 77 02
Fax : +33 3 90 67 70 18
E Mail :[email protected]
Date :
15th October 2003
Contributed to :
TIA TR-41.4
The Source1 grants a free, irrevocable license to the Telecommunications Industry Association (TIA) to incorporate
text or other copyrightable material contained in this contribution and any modifications thereof in the creation of a
TIA Publication; to copyright and sell in TIA's name any TIA Publication even though it may include all or portions
of this contribution; and at TIA's sole discretion to permit others to reproduce in whole or in part such contribution or
the resulting TIA Publication. The Source will also be willing to grant licenses under such copyrights to third parties
on reasonable, non-discriminatory terms and conditions for purpose of practicing a TIA Publication which
incorporates this contribution.
This document has been prepared by Alcatel to assist the TIA Engineering Committee. It is proposed to the
Committee as a basis for discussion and is not to be construed as a binding proposal on Alcatel. Alcatel specifically
reserves the right to amend or modify the material contained herein and nothing herein shall be construed as
conferring or offering licenses or rights with respect to any intellectual property of Alcatel other than provided in the
copyright statement above.
The Source agrees that if the Source has changed or added text to the required language in the TIA contribution
template as contained in the TIA Engineering Manual, any such change or addition which is inconsistent with such
contribution template, is of no force or effect.
1
The owner of the copyright or license right, if any, submitted in the contribution.
Summary:
This contribution includes the following proposals for progressing TSB-146
 Reference for Call Priority in § 2
 New IETF and NENA reference in § 3 and withdraw not used references (e.g. TAPI, JTAPI)
 Text from Marc Linsner in §6
 Call for proposal in § 8.1.4 (transient user), plus a first proposal to be discussed
TSB-146
Telecommunications - IP Telephony Infrastructures IP Telephony Support
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
TIA/EIA/TSB-146
TABLE OF CONTENTS
1.
2.
3.
4.
4.1.
5.
6.
7.
7.1.
7.2.
7.3.
7.4.
7.5.
8.
8.1.
8.1.1.
Introduction............................................................................................................................. 1
Scope ........................................................................................................................................ 1
References ................................................................................................................................ 2
Definitions, Abbreviations and Acronyms ........................................................................... 3
Abbreviations and Acronyms ................................................................................................... 3
Regulatory Consideration ...................................................................................................... 4
Voice over IP Networks .......................................................................................................... 5
Requirements Summary ........................................................................................................ 5
Basic.......................................................................................................................................... 5
Dialing ...................................................................................................................................... 5
Originating Call Blocking ......................................................................................................... 5
Alternate Routing...................................................................................................................... 6
Attendant/Staff Notification ..................................................................................................... 6
Determining Caller Location ................................................................................................. 6
Network Based Solutions to IP Telephony Caller Location ..................................................... 7
SNMP based solution ............................................................................................................... 7
8.1.1.1.
8.1.1.2.
Switch based solution ............................................................................................................................. 7
Midspan remote power source based solution ........................................................................................ 8
8.1.2.
8.1.3.
8.1.4.
8.1.5.
8.2.
8.2.1.
8.2.2.
8.2.3.
9.
9.1.
9.2.
9.3.
10.
DHCP tracker based solution .................................................................................................... 8
Enterprise Wide-Area Network ................................................................................................ 9
The Transient User ................................................................................................................... 9
Centrex Application (Hybrid Approach) ................................................................................. 9
Set-based Solutions ................................................................................................................... 9
Positioning Beacon ................................................................................................................. 10
Beacon Signaling .................................................................................................................... 10
Bluetooth................................................................................................................................. 10
Location Information Format ............................................................................................. 11
Location Information Server (LIS) ......................................................................................... 11
Location Information (LIS) Configuration ............................................................................. 12
Operation ................................................................................................................................ 13
Related Activities .................................................................................................................. 15
i
TIA/EIA/TSB-146
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 terminals connected to an Enterprise IP. This document
was prepared by subcommittee TR-41.4 (IP Telephony Infrastructure) of TIA. A TSB is not an
industry standard, and compliance with its contents is 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.
The TR-41.4 Engineering Technical Subcommittee acknowledges the contribution made by the
following individuals in the development of this document.
Name
Nadine Abbott
Bob Bell
Roger Britt
Tony Caggiano
Dick Frank
Raymond Gass
Richard Hatherill
Marc Linsner
Dorothy Lockard
Joanne McMillen
Kirit Patel
Mo Zonoun,
Representing
Telcordia
Cisco Systems
Nortel Networks
Lucent Technologies
Dietrich Lockard Group
Alcatel
Mitel Networks
Cisco Systems
Dietrich Lockard Group
Avaya Inc.
Cisco Systems
Nortel
Chair
Editor
Suggestions for improvement of this document are welcome. They should be sent to:
Telecommunications Industry Association
Engineering Department
Suite 300
250 Wilson Boulevard
Arlington, VA 22201
ii
TIA/EIA/TSB-146)
1.
Introduction
This TSB reviews the problems that must be solved to support Emergency Calling Service (ECS)
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 provides 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 provides IP Telephony service, 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.
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, call priority interruption [24] and do not disturb.)
 Access by persons with disabilities (e.g. TDD devices)
 Language-based call routing
 Use of a Private Safety Answering Point
 Transmission of supplementary call data (e.g. biometrics)
Please note that using managed, switched infrastructure described in this TSB does not necessarily
provide a solution for the problem of remote access via VPN connectivity. It should be further noted
that the determination of the appropriate PSAP to delivery of the ECS call is not detailed in this TSB.
It also assumes that a sufficient number of local tandem ECS trunk connections exist to allow for a
direct connection to the appropriate PSAP.
1
TIA/EIA/TSB-146)
Mobile
IP Phone
IP Phone
PSAP A
Terminal
ALI
Database
E911
switch
Router
LAN
Agent A
Agent B
PSTN
Agent X
Figure 1, ECS Network Configuration
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.
2. PBX and KTS Support of Enhanced 9-1-1 Emergency Service Calling, TIA/EIA-689-A-.2003
3. Network Interfaces for E9-1-1 and Emerging Technologies, NENA Technical Information
Document, Issue 2.0, February 18, 2001
4.
5.
6. Lightweight Directory Access Protocol (v3), (http://www.ietf.org/internet-drafts/draft-ietfldapbis-protocol-02.txt
7. SNMP Management Frameworks, RFC 2271 (http://www.ietf.org/rfc/rfc2271.txt?number=2271)
8. SNMP Message Processing and Dispatching, RFC 2272
(http://www.ietf.org/rfc/rfc2272.txt?number=2272)
9. SNMPv3 Applications, RFC 2273 (http://www.ietf.org/rfc/rfc2273.txt?number=2273)
10. SNMPv3 User-based Security Model (USM), RFC 2274
11. SNMP View-based Access Control Model (VACM), RFC 2275
12. Definitions of Managed Objects for Bridges, RFC 1493
13. 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)
2
TIA/EIA/TSB-146)
14. RFC 2863 (see § 8.1.1.1)
15.
16.
17. ANSI T1.628-2000, Emergency Calling Service
18. ANSI T1.628a-2001, Emergency Calling Service – Connection Hold and Ringback Addendum
19. ANSI T1.411-2001, Interface between Carriers and Customer Installations - Analog Voicegrade
Enhanced 911 Switched Access Using Network-Provided Reverse-Battery Signaling
20. NENA Technical Information Document, November 2000, Model Legislation, Enhanced 9-1-1
for Multi-line Telephone Systems
21. 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)
22.
23. 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.
24. IETF draft-ietf-geopriv-dhcp-lo-option-00.txt
25. IETF draft-ietf-sip-resource-priority-00.txt
26. IETF draft-polk-sipping-location-requirements-00.txt
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
ANI
Automatic Number Identification
ATIS
Alliance for Telecommunications Industry Solutions
PBX
Private Branch Exchange
CF
Call Forwarding
CW
Call Waiting
CID
Caller Identification
CLID
Calling Line Identification
BDMS
Database Management System
DHCP
Dynamic Host Configuration Protocol
DN
Domain Name
DND
Do Not Disturb
DNS
Domain Name Service
DSP
Digital Signal Processor
ECS
Emergency Calling Service
E911
Enhanced 911 Emergency Service Calling
ELIN
A valid North America Numbering Plan format telephone number
EN
Enterprise Network
ERL
Emergency Response Location
ESZ
Emergency Service Zone
FCC
Federal Communications Commission
GPS
Global Positioning System
IETF
Internet Engineering Task Force
3
TIA/EIA/TSB-146)
IP
Internet Protocol
ITU
International Telecommunications Union
KTS
Key Telephone System
LAN
Local Area Network
LDAP
Lightweight Directory Access Protocol
LEC
Local Exchange Carrier
LIF
Location Interoperability Forum
LIN
Location Identification Number
LIS
Location Information Server
MAC
Medium Access Control
MGCP
Media Gateway Control Protocol
MIB
Management Information Base
MLTS
Multiple Line Telecommunication System
NENA
National Emergency Number Association
NMS
Network Management System
PBX
Private Branch Exchange
PSAP
Public Safety Answering Point
PSTN
Public Switched Telephone Network
QoS
Quality of Service
SIP
Session Initiation Protocol
SNMP
Simple Network Management Protocol
TN
UDP
TDD
TFTP
VoIP
WAN
5.
Telephone Number
User Datagram Protocol
Telecommunications Device for the Deaf
Trivial File Transfer Protocol
Voice over Internet Protocol
Wide Area Network
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. The “model legislation” 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 its 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.
4
TIA/EIA/TSB-146)
6.
Voice over IP Networks
[Editor’s note: following text is copied from “internet-drafts/draft-polk-dhcp-geo-loc-option-00.txt”
(James M. Polk, John Schnizlein, Marc Linsner, Cisco Systems)]
As applications such as IP Telephony are replacing conventional telephony, users are expecting the
same (or greater) level of services with the new technology. One service offered by conventional
telephony that is missing, in any standardized fashion, within IP Telephony is for a user to be
automatically located by emergency responders, in a timely fashion, when the user summons help (by
dialing 911 in North America, for example). Unless strict administrative rules are followed, the
mobility of a wired Ethernet device within a campus negates any opportunity for an emergency
responder to locate the device with any degree of expediency. Users do not want to give up the
mobility IP Telephony offers. Informing the host device of its geo-location at host configuration time
will allow the device to utilize this geo-location information to inform others of it's current geolocation, if the user and/or application so desires.
7.
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 the 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.
 Location Information -- Provide correct emergency location information number (ELIN) of the
ECS caller so that the PSAP can dispatch help to the correct location.
 Call back Information – Provide the correct number for calling back the ECS caller in case the
call is disconnected.
The key to supporting the first three requirements is EN determination of the caller's location,
regardless of the terminal access scenario (See Figure 1). There are multiple methods for addressing
the last requirement.
Local regulations may require the implementation of other additional capabilities in the future. These
may include support for services analogous to E911 call hold and ringback as defined in T1.628a2001 for the PSTN.
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.
5
TIA/EIA/TSB-146)
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 nonworking 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.
8.
Determining Caller Location
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.
Cellular and wireless have addressed the issue of location discovery for the past few years and are
ahead of the IP industry for identifying the location of an ECS caller as well as supporting the new
Location Based Services (LBS). IP telephony issues are more complex, however, a similar approach
may be applicable.
In the Cellular domain, there are two basic types 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 networkbased 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.
A parallel approach could be taken for IP Telephony location discovery, as follows:
 Network-based solution – uses network management protocol (SNMP Trap) or DHCP tracker 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 manual configuration, or radio based beacons. There are limited
cases where GPS could be used.
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.
6
TIA/EIA/TSB-146)
8.1. Network Based Solutions to IP Telephony Caller Location
8.1.1.
SNMP based solution
8.1.1.1. Switch based solution
For the purposes of IP Telephony device location, it is assumed that the vendor of LAN
equipmentused 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 removal 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, LIS Logical Processing
Figure 2 shows the logical process of the LIS communicating with the SNMP agent within the
Ethernet switches to gather both a full forwarding table and 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 an IP network, a periodic gathering of all MAC address–toport information would be used to ‘sanitize’ the database and ensure that any information missed due
to lost packets is recovered.
The different steps that are used to build the association MAC addresses / RJ 45 location are the
following:
 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.
7
TIA/EIA/TSB-146)



[Editor’s note: Call Agent should be defined somewhere]
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.
Then, user call to 911 will be set up as follows:
 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.2. Midspan remote power source based solution
Deployment of IP phones in customer premises usually goes together with the need for the provision
of remote power source. Two solutions exist:
 replace existing switches by new ones that come together with embedded remote power supply.
These new equipment usually have SNMP and the relevant MIB and agents suitable for SNMP
switch based, as described before, in 8.1.1.1
 insert a new equipment between the switch and the cabling / power patch panel, that provides
midspan power insertion. This makes it possible to cope with existing switches for a while.
These midspan power equipment need to conform to IEEE 802.3af, and provide relevant MIB
and SNMP agent that will then be used for the provision of port / MAC address / kind of
terminal, as described in8.1.1.1.
8.1.2.
DHCP tracker based solution
Following text is extracted from draft-ietf-geopriv-dhcp-lci-option-01.txt
The DHCP request, from the terminal to the DHCP server is made using the Relay Agent Information
Option defined as SubOpt1 in RFC3046. This is an option whereby the Relay Agent (Ethernet switch
in the figure below) will append it’s MAC address and port number to the DHCP request message
sent by the terminal. This makes it possible to discover the association between a terminal, it’s MAC
address and relevant information related to the switch where it is connected. The nex step will be to
access a “Wall Jack” map to determine the location of the terminal in the building.
An important option of the proposed rfc is to forward this information back to the terminal. It can
therefore be stored and handled directly by the terminal instead of relying to a central LIS as it was
described in 8.1.1. This avoids extra delay and failure problem during 911 call.
Current proposal includes latitude, longitude, altitude information, together with their respective
accuracies, that are appended (16 bytes long) to the DHCP allocation reply from the DHCP server.
8
TIA/EIA/TSB-146)
8.1.3.
Enterprise Wide-Area Network
For further study
8.1.4.
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. [Editor’s note: it is not clear whether this is linked to the user or to the
terminal. I might very well connect from the airport, using their terminal and their infrastructure, but
towards the VPN and Call Server of my enterprise.]
[Editor’s note: contributions are welcome to provide solutions for location of this kind of user. One
simple solution would be to ask the end user, at the logging to the network, to fill out the location
(username, password AND LOCATION). The user could even be guided to fill out the location]
8.1.5.
Centrex Application
[Relevant material provided by N.B. Abott from Telcordia, to be added here]
8.2. Set-based Solutions
An advantage of IP sets is that they can be moved without any administrative intervention. This
allows a user to freely roam among various networks, such as IP, cellular and wireless; and be a
telecommuter, working from home, hotel room or airport connected (tunneled) to a 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 Netbased solution. The Set-based solution uses the networks only to carry the data stream to and from
the positioning device. If the network has a dynamically changing hub configuration or the adjacent
networks do not deploy a compatible solution, positioning becomes very difficult, complicated and
inaccurate.
9
TIA/EIA/TSB-146)
One other issue of importance is privacy. The Net-based solution provides the service provider the
capability to maintain a database location for commercial proposes. 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.
Cellular phones have been deploying a 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 does not work very well indoor, particularly, in a dense
metropolitan environment or in high rise buildings. This problem can be overcome by retrieving the
position information from the nearby devices or a beacon, which is accurate, secure and trusted.
[Editor’s note: there are WLAN based solutions that are built without the need for beacons]
8.2.1.
Positioning Beacon
The beacon is a stationary device, separately installed at various locations (offices, hotels and
homes), similar to the smoke alarm, or integrated into the wall mounted LAN connector. When it is
activated by an E911 call from an IP set equipped with the same signaling capability, the beacon
provides physical location information. The location information provided may be in the form of
position coordinates or a unique code.
[Editor’s note: there are 2 different proposals for the beacon family of solution; the first one, as
described before, relies on a beacon that is activated by the mobile terminal, and that will forward
information related to the terminal towards a server, over the LAN infrastructure. The second
proposal makes use of dumb beacons, that broadcast a fixed reference. This reference is recognized
by the terminal, and will be sent to the location server. In this second solution, the beacon needs not
to be connected to the LAN. This might be a cheaper solution.
The term beacon as used in this section can also apply to a more complex device that can be
deployed in several additional ways. For example, in a high-rise building it can provide a
redistribution function for amplifying the GPS timing signals from the satellites or can insert 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
are then cross-referenced to an actual physical address for the PSAP.
8.2.2.
Beacon Signaling
Several options are available for the signaling between beacons 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 an individual beacon. If not, all the beacons become
activated).
[Editor’s note: beacon might always be activated (see proposal 2 in my note above). And then, when
all beacons are activated, it might be quite difficult to describe the behavior] Once the beacon is
activated it transmits its pre-programmed coordinates or a unique code to the E911 server. This
information is then 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. It should be noted that if the initiation point
for an E911 call is outside the coverage area of the beacon, it is not possible to accurately provide the
location information for that initiation point.
8.2.3.
Bluetooth
Bluetooth is a new technology with a very large industry support (over 2100 members). It provides a
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.
10
TIA/EIA/TSB-146)
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 environments and data are protected by advance error-correction method,
encryption and authentication routine for privacy.
[Comments: the beacon might be always on, no need to activate – deactivate; then, I think we should
not limit ourselves to Bluetooth beacons: WLAN beacons and WLAN base stations might also be
suitable solutions. Dialog between the terminal and the beacon is not conform to Bluetooth Local
Positioning Profile. I propose to update for the next meeting, with this figure aligned with current
Bluetooth spec and proposals for the WLAN case.
Figure 3, Message Flow Among Various Components of the Set Based Solution
9.
Location Information Format
9.1. 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.
[Editor’s note: why should we exclude mobile terminals and terminal based solutions from now on ?]
The LIS provides the location information in an appropriate format (This could be either geodetic
latitude/longitude representing the position of the physical jack, or detailed address information,
11
TIA/EIA/TSB-146)
What is a detailed address? Street address or IP address? for examples.) for inclusion in the PSAP
ALI database. Or alternatively, the LIS provides the DID number of the emergency caller for
conversion into a physical address by the PSAP database.
[Editor’s note: current geoloc proposal in IETF is a geographical address, there is no need for further
conversion from the PSAP]
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.
9.2. 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 Figure 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 Network 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.)
12
TIA/EIA/TSB-146)
Enterprise
Network A
LAN
PS-ALI
Local
LIS
Network
LIS
ALI
DBM
PS-ALI
Enterprise
Network B
LEC Packet
Network
LAN
ALI – Automatic Location Identification
DBM – Data Base Manager
LAN – Local Area Network
LEC – Local Exchange Carrier
LIS – Location Information Server
PS-ALI – Private Switch ALI interface
Local
LIS
Figure 4, Automatic Upload of Location Information
9.3. 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
database is shown in the tables below.
Table 2 below shows the correlation between wall jack location, Ethernet switch port, IP address,
telephone number, ELIN, and emergency services zone.
Table 1, LIS Database
END USER
ETHERNET
SWITCH/
PORT
IP PHONE
MAC
ADDRESS
IP
ADDRESS
2A57
SW16/73
Abc067854dea
10.1.1.26
408-5556789
408-5551212
124
4F98
SW07/19
e10f4598d3ba
10.6.3.2
408-5555378
408-5551234
348
3Z103
SW113/147
e10f4597ab6f
192.168.2.1
5467
408-5557564
763
Column 2
Column 3
Column 4
Column 5
Column 6
Column 7
JACK
NUMBER
Column 1
ESZ
13
PHONE
ELIN
NUMBER
EMERG.
SRV.
ZONE
TIA/EIA/TSB-146)
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
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 is the 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 the 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 3 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 2, ELIN to ERL Mapping
ELIN
ERL
408-555-1212
170 W. Tasman Dr., 3rd floor, NW
corner
170 W. Tasman Dr., 2nd floor, SE
corner
170 W. Tasman Dr., 4th floor, room
415
408-555-1234
408-555-5432
GEODETIC LOCATION
INFORMATION
14
TIA/EIA/TSB-146)
Table 4 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 3, 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.
One available format is T1.628
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
15