Understanding Enterprise E911Understanding Enterprise E911

Today's IP telephone systems and current carrier offerings allow enterprises the flexibility to architect systems to join sites, share trunking, and create a single virtual telephone environment like never before. But these capabilities challenge consultants, system designers, and customers to fully understand and plan through the implications these can have for emergency services notification. Before a system is deployed, it is important to determine answers to key questions, such as:

* When someone dials "9-1-1" from the enterprise, will their call ring into the correct dispatch center responsible for serving that site?

* When someone dials "9-1-1" from the enterprise, will dispatch receive the correct information (phone number and address) for that caller?

* If emergency personnel have to respond to the call using the address information for the caller, is it reasonable that they would be able to find the individual if no one was around to take them to the caller?

In years past, these questions were often not considered a critical part of telephone system design except when working with larger system installations. Today, this has clearly changed as more and more organizations are purchasing systems and enabling sophisticated networking features, enabling centralized trunking, tying multiple disparate sites together, supporting remote users, and supporting the fluid move/change environment enabled by IP phones. These capabilities have the potential to affect the integrity of 911 calling.

At this time, several states have some type of legislation regarding expectations for the processing of 911 calls from a business environment with the potential to impact design considerations. Whether or not state regulations exist, prudence recommends taking steps to ensure that the constituents using an organization’s telephone system can depend on that system to process a 911 call properly and allow emergency responders to show up at the correct location with enough information to quickly find the caller.

This article explains the applications and services that exist to allow a system to be designed to deliver customized and detailed location information to the emergency dispatch center (Public Safety Answering Point or "PSAP"). Specifically, we will look at how enhanced 911 services work on the CPE side and compare that to the specialized Private Switch – Automatic Location Information (PS-ALI) services that exist on the carrier side – and how the two interact. Lastly, we will offer some guidance when moving forward with the decision to implement enhanced 911 services.

911 CALL PROCESSING

Without the use of any special E911 capabilities, a user dialing 911 in an enterprise telephone system will pass the Automatic Number Identification (ANI) associated with the trunk they are using. The Automatic Location Information (ALI) will almost always correspond to the billing address for the trunk--which typically is the same as the address for the demarc. The general process is described below:

If analog central office lines are used, the ANI passed to the PSAP will be the number associated with the line being used to place the call. If digital ISDN-PRI service is being used with Direct Inward Dial (DID) numbers, the ANI will follow the configuration of how the PRI was set up; either the main pilot number associated with the PRI will be out-pulsed or the individual DID number being used to place the call will be out-pulsed. In many system implementations, allowing a user to pass the ANI/ALI of the trunk they are using is acceptable because in many cases the user's location and the trunk's billing information (demarc location) are the same. However, we potentially get into difficulty under at least three scenarios:

1. A single building environment that is either very large and/or has multiple floors.

2. A campus environment with multiple buildings but only one demarc.

3. A networked environment that serves multiple buildings (MAN/WAN) where some/all of the buildings have access only to hub trunks (no local trunks exist at the networked endpoints to process 911 calls).

In all of the above scenarios, a call to 911 may either provide insufficient information to emergency responders--or worse yet, may actually lead responders to the incorrect address. Generally-followed dispatch protocol recommends that upon answering a call to query the nature of the emergency, dispatchers will ask to confirm the caller’s location. However, if this cannot be done, the ALI address is what will be used when dispatching a responder. Additionally, if the call drops--or even if the caller immediately hangs up--dispatch will call back on the ANI received and if they cannot reach anyone at the number, they will dispatch an officer to the ALI address. Therefore, providing dispatch with the proper ANI (or minimally an ANI that will be answered by the organization) as well as an accurate ALI, is critical to enabling the emergency response process to work.

If we use the example of an organization using ISDN-PRI service and DID numbers in a multi-floor building, the telephone system can be set up to pass the actual ANI of the caller dialing 911, but the ALI will only indicate the main billing address. Therefore, emergency responders showing up at the scene would not know what floor to go to unless it was communicated on the original call or someone at the scene could guide them to the caller. Likewise, in a multi-site/campus environment using a single set of centralized trunks, a common ALI address (the building address where the demarc is located) would be given for anyone dialing 911.

