If you’ve worked in telecom for more than a few years, you probably have muscle memory around how 911 works. A subscriber dials 911, your Class 5 switch routes the call to the selective router, the PSAP gets the ANI, and then the ALI database is queried to find the caller’s street address. It’s been that way for decades.
However, states are gradually in the process of rolling out NG911. We gave an overview of the process last year:
- This process is driven by the states – although the FCC has provided some guidelines
- The states will likely roll this out in two phases – Phase 1 moves 911 to SIP trunks, and…
- Phase 2 adds new Location data into the calls – and that’s what we’ll be focusing on today/
We may all be familiar with the simple framework of ANIs and ALIs, but as Phase 2 of the NG911 transition rules start to roll out, that familiar workflow is about to change — in ways that may require you to make upgrades to your voice network.
From “ANI + ALI” to “Location in the Call”
Under the legacy E911 setup, the PSAP did the work of matching a phone number to an address. NG911 flips that around. In Phase 2, you, as the originating service provider, are responsible for delivering the caller’s location with the SIP call when it hits the state’s NG911 network.
That means:
- The call arrives at the ESInet (Emergency Services IP Network) already in NG911-compatible SIP (per the NENA i3 standard).
- The SIP INVITE typically includes a PIDF-LO — an XML “location object” that contains either a civic address (street address) or geodetic location (latitude/longitude).
- The NG911 Core Services (NGCS) use that location immediately for call routing and pass it on to the PSAP. No ALI dip required.
In short: the location isn’t “pulled” after the call arrives — it’s pushed with the call.
Two New Pieces of the Puzzle for Rural LECs
If you operate a largely landline-based rural network, the FCC’s Phase 2 requirements boil down to adding two main elements to your architecture.
1. Location Information Server (LIS)
Think of the LIS as your authoritative address book for every subscriber line you serve. Its job is to:
- Store validated, dispatchable addresses for each phone number.
- Provide that location to your switch or SBC at call time.
- Keep those addresses in sync with the state’s 911 GIS data via the Location Validation Function (LVF).
LIS-as-a-Service
Not every service provider will need to stand up their own LIS. In some deployments, the LIS function can be hosted and managed for you:
- In Canada: National policy requires the NG911 network provider (ESInet/NGCS operator) to offer a hosted LIS that originating carriers can use instead of operating their own.
- In the United States: The FCC rules put the responsibility on the OSP to use a LIS, but they allow outsourcing — including from a 911 authority’s ESInet provider.
Whether your state offers a hosted LIS will depend on its ESInet design and contracts. Even if the ESInet doesn’t offer this service, we are expecting third-party NG911 vendors will provide a LIS-as-a-service package that integrates with your provisioning and the state’s LVF/ECRF.
2. NG911 SIP Edge / SBC
Between your Class 5 switch and the state’s ESInet you’ll need a SIP-capable edge device — typically your SBC — that can:
- Terminate your internal trunks.
- Handle the location conveyance requirements for NG911.
- Meet the NG911 signaling profile that the state specifies.
- Hand off to the NG911 Delivery Point (the ESInet’s designated point of interconnect).
How location gets to the ESInet
There are two standards-compliant ways for your SIP edge to pass location on to the ESInet:
- Location-by-Value (LbyV):
- The SBC includes the full PIDF-LO (XML location object) in the SIP INVITE.
- This requires the SBC (or an upstream element) to query the LIS at call time (often via HELD or a vendor API) and insert the PIDF-LO before the call is sent.
- Location-by-Reference (LbyR):
- The SBC includes a secure URI in the SIP Geolocation header pointing to the caller’s record in the LIS.
- The ESInet/NGCS then dereferences the URI to retrieve the PIDF-LO.
Does my SBC support this?
The Metaswitch Perimeta supports the PIDF-LO header natively, but there’s no specific functionality to query a LIS from the Perimeta. This could be handled by routing the call to a LIS and handling a 302 response that adds the PIDF-LO or other headers into the message – which is similar to one of the methods used to add STIR/SHAKEN Identity headers into the call path.
What This Means for Your Network Operations
For a rural LEC, implementing Phase 2 isn’t just a paperwork exercise — it’s a small but significant architecture change.
- Provisioning changes: Your address management process will shift from “update ALI” to “update LIS” (with LVF validation).
- Network changes: You’ll need a LIS (in-house or hosted) and an SBC/gateway configured for NG911 i3 signaling and location conveyance (LbyV or LbyR).
- Testing: The FCC framework includes connectivity testing, so you’ll need to prove your SIP + location implementation works with the ESInet before going live.
- Coordination: You’ll work with your state 911 authority and their ESInet vendor to align on POIs, security (TLS/SRTP), location method, and data formats.
What Do I Need to Do?
This whole process will be driven by your state, and the timeline for implementation is entirely dependent on how your state chooses to roll this out. So until you receive a notification from your state that they’re planning to roll this out, your main job is to stay well-informed (e.g. by reading this newsletter!).
When your state is ready to roll this out, they will most likely start with Phase 1 (moving to SIP 911 trunks) and will only implement Phase 2 (adding the Location Information) once Phase 1 is complete. The details of how this all works will vary by state, depending on how they have implemented the ESInet, and who is providing the LIS.
We are very happy to help guide you through the implementation when the time comes – don’t hesitate to reach out to us for help with building new SIP trunks, configuring your SBC, and integrating with the LIS and the ESInet.
