Enterprise systems can give public safety verified context both inside and beyond the property line
By Mark J. Fletcher, ENP
Listen to the Article
For years, Multi-Line Telephone Systems have been treated as a difficult edge case in the 911 ecosystem.
They were the private systems behind the public network: the PBX in a hospital, the communications platform across a university campus, or the telephone system serving a hotel, corporate headquarters, government complex, or manufacturing facility.
The public 911 network knew that a call came from the facility. The enterprise often knew where inside the facility it originated. Connecting those two pieces of information was the difficult part.
With Public Notice DA 26-1043, the Federal Communications Commission’s Public Safety and Homeland Security Bureau has taken an important step toward closing that gap. The Bureau deserves credit for recognizing that MLTS cannot remain an afterthought as the country transitions to Next Generation 911.
The notice grew out of a problem discovered during Verizon’s NG911 Phase 1 testing in Massachusetts. Some 911 calls from TDM-based MLTS customers using third-party Private Switch Automatic Location Identification services were being delivered to a national emergency call center instead of directly to the state’s NG911 core-services provider.
The carrier could transport the call, but it did not possess the enterprise location information maintained through the third-party PS/ALI arrangement.
That may sound like a narrow carrier implementation problem. It is not.
It exposes one of the most important challenges in the NG911 transition. The network cannot deliver information it does not receive, and the enterprise cannot provide that information unless the carrier gives it a supported path into NG911.
The FCC Moved Beyond the Individual Waiver
The FCC granted Verizon limited additional time to address the immediate problem. More importantly, the Bureau did not treat it as an isolated waiver involving one carrier and one state.
The Public Notice puts other wireline originating service providers on notice that they should examine their own MLTS and third-party PS/ALI relationships before receiving an NG911 Phase 1 or Phase 2 request.
That is the proactive regulatory guidance the industry needs.
Waiting until a live transition test fails, or until an emergency call follows the wrong path, is not an acceptable implementation strategy. The FCC is telling carriers, MLTS operators, NG911 service providers, and 911 Authorities to identify these seams now.
The notice also encourages legacy TDM-based MLTS users to consider moving to IP-based platforms. It does not order every legacy system to be replaced immediately. It recognizes that systems built around selective routers, static ALI records, and specialized circuit arrangements will become harder to sustain as the rest of the 911 environment moves to IP.
That alone moves the needle forward. But there is a larger opportunity here.
MLTS Is More Than a Source of Telephone Calls
An enterprise MLTS may be one of the most relevant sources of verified information available to NG911.
It can know that a call came from a particular building, floor, suite, classroom, hotel room, nursing station, laboratory, security desk, or conference room. In a modern IP environment, it may also know which user is associated with the device, how the endpoint is connected, whether it is fixed or nomadic, and whether it is operating on campus or remotely.
Once the MLTS is correlated with the enterprise network and other operational systems, the available context becomes much richer. The enterprise may maintain authoritative building maps, wireless access-point locations, endpoint registrations, access-control information, fire and environmental sensors, responder-access instructions, emergency-equipment locations, on-site hazards, and public-safety contacts.
This information should not be indiscriminately dumped onto a call taker’s screen. More data is not automatically better data. It must be verified, current, properly secured, relevant to the incident, and presented in a form the telecommunicator can use.
When those conditions are met, enterprise information can provide context that the traditional telephone network could never produce.
NENA’s NG911 architecture anticipates Additional Data about the caller, device, call, and location. An Additional Data Repository can contain information such as floor plans, on-site hazards, device details, medical information, and other incident-related context. That information may be delivered with the call, retrieved through a secure reference, searched using an identity, or discovered through a location-based query.
MLTS should be considered an important contributor to that environment, not simply another legacy system that must be pulled through a gateway.
The Value Does Not Stop at the Property Line
The most obvious use case is a 911 call placed from inside the enterprise. The MLTS and its associated systems can help identify the caller’s location and provide relevant facility information.
The potential value extends beyond calls originating inside the facility.
Consider a vehicle collision on a roadway bordering a university campus. The public caller may know only that the crash occurred near a large building. The university may have authoritative maps, nearby camera coverage, gate-access information, campus police resources, construction notices, or details about a blocked entrance.
A fire beside an industrial facility may involve hazardous materials, utility shutoffs, restricted access points, or evacuation considerations known to the facility but not immediately apparent to the caller.
An emergency near a school, hospital, stadium, transportation center, or government complex may be better understood when the incident location is correlated with verified information maintained by the neighboring enterprise.
The enterprise does not own the incident, and its data should never override the authority of the responding agency. Its systems can contribute location-relevant context through a trusted Additional Data mechanism.
That capability requires careful governance. Data must be validated, permissioned, secured, logged, and presented according to policy. The call taker should see what matters, not a stream of unfiltered sensor readings.
The architectural opportunity is real. NENA’s i3 framework permits Additional Data to be discovered through location-based queries, including information associated with an area rather than only with the calling device. That creates the foundation for correlating an external incident with relevant information from a nearby enterprise.
The FCC notice does not require this broader use of enterprise data. It does something more fundamental by reinforcing the responsibility to connect MLTS location information properly to NG911. Once that trusted connection exists, it can become the pathway for more useful context.
Responsibility Must Follow the Information
The FCC correctly recognizes that the MLTS operator may be the only party possessing detailed end-user location information.
A carrier cannot create the room number of a telephone it does not manage. A 911 Authority cannot maintain every enterprise’s internal moves, additions, and changes. An NG911 core-services provider cannot validate data that never reaches it.
The enterprise must maintain accurate information about its people, endpoints, and facilities. The originating service provider must provide a supported mechanism for carrying the required location and routing information. The NG911 environment must be able to validate, secure, and present it.
No single party can solve the entire problem alone.
This is why the Bureau’s emphasis on early communication matters. Carriers should not wait for the Phase 1 deadline to discover that thousands of MLTS endpoints depend upon PS/ALI records maintained outside their systems. Enterprises should not assume that a database arrangement created for legacy E911 will automatically function in an NG911 environment.
NG911 readiness must include the data path as well as the signaling path.
From Static ALI to Trusted Context
Legacy E911 taught us to associate a telephone number with a service address. PS/ALI extended that model into larger facilities by allowing enterprises to provide more specific location records. That was valuable, but it remained largely static.
NG911 gives us the opportunity to create a current relationship among the caller, device, enterprise, location, and incident.
The MLTS can become a trusted enterprise source. The Location Information Server can support current endpoint location. An Additional Data Repository can provide approved information about the caller, device, or facility. NG911 policy and routing functions can determine what information is relevant and where it should be delivered.
That is the future the FCC is helping enable.
The Public Safety and Homeland Security Bureau deserves praise for looking beyond the immediate waiver and issuing guidance to the broader industry. By putting carriers on notice, encouraging MLTS operators to engage, and reinforcing the need to migrate away from brittle TDM arrangements, the Bureau has made the NG911 transition safer and more practical.
The industry should stop treating MLTS as an obscure enterprise problem.
MLTS serves the places where people work, learn, recover, travel, and gather. It may know more about the caller’s immediate environment than any other system involved in the emergency call.
Used responsibly, that information can help 911 locate the emergency, understand the surroundings, and give responders better context before they arrive.
The FCC has moved the needle. Now carriers, enterprises, NG911 providers, and public safety must move with it.
Sources
- Federal Communications Commission, Public Notice DA 26-1043.
- Federal Communications Commission, Verizon Waiver Order DA 26-1042.
- Electronic Code of Federal Regulations, 47 CFR Part 9 — 911 Requirements.
- National Emergency Number Association, NENA i3 Standard for Next Generation 911.
- National Emergency Number Association, NG911 Guide for 911 Authorities.
Author’s note: This article reflects my personal views and is not an official statement of the Federal Communications Commission or any other organization.