In networked metropolitan environments (e.g., municipal government, school systems, local banks) this shortcoming can be alleviated by dedicating a small group of at least two analog lines into each building and routing each building’s users to the local trunks when dialing 911, but this latter method assumes:

* A demarc exists in each building
* Each site is equipped with a system/gateway that will support local trunking
* Each system/gateway can direct its building's 911 calls to a local separate trunk route
* Each system/gateway can make these "emergency" lines a ringing appearance on at least one phone in the building in case Dispatch was to call back on a 911 hang-up/disconnect

If these assumptions cannot be met, callers to 911 may suffer compromised outcomes.

There is at least one other scenario that will force us to deal with 911 call handling:

* State regulation that requires compliance

Currently, 16 states have legislation with the potential to impact business telephone system design:

Alaska; Arkansas; Colorado; Connecticut; Florida; Illinois; Kentucky; Louisiana; Maine; Massachusetts; Minnesota; Mississippi; Texas; Vermont; Virginia; Washington

See "State Status of MLTS (Multi-Line Telephone System)/PBX Legislation" for more information (Note: This site is only periodically updated). Each state’s regulations and requirements are unique, so implementing systems in these states requires consideration to determine whether the regulation affects your project and if so, what will be required to satisfy the regulations.

It should be noted that in some isolated cases, some organizations elect to handle their own emergency calls by directing users to call an internal extension to reach a Security/Public Safety department who in turn determines if a 911 call needs to be placed. Although beyond the scope of this article, organizations should be aware that the potential liability associated with this protocol should be assessed against the benefits of screening emergency calls; best practices would recommend against taking on the liability for matters normally in the domain of emergency service professionals. Alternative approaches to addressing notification to an internal security department will be discussed later within this article.

THE CUSTOMIZATION TOOLS: E911 & PS-ALI

When it has been determined that the ANI/ALI delivered using the in-place trunks will not provide an ideal or acceptable level of accuracy for 911 calling, it is time to look at customizing the ALI environment. This is where enterprise E911 capability comes into play.

In its simplest form, E911 capability is the application within the telephone system that allows the administrator to ignore the default trunk ANI/ALI information and assign telephone users "custom" ANI information that will be correlated with "custom" ALI information. As an example, if a user's DID number is "212 555-2222," the E911 application can allow the administrator to assign a different DID number to be passed when the user calls 911, say "212 555-4444." Why would this be of value? Because it is the ANI that drives the entire 911 call process. When someone dials 911, their receiving central office forwards the call to their regional 911 selective router, which performs a lookup against the ANI to determine which PSAP should get the call--it then delivers the call to the serving PSAP. As the call rings into the PSAP, a data connection between the PSAP and the regional ALI database processes a query using the caller’s ANI to "spill" the caller's ALI information to the dispatcher’s console screen a split second after the call is received.

It is important to understand that when it comes to customizing what the PSAP sees, the E911 application in the telephone system is just half of the equation. A 911 caller can only pass their ANI (whether it is their "real" ANI or a pseudo-ANI spoofed by the E911 application)--the ALI (location information) associated with an ANI resides in the carrier's ALI database. Getting access to the carrier's ALI database in order to show "customized" location information is the second half of the equation. It is done by purchasing a Private Switch ALI (PS-ALI) service from the ILEC/CLEC or a PS-ALI service provider. This service allows for "custom" location records to be related to specific ANIs and then uploaded to the carrier's regional "live" ALI database. Once this is done, a 911 call made with one of the ANIs built in the PS-ALI service will match up with the custom ALI record in the regional database and "spill" the appropriate location information to the PSAP. It should be noted that PS-ALI service is typically priced in direct proportion to the number of unique ANI/ALI records required to be built and carried in the database, so the more records, the more costly.

UNDERSTANDING THE E911 APPLICATIONS

