VoIP

SUBSCRIBE TO TMCnet
TMCnet - World's Largest Communications and Technology Community

VoIP Feature Article

VoIP

May 22, 2006

Life, Death, and Liability: Enterprise e911

TMCnet Special Guest
Benny Rodrig, Bill Mertka, Christian Stegh, and Dan Romascanu


One of VoIP’s most tangible benefits is its ability to enable mobility. Users can move their phone to a different office or login from softphones from hotels, assume their own extension and features, make and take calls as if they were back at their desk. But a challenge comes with this flexibility: finding the precise physical location of a user dialing for help in an emergency is not trivial. The standards being developed to solve this challenge are the focus of this article. 
 
There is no single standard that will solve the emergency location problem. Similar to the way SIP reused HTTP and SMTP, there are existing protocols which help solve parts of the issue. Some key enabling standards are close to being finalized, while others need deliberation and maturity. It’s not just the lack of individual standards, but also the lack of a framework that has kept the industry from cohesively addressing emergency location problems in the enterprise. 
 
After a brief statement of the problem, the standards being developed for two categories of VoIP users are discussed in turn.  Future predictions are offered, followed by a summary of the implementation challenges of the standards.
 
What Seems Simple Actually Isn’t
 
Identifying the location of a fixed user in an emergency is simple. Most enterprise IP PBXs have a database entry for each user, and part of each entry is a field describing the phone’s location. Administrators can enter general locations like a street address, or detailed descriptions like floor, quadrant, and cubicle number. 
 
In the U.S., this location information, along with the extension number and other information is periodically sent to 911 database administrators, which in turn send the electronic information to the proper local Public Safety Answering Point (PSAP).  When a 911 call is placed from an extension and routed to the PSAP, the ANI information is used to pop an operator’s screen with the caller’s location information.
 
So what happens if a user moves their phone or logs into a phone at a different site, makes a 911 call, and the location information hasn’t been updated with their current location? The call may end up in the wrong PSAP, or the emergency responders dutifully drive up to an incorrect location. 
 
Under certain circumstances, enterprises are required to keep accurate location information and are liable for such misinformation. Rules are especially strict in certain states in the U.S.A, but regulations vary in different states and internationally.
 
In all cases, the main premise is that the enterprise is expected to provide location information, but the details are abstract. Nonetheless, industry players have made consistent progress in providing emergency location information even without standards-based solutions, which are discussed next. 
 
Standards to Address the Mobile On-Net Worker
 
First, there is the challenge of mobile workers, like regional managers or traveling executives, who often move their IP phones or login to phones in different offices.  Today, using network wiring documentation, topology maps, and proprietary mechanisms, enterprises can determine the location of the user based on its IP address or based on which Ethernet switch port the phone connects.
 
However, such methods require regular maintenance and aren’t foolproof.  To more dynamically map the network and determine to which LAN switch port a phone is connected, the industry looked to the Link Layer Discovery Protocol for Media Endpoint Devices (LLDP-MED).
 
LLDP-MED
 
LLDP was developed in the IEEE 802.1 Working Group, and was approved as 802.1AB in March 2005. It’s a one-hop layer 2 announcement protocol, where a network device or host advertises topology information to neighboring devices connected at the port.
 
Each device builds a topology management information base (MIB) about its neighbors, using the standard Simple Network Management Protocol (SNMP).  The information is exchanged by neighboring devices using Time-Length-Value (TLV) triplets, which provide a modular architecture and extensions being defined by the IEEE 802.1 Working Group and others.
 
LLDP-MED is the first such extension of IEEE 802.1AB.  LLDP-MED defines a set of new TLVs, identified by a Telecommunications Industry Association (TIA) Organizationally Unique Identifier (OUI) in each LLDP-MED TLV.  It’s built to exchange information between IP phones and networking equipment, like Ethernet switches and WiFi (News - Alert) Access Points.  One of its main applications is to locate where IP phones connect to the network. 
 