Without the use of an E911 application in the telephone system, the method of delivering customized, accurate ANI/ALI to PSAPs requires the 100% use of a PS-ALI service. In this scenario, since every telephone/DID user would by default pass their unique ANI and the default trunk billing address, there is a need to build a "custom" ALI record for every DID instance in the enterprise. Therefore, if an enterprise has 1,000 telephone (DID) users, the PS-ALI service would require 1,000 unique ANI/ALI records to avoid passing the default billing address for any of the 1,000 phone users. This is both expensive and burdensome to manage. In this environment, anytime a DID user moves within the organization, the administrator needs to update the PS-ALI database to show the new location information, and then the carrier needs to upload this information to their "live" regional ALI database (or databases); this database refresh can take from minutes to hours to accomplish.

Manufacturers and third party providers have developed E911 applications to economize and simplify the process of customizing and managing 911 information for enterprise users. The E911 capability found either standard or optionally within most systems can be used to reduce the number of PS-ALI records required and simplify the administration of MAC activity and associated integrity of 911 call processing.

The major function of the E911 application is to allow for the capability to out-pulse a pseudo-ANI rather than the user’s actual ANI when making a 911 call. This allows DID users to be grouped together in "zones" and assigned a common pseudo-ANI that will be out pulsed when anyone assigned to the group dials "911;" this ANI will reference an ALI record in the PS-ALI database that will identify the building’s address plus a granular location within the building that multiple telephone users can reference (e.g., 3rd floor, West end). This geographic "zone" is referred to as an Emergency Response Location (ERL). The DID number that is out pulsed and used to reference a custom address/ERL in the PS-ALI service is known as an Emergency Location Identification Number (ELIN) or a Customer Emergency Service Identification (CESID). Using ELINs/CESIDs to serve a proximate group of users reduces the number of records needed in the PS-ALI database, thereby reducing cost, simplifying setup of the E911 database, and simplifying 911 Move/Add/Change administration.

Interestingly, E911 application functionality is not without potential drawbacks. For instance, with the use of ELINs/CESIDs, instead of a 911 caller passing their true ANI, the E911 application will in many cases pass the caller's ELIN to the PSAP (the "spoofed" or pseudo-ANI used when out-pulsing a 911 call). If this is the case, enterprises must make sure that every ELIN rings into a station(s) that would normally be tended in case the PSAP were to call back on a disconnected 911 call. In some cases the manufacturers are able to overcome this shortcoming (e.g., some systems are capable of recognizing a 911 call back and ringing it to the actual DID of the most recent 911 caller).

Another potential shortcoming with some E911 applications is that where a separate application server is used, a failure of this server may result in enterprise 911 calls passing default trunk information to the PSAP (in most cases, a redundant server is an available option to mitigate this vulnerability).

Besides the core function of enabling 911 calls to pass customized DID assignments, most E911 applications provide other important benefits. One is the ability to provide real-time notification to one or several users that a 911 call was just placed (and identify who placed it) with the option of allowing authorized phones to join in and listen to the call. This capability is important to environments where false 911 calls are a problem (e.g., K-12 Education) or security departments want to be apprised of internal emergencies (e.g., Manufacturing, Higher Ed). Another capability typically found is the automatic administration of Move/Add/Change re-assignments so that as IP phones are moved within the organization they are automatically and accurately updated with the proper ELIN assignments. Although manufacturers vary somewhat in their approach to mapping the data network and tracking phones that move on the network, IP phones can typically be moved anywhere in the enterprise and the E911 application will know enough about the data network to know what ELIN should be assigned. This is typically accomplished by using subnet assignments or a Layer 2 approach to assign users based on the switch or switch port being used by the IP phone so that 911 calls can be processed with the correct location information without any administrative intervention.

Below follows a brief summary, grouped by manufacturer, of some of the E911 applications currently available:

CISCO: The E911 application for Cisco’s Unified Communications Manager (CUCM) is Cisco Emergency Responder (CER). The CER application and server are optional and are therefore priced separately. CER can be set up for redundancy with a Primary and Secondary failover server. Multiple methods can be used to keep track of phone locations in relation to the enterprise data network, including defining "zones" (ERLs) by subnets (this is the required method for supporting wireless phones), by LAN switches, or down to the LAN switch port level. As with all manufacturers, this mapping requires a one-time setup of the application database to correlate the LAN topology with the ERL "zones" that will be used. Phones that are moved and reconnected to the network use Cisco Discovery Protocol to announce device type ("IP phone") and connection location on the network (enterprise location)--CER automatically re-assigns the proper ELIN for the user should they need to make a 911 call. If CER is unavailable or unreachable from CUCM, 911 calls are processed through the appropriate (ideally "local") gateway, and default trunk information will be passed. E911 for soft phones (Cisco IP Communicator) is supported as long as they are connected to the enterprise network. CER supports real-time notification to key users that a 911 call was placed within the enterprise; however, support for some specialized features such as silent monitoring of an in-progress 911 call is not supported at this time.

AVAYA: The E911 application for Avaya’s Communications Manager 5.0 is embedded in the generic software and is simply referred to as Enhanced 911. There is no separate server or application to purchase to activate this functionality--defining ELINs and mapping the data network is done within Communications Manager. Depending upon the level of granularity, desired network regions can be defined based on subnets, switches, or down to the (switch) port level. Since the E911 functionality resides within Communications Manager, there are no ramifications associated with a separate server/application failing. Avaya supports real-time notification of specific users that a 911 call was made within the enterprise ("Crisis Alert") and can provide the capability of monitoring and even recording the call. When "zones" are used and DID users are assigned a pseudo-ANI to tie them to their PS-ALI database record, Avaya can present the PSAP with either the pseudo-ANI or the user’s true ANI. For more demanding applications where wireless mobility is being used (e.g., Avaya’s One-X), Avaya will bring in the E911 solution offered through the third party provider RedSky.

NORTEL: The base E911 functionality for the Nortel CS1000 is embedded in the generic software and is called Emergency Services Access (ESA). If the enterprise is able to define ELINs according to their subnets, no further application is required besides the carrier's PS-ALI service for full functionality. If the enterprise needs the flexibility to define ELINs according to the LAN switch ports used, then it requires the use of a third party provider: eTelemetry's "Locate911" application. Locate911 runs on a Linux appliance which has maps, a database of all LAN switches and the addresses to be used for all port assignments. Locate911 continually monitors the network to track the location of IP phones on the network and ensure that the proper information is passed to the CS1000. Locate911 is used as a means to "see" the data network and track IP phones; it does not impact the ability of the CS1000 to process a 911 call and therefore does not pose a point of failure. ESA is capable of recognizing a PSAP callback on a 911 hang up (configurable from 5 to 1,440 minutes of when the call was made), and if the call is not answered on the ELIN DID, it will hunt the call to ring the actual DID of the user who called 911. Real time notification of a 911 call is supported (one user notification license is supported at no additional cost), and custom descriptor information is passed to the notified party.

MITEL: Basic E911 functionality exists in the Mitel 3300 ICP's generic software, but the advanced capabilities are delivered as part of Emergency Response Advisor (ER Advisor) which runs on a separate server. ER Advisor maps the data network and keeps track of Layer 2 addresses on the LAN switches and correlates them to CESIDs which are then correlated in the PS-ALI service.

NEC: Basic E911 functionality exists in the generic software for the NEC SV 8300 and SV 8500, but the advanced capabilities warrant the use of third party Amcom’s "Enterprise Alert." Enterprise Alert runs on a separate application server plus a server that acts as a VoIP tracking gateway that can track the movement of the VoIP enabled terminals within the LAN and supports up to 100 SNMP-enabled LAN switches on a single server (more than 100 LAN switches will require additional servers). If the Enterprise Alert application were to fail, 911 calls would still be processed but would do so using default trunk information; a redundant server option is available. Real time notification of 911 calls is available.

SIEMENS: The E911 application for Siemens' OpenScape Voice Application (HiPath 8000) is embedded in the generic software and is generally referred to as the "E911 Tables." Since this application is embedded, there is no separate server and there is no additional cost for the E911 functionality. Since there is no dependency on a separate application server, E911 performance is directly tied to the resiliency of the 8000 and the remote gateways in the enterprise network. Siemens uses subnets as the method to track "zones" and correlate users within the enterprise with their ELIN. Siemens does not support real time notification to specific users that a 911 call was placed within the enterprise; this functionality would require the use of a third party E911 application.