When an IP phone connects to an Ethernet switch, it first must authenticate using IEEE 802.1X, to ensure the topology exchange is between trusted entities.  Then, the phone and the port begin exchanging topology information, using LLDP-MED TLVs.  
 
The IP phone is told about its location by the upstream network device. Although the LLDP-MED standard does not specify how the location information should be used, a typical scenario would be for the network device to be configured with the authoritative location information, since they’re in a fixed location.
 
For example, port 0/24 is known to be connected to a cable in the conference room on the fourth floor, but 0/23 is running to a cube in the north quadrant.  The IP phones acquire this information when they connect to a specific port, and provide the information to the location database.  The Endpoint Location Identification Discovery TLV carries the emergency call service location.
 
The exchange is repeated periodically to update topology changes in real-time, and SNMP traps can alert management applications as changes happen through an LLDP-MED extension.
 
In order to tie LLDP-MED into the existing emergency network, Emergency Location Information Numbers (ELIN) can be used.  ELINs are special phone numbers used to indicate location, and are assigned and associated with small geographies in the organization.  The ELINs and their locations are provided to the PSAP, and endpoints get associated with ELINs based on their location.
 
Figure 1 (below) outlines a possible Enterprise emergency calling solution utilizing LLDP-MED location delivery.
 
Figure 1 
 
Two critical parts of the process are illustrated in Figure 1: the bottom half shows an IP phone joining the network and getting its location information via LLDP-MED.  The location information and the ELIN associated with the location are sent to the PSAP on a scheduled basis (not in real time).  The top half shows an IP phone dialing 911, and the ELIN information that it received being sent along with the call setup to the PSAP. At the PSAP, the ELIN is used to pop a screen indicating the location of the caller that needs help.
 
LLDP-MED offers services in addition to location information, like VLAN identification, layer 2 and layer 3 QoS marking, asset management, and extensions of the Power over Ethernet information already present in IEEE 802.1AB.  LLDP-MED was co-authored by Avaya (News - Alert), Mitel, HP and Enterasys in the TIA TR41.4 working group. The content of the LLDP-MED standard passed all technical ballots in the second half of 2005, and is expected to be published soon as ANSI/TIA-1057.  Some products using LLDP-MED have been announced, and others soon will be available.
 
DHCP
 
Another solution being considered for delivery of location information uses DHCP (Dynamic Host Configuration Protocol). The GEOPRIV Working Group of the IETF has specified a DHCP Option (number 123) in RFC 3825 for delivering coordinate-based geographic location, and is working on specifying a DHCP option for delivering location information in civil address format. DHCP provides location information to the IP Phone, provided it knows the location information and exactly where the endpoint is within the enterprise. 
 
To determine the location of the endpoint, coordination with additional devices and mechanisms is required. In Ethernet switch environments, this solution requires a DHCP-Relay function in the switch and the use of DHCP option 82.  Option 82 tells the DHCP server about which switch port the client is connected.  
 
The same is required in WiFi environments; the DHCP server must know to which WiFi Access Point the client is connected.  Since mobile clients, such as WiFi-connected softphones, can change their location by moving from one access point to another within the enterprise, the DHCP location solution requires frequent refresh.
 
While the Enterprise LAN is not the focus of this standard, it is one of the many network environments in which the standard can be used.  DHCP-based location delivery can play a parallel role to LLDP-MED in the Enterprise emergency calling solution architecture; both are expected to be supported.
 
Additional possible solutions for location delivery to the endpoint are being considered by standards bodies, including layer 7 solutions such as HELD (HTTP Enabled Location Delivery).  Such solutions may be better suited to environments other than the enterprise.
 
Standards to Address the Road Warrior
 