SHORETEL: ShoreTel's Unified Communications Solution contains basic E911 functionality embedded in the generic software, but for larger and more demanding E911 requirements, ShoreTel recommends third-party 911 Enable Emergency Routing Service (ERS) by ConneXon Telecom. 911 Enable offers both a CPE-based approach and a hosted service approach. The CPE solution requires a separate server to run the 911 Enable application while the hosted approach requires a trunk connection to 911 Enable's NOC, which hosts the ERS application and connections to the public 911 network. ERS can accommodate setting up Emergency Response Location "zones" according to existing subnets, switches, or on a switched port-by-port basis. Redundancy can be built into either the hosted approach (multiple trunk connections) or the CPE approach (redundant servers). Based on how the application is set up, the user’s ANI or their ELIN can be passed to the PSAP.

3COM: 3Com's VCX platform (Connect 100/200, V7000 Enterprise, and Unified Communications on IBM System i) is paired by 3Com with third party provider ConneXon Telecom's 911 Enable product. 911 Enable runs on a separate server and will accommodate the use of Emergency Response Location "zones" by subnet, switch assignments, or down to a switch port basis.

AASTRA: Clearspan, Aastra's SIP-based solution based on software from Broadsoft (Broadworks carrier grade call control system), is paired with their redundant Location Information Server application ("LIS" server) to provide full E911 capability. The LIS server allows Emergency Response Zones to be defined according to subnets while a later release is planned to allow for definitions down to Layer 2 (switch ports). In addition, Aastra phones support Link Layer Discovery Protocol-Media Endpoint Discovery. Aastra supports notification (including email messaging to security personnel) active or passive bridging to a Security Desk of in-progress calls.

Third Party Providers: It should also be noted that a number of specialized third party application providers focus on the E911 space and some of these are the preferred third party providers to the major telephone system manufacturers listed above. Some of these include:

* 911 Enable
* 911 ETC
* Amcom
* eTelemetry
* Red Sky

A review of their product offerings reveals standard E911 applications plus advanced, specialized feature sets for organizations that have specific and demanding E911 requirements.

UNDERSTANDING PS-ALI SERVICE & VPCs

As mentioned earlier, the telephone system's E911 application does nothing to populate the actual carrier ALI databases that exist strategically throughout the public network. In order to populate the "custom" ALI records into the public network, a carrier offering needs to be purchased. This offering is typically referred to as Private Switch ALI Service (PS-ALI Service) and allows the customer to build their custom ANI/ALI database and then upload it to the public 911 database network. Once this is completed, calls from the enterprise to 911 will display the custom information to the PSAP receiving the call. It is important to note that there are two primary methods of interfacing to the PS-ALI service when using conventional trunks--either by using ISDN-PRI or by using CAMA (Centralized Automatic Message Accounting) trunks. The preferred method is almost always to use PRI, since it can be used to make and receive calls, while CAMA trunks (a minimum of two must be installed) do nothing but support the PS-ALI functionality at a cost similar to T1/PRI.

The major providers of PS-ALI service are the local carriers (ILECs/CLECs) such as AT&T, Verizon, QWEST, XO, Cincinnati Bell, etc. Typically, there is a one-time cost to set up the PS-ALI database that may range from approximately $2,000 for a 50-record database to $8,000 for a 2,000 record database. Likewise, there is typically a recurring cost to maintain the records in the regional ALI database that may range from approximately $30 for a 50 record database to $150+/month for a 2,000 record database. Service offerings can vary to include unlimited access by the customer to make updates to their PS-ALI database; or the service may limit them to submitting their changes to the carrier who then charges a fee for each update required.

A brief summary of some PS-ALI service offerings:

AT&T: AT&T offers PS-ALI products across its 22 state footprint, but the product name, pricing, and precise feature functionality vary according to its legacy RBOC areas.

* AT&T (SBC region): PS-ALI service comes in two versions: "9-1-1 Locator ID" and "9-1-1 Locator ID Lite" service. The "9-1-1 Locator ID" service allows the customer a direct interface with the E911 database to make changes as needed, and it scales to handle many records. The "Lite" service is priced to accommodate those with a need for relatively few records (< 25) and is intended to be essentially a static database that the customer requests by filling out a form, which AT&T processes on their behalf.