Next, there is the more difficult problem of road warriors using softphones from homes, hotels, or random hotspots. Proprietary mechanisms to solve this issue include requiring the user to hardcode and send an actual E.164 PSTN number to the location database when logging in. However, even with that information provided, the updated location database isn’t pushed to the PSAP immediately, since updates occur only on a periodic basis.
 
Driven by the needs of corporate road warriors and regulatory pressures, industry is working on standard solutions for users connecting outside their regular corporate environment. Spearheaded by National Emergency Number Association (NENA) in North America, these standards intend to provide nomadic users with the same emergency service as wired endpoints. Dubbed “i2” for short, this standard aims to ensure that VoIP-based 911 calls are routed to the correct PSAP, along with callback number and address information, regardless of where the caller is located.
 
The NENA i2 standard is based on some basic key concepts and building blocks. First is LIS, or Location Information Server, which provides the location information for all corporate users. Mobile workers can input their location information to the LIS by methods such as a web page update, drop down list of addresses in their softphone client, or ancillary methods like an Interactive Voice Response (IVR). 
 
The LIS in turn provides location information to the VoIP Positioning Center (VPC).  The VPC is modeled after similar capabilities in the Wireless E-911 world, which “geo-codes,” or determines a latitude/longitude for the location in question, and validates the address information submitted.  This information is available to the PSAP operators in near real-time should a caller dial for help
 
The 911 calls themselves are forwarded via another key building block, the Emergency Services Gateway.  The ESGW takes the VoIP call, converts it to TDM and forwards it to the proper selective router in the existing 911 network that handles the required PSAP.  LIS, VPC, and ESGW functions, all part of the NENA i2 standard, are offered by a growing number of 911 service providers to enterprise customers, providing nomads with access to the same emergency services they have from their desk phone.
 
Summary: A Look into the Future
 
With multiple approaches still maturing, enterprises will need to obtain and deploy solutions that accommodate both user populations, and are flexible enough to be updated as standards evolve. Solutions such as the DHCP location option and LLDP-MED will soon be supported in endpoints.  As these solutions are deployed in various networks through which the corporate road warrior connects, they will enable automatic location determination and eliminate the need for the users to manually update their location information when moving. 
 
LIS vendors, IP PBX manufacturers, and other enterprise telecommunications service providers are actively participating in the standards bodies and are working to ensure their solutions will meet the standards as they evolve.  That said, enterprises should demand that their vendors adhere to the standards, and be prepared to add or upgrade solutions as standards become finalized.
 
In addition to upgrades within the enterprise, it will take significant effort to deploy the framework within the public network. Updating all of the PSAPs in the world to IP-based protocols will not happen overnight. Even as standards become available, different states and countries will move at their own pace in updating their systems, especially since local laws may not require them to change. As a result, enterprises cannot expect consistent worldwide support right away. 
 
In the longer term, as IP communications are adopted widely, PSAPs will gradually migrate to VoIP and will be able to accept SIP calls directly.  NENA is working on a future standard called “i3,” and the IETF ECRIT working group is addressing certain needs of this future environment.  One model for the solution is that the endpoint acquires its location information from the access network it connects to, then relays the location in its emergency call setup message sent to the PSAP. The location information is also used to determine to which PSAP the call is routed.
 
So while there has been progress in solving emergency location challenges for enterprises, to date it has mainly been without standards.  Since this makes interoperability improbable and management complicated, the current state of the industry reiterates the need for the standards and frameworks discussed in this article.
 
----
 
This article was a group effort, written by: Benny Rodrig, Architect, CTO Group, Avaya; Bill Mertka, Director of Product Management, RedSky Technologies; Christian Stegh, IP Telephony Practice Leader, Avaya; Dan Romascanu, Director of External Standards, CTO Group, Avaya and Director, Operations and Management Area, IETF.

VoIP


Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: tmc@tmcnet.com.
Comments about this site: webmaster@tmcnet.com.

STAY CURRENT YOUR WAY

© 2020 Technology Marketing Corporation. All rights reserved | Privacy Policy