* AT&T (Bell South region): PS-ALI service is called "911 Pinpoint."

* AT&T (PAC Bell and Southwestern Bell region): PS-ALI service is called "PS-ALI."

VERIZON: Verizon's PS-ALI product is called "PS/ALI." Verizon recently dropped monthly recurring charges for this service--there is now just a $2,500 non-recurring fee to set the customer up in Verizon's E-911 database.

QWEST: Qwest's PS-ALI product is called "PS/ALI."

Embarq: Embarq's PS-ALI product is called "PS/ALI."

Intrado: Primarily provides 911 operations support systems services to incumbent local exchange carriers, competitive local exchange carriers and wireless carriers but will also offer services to enterprises on an individual case basis.

It is important to note that if SIP trunks are used, standard PS-ALI service will not suffice. IP-based trunking requires the services of a VoIP Positioning Center (VPC). VPC’s are the E911 service providers for VoIP service providers (VSPs). Some of the major VPCs are:

* 911 Enable
* Intrado
* Red Sky
* TeleCommunication Systems
* Vixxi

Interestingly, SIP trunks paired with VPC services can allow for even more detailed information to be loaded into the data fields sent to the PSAP than those found with conventional trunks.

DESIGN CONSIDERATIONS

When moving forward with an E911 deployment, a key step is planning out what will ultimately make up the PS-ALI database. A number of questions will need to be answered and will require the review of building floor plans, and may even require on-site walk-throughs. These include:

* What should make up the geographic "zones" (Emergency Response Locations/ERLs) that will be associated with each ELIN?

* How granular do we want to be--how big or small should each ERL be?

* How many PS-ALI records will we ultimately require to support all of our ERLs?

When defining zones it is helpful to think about what location information the emergency responders will receive versus what they will see when they arrive on-site. Is it reasonable that they could quickly find the caller? Or is the space so large--or so partitioned--that it would be time consuming to comb through it? Sometimes fire alarm zones can be used as a guide to defining reasonable ERLs. The local Police or Fire department may also offer helpful assistance and guidance when working through some of these decisions. A helpful resource is the National Emergency Number Association’s website--go to "For 911 Professionals" then "MLTS/PBX;" once there you will have access to technical documents including the PDF: "Model Legislation: E9-1-1 for MLTS."

It should be noted that certain E911 instances can be particularly challenging, and though they are beyond the scope of this article, they should be on your radar:

* Soft Phones: Passing proper ANI/ALI for soft phone users within the enterprise is generally not a problem for the E911 application but when soft phones are used outside of the enterprise (e.g., home, hotel, coffee shop, etc.) significant difficulties arise that are not easily accommodated by most E911 solutions.

* Networked Sites: When dealing even with small metropolitan networks, you may be faced with sites that cross boundaries and are served by different PSAPs as well as even different carrier ALI databases. This can require multiple PS-ALI services with multiple connections to these services. It is important to understand up front what PSAPs serve each site and which carriers are responsible for providing the ALI database serving these PSAPs.

* SIP Phones: In cases where SIP phones are being used instead of the manufacturer’s IP phones, E911 capabilities found in the telephone system may not carry over and provide full functionality to SIP phone users due to limitations associated with supported SIP feature sets.

By understanding the implications that current design capabilities can pose for 911 calling, system designers can identify in advance scenarios that pose potential for trouble, and can inform their customers as to additional steps that might be needed to fully protect the integrity of those calling 911. By understanding the tools that are available and how they are used, enterprises are able to take reasonable, economical steps to overcome design issues and protect their personnel and any others using their telephone system. Helping organizations understand how to protect employees while minimizing risk and liability is good business - it is also doing our part to help emergency personnel meet their challenge of responding effectively when that 911 call comes in.

Ted Mallires is a Manager in the Technology Consulting & Solutions group of Plante & Moran, PLLC, an accounting and management consulting firm with offices located throughout the Great Lakes region. He specializes in telecommunications and networking projects and is a member of the Society of Telecommunications Consultants.