ALI/MSAG vs. Transitional LDB Routing

By Sandi C. Stroud, ENP · Published October 26, 2026

Key takeaways

• Civic-address calls don't wait for i3. While the PSAP boundary routes coordinate calls, wireline, VoIP and MLTS calls keep routing on one of two paths: traditional ALI/MSAG or transitional LDB.
• The paths differ in what the address is checked against. ALI/MSAG checks a service order against a table of street ranges. The LDB is supposed to check it against your GIS through the LVF.
• Compare ALI to your GIS once, before an i3 CHE goes live. If the CHE expects a PIDF-LO, the LDB has to produce a properly populated one for every legacy caller, and that depends on a one-time ALI-to-GIS comparison and remediation.
• The LDB is where MLTS shows up first. The LDB lets you test geospatial routing for every device before an FCC Phase 2 request, but only for records that LVF-validate. MLTS records with building, floor and room details start failing that test long before the request is made.

In Part 2, I said civic-address calls stay on traditional ALI/MSAG routing or transitional LDB routing while your address data catches up, and promised a post on the difference. This is that post. In my opinion, it covers the least discussed but extremely important step that must be taken before you can deploy an i3 CHE system or make an FCC Phase 2 request.

Both paths get a landline call to the right PSAP today. What changes is the test a service order has to pass. On ALI/MSAG, the street and house number only have to fall inside an MSAG range, and the ESN on that range picks the PSAP. On the LDB, the LVF should have to match the address to one address point or road centerline in your GIS, so that the legacy address can be converted and stored as an i3 standards-formatted address. Then the LDB can produce a PIDF-LO object the ESRP can send to the ECRF so that geospatial call routing of all devices can be tested and operational before making the FCC Phase 2 request.

Traditional ALI/MSAG routing

This is the E9-1-1 path most centers have run for decades.

1. The service order comes in. When a phone line is installed or moved, the carrier sends the subscriber's address to the ALI (automatic location identification) database provider.
2. The address is checked against the MSAG. The master street address guide is a table: street names, address ranges, odd or even, community, and the emergency service number (ESN) for each range. If the service order's address falls in a range, it's MSAG-valid and takes that range's ESN.
3. The call routes on the ESN. When the caller dials 911, the selective router looks up the number, finds its ESN, and sends the call to the PSAP that ESN belongs to.
4. The PSAP pulls the address. The call taker's screen queries the ALI database by phone number and displays the stored address.

Notice what's missing: a map. MSAG validation checks that a street and number exist in a table. It never asks where the address sits on the ground, or which PSAP boundary it falls inside. The ESN does that job, so the ESN has to be right.

Transitional LDB routing

The location database (LDB) is the bridge. It's a database the 911 Authority pays for, and is kept current by the originating service provider (OSP) submitting the same new service orders it used to send to ALI. It starts with a one-time load of today's ALI records, matched to your GIS (more on that below); after that, it works like this:

1. The service order comes in, the same way. The i3 standard expects the legacy gateway's location database to be provisioned through "the existing provisioning flows, systems, and interfaces that are used for provisioning legacy ALI databases today" (NENA-STA-010.3, section 6.1.3).
2. The legacy record is matched to your GIS and converted. Instead of an MSAG table, the legacy record is matched through the location validation function (LVF) against either a site/structure address point or a road centerline range in your provisioned GIS. The GIS has to answer the same question the MSAG did, which ESN and MSAG community the address belongs to, and the ALI record also has to match the correct address details for that location: house number, street name and community. That match is used to convert the location into an i3-formatted location record, and the LDB stores it that way so it can do a legacy-to-i3 lookup and create the PIDF-LO during the call path.
3. The call routes on the location. When a legacy call arrives, the LDB looks up the i3-formatted record for that caller and creates a PIDF-LO (Presence Information Data Format Location Object), the standard location container in NG911. The ESRP (emergency services routing proxy) sends it to the ECRF, which matches it against your GIS and returns the PSAP.
4. The PSAP gets the same location. The record that routed the call is the one the call taker sees (NENA-STA-010.3, section 6.1.3).
5. The LDB is supposed to be re-validated against the LVF. Every time new GIS data is provisioned through the Spatial Interface (SI), the LDB's records should be verified against the LVF again, so a record that matched last month's GIS still matches this month's. NENA treats LVF validation as the analogue of MSAG validation, with civic locations validated before a call is ever placed and revalidated periodically as GIS changes are made (NENA-STA-010.3, executive overview).

The ESN drops out of the routing decision. What decides where the call goes now is whether the address matches your address points and road centerlines, inside the right PSAP boundary, as Part 3 laid out. That's the real value of the LDB: geospatial call routing for every device can be tested and running before you make the FCC Phase 2 request.

Side by side

What your GIS has to stay in step with

NENA is blunt about the transition: "all GIS data layers need to fulfill both Enhanced 9-1-1 (E9-1-1) and NG9-1-1 requirements," and the transition "is likely to be lengthy" (NENA-INF-046.1, section 1). So your GIS serves both paths at once.

For calls still on ALI/MSAG, your GIS and the MSAG and ALI need to agree. That means road centerlines and address points carrying the legacy elements, ESN (left and right on centerlines), MSAG community and legacy street name, so you can compare them record by record. Comparing the two "will identify inconsistent naming conventions, inaccurate address information, improper ESN assignments to MSAG records," and more, and errors "can exist in both databases" (NENA-INF-034.1.1, section 2.2). A mismatch tells you two records disagree, not which one is wrong.

For calls on the LDB, your GIS is the validator. Everything in Part 3 applies: CLDXF-conformant fields, one and only one match, real road centerline ranges, and every feature in or on the right PSAP boundary. The bonus: once the LDB is validating against your GIS, the legacy MSAG is no longer needed, so the resources that went into maintaining it can be put to work elsewhere.

For both, keep the legacy elements in your GIS until you're done with them, even after the MSAG table itself is retired. They're how you prove an address point lands in the same PSAP its ESN says it should, and NENA expects them to fall away only "upon completion of full transition to end state" (NENA-INF-046.1, section 1).

Before GIS can stand in for MSAG/ALI: the one-time comparison

The LDB only works if the legacy records already in ALI can be matched to your GIS. That takes a one-time ALI-to-GIS comparison and remediation, done before the LDB takes over, so your GIS data can replace the MSAG and ALI in the interim until the FCC Phase 2 request is made.

NENA describes the method: geocode the ALI database against your road centerlines and address points. Beyond catching discrepancies, it "simulates the behavior of how 9-1-1 calls from the ALI database will plot to the GIS data," and "corrections may be required of the GIS street centerline data, the MSAG data or both" (NENA-INF-034.1.1, section 3.2.2). The site/structure comparison works the same way, field by field, against your address points (section 3.2.3).

To do this, your GIS location data has to carry the conditional legacy address elements in the NG911 GIS Data Model, MSAG Community and ESN, on your address points and road centerlines (NENA-STA-006.3). Without them, there's nothing to compare an ALI record against except the street name.

What it takes:

1. Compare every ALI record to the GIS. Match each one to an address point or a road centerline range, checking both the legacy answer (ESN and MSAG community) and the address details (house number, street name and community).
2. Work every mismatch to its source. Fix the GIS, the MSAG or the ALI record, whichever is wrong, and coordinate the fix with the service providers who keep ALI.
3. Load the matched records into the LDB. Each one converts to an i3-formatted location record that can produce a PIDF-LO.
4. Then keep it current. New service orders and every SI provisioning get validated against the LVF from here on.

Plan for this to take time. A no-match ALI record doesn't tell you whether the GIS data is wrong or missing, or whether the ALI record is wrong. Finding out often means GIS teams investigate in other databases, such as parcel records. Sometimes the answer is on the street itself: a road sign that was misprinted and doesn't match the road's official name, so the ALI, the GIS and the sign each say something different.

A caution for 911 Authorities and GIS professionals: this has to be done before an i3 call handling system (CHE) goes into production. If the CHE expects to receive a PIDF-LO, the LDB has to be stood up and able to produce a properly populated PIDF-LO for every legacy caller. An LDB built on records that were never compared and remediated will hand the CHE incomplete or wrong locations on day one.

Where MLTS starts to bite

Here's where it gets harder. The LDB is supposed to LVF-validate every location that goes into it, and that includes records from multi-line telephone systems (MLTS).

MLTS operators are required to provide a dispatchable location with 911 calls (47 CFR § 9.16), and the FCC defines dispatchable location as the validated street address plus details like suite, floor or room (47 CFR § 9.3). So an MLTS record headed for the LDB often carries building, floor and room details.

As Part 3 noted, some 911 GIS data stores those details for public buildings, but likely not for private ones, because there's no access to collect them. Run those MLTS records through the LVF and the street address may match while the sub address can't. Depending on the LVF, that comes back invalid or unchecked, and either way it lands somewhere: on the OSP deciding whether to load it, and on the 911 Authority's GIS team as a discrepancy report it can't resolve.

That problem shows up as soon as the LDB is validating, and it means those devices can't be fully tested on geospatial routing well before a 911 Authority makes an FCC Phase 2 request under 47 CFR § 9.29 and the OSP has to stand up its own LIS. The routing-bar answer from Part 3 still holds: if the primary address elements match, the call reaches the right PSAP. But someone has to decide what the LDB does with every MLTS record that can't fully validate, and that decision is better made now than discovered later. The next post in this series takes MLTS on directly.

Questions to settle now

For 911 authorities

1. Which of our civic-address calls route on ALI/MSAG today, and which on an LDB?
2. Has the one-time ALI-to-GIS comparison been done and every mismatch remediated?
3. If our i3 CHE expects a PIDF-LO, can our LDB produce a properly populated one for every legacy caller before go-live?
4. Have we budgeted enough time for the comparison, including research in parcel records and field checks of road signs?
5. If we have an LDB, is every record actually being validated against the LVF, and re-validated each time new GIS data is provisioned through the SI?
6. What does our LDB provider do with an MLTS record whose street address validates but whose sub address doesn't: load it, reject it, or flag it?
7. Who answers the discrepancy reports those records generate, and what can they realistically fix?

For GIS stewards

• Populate the conditional legacy elements, MSAG Community and ESN, on your road centerlines and address points; you need them for the ALI comparison and until the last call leaves ALI/MSAG.
• Run the MSAG and ALI comparison, and treat every mismatch as "two records disagree," not "the GIS is wrong."
• After every SI provisioning, confirm the LDB was re-validated against the LVF, and review what newly fails.
• Track LVF discrepancy reports from MLTS records separately, so sub address gaps don't bury routing errors.

For vendors and LDB providers

• Show how service orders are validated against the LVF, and what happens to records that fail.
• Report MLTS records that match on the street address but not the sub address as their own category.
• CHE vendors: state whether your system expects a PIDF-LO for legacy calls, and test it against the LDB before go-live.

Bottom line

ALI/MSAG and the LDB both get civic-address calls to the right PSAP during the transition. The difference is what the address is checked against: a table, or your GIS. Getting from one to the other takes a one-time ALI-to-GIS comparison, with MSAG Community and ESN in your GIS, and it has to be finished before an i3 CHE goes live. Once it's your GIS, every MLTS record with a sub address you can't collect becomes your problem too, and it starts the day the LDB starts validating, not the day you deploy an i3 CHE or make a Phase 2 request.

Where does your data stand? Ground Truth GIS checks your road centerlines and address points, and optionally your MSAG and ALI, against NENA-STA-006.3, and labels each finding by what it affects. It's free, and your files never leave your computer.

Next in the series: MLTS databases, and what 911 Authorities can and can't validate inside private buildings.

Frequently asked questions

What is the difference between ALI/MSAG routing and LDB routing in NG911?

In traditional ALI/MSAG routing, a service order address is validated against the master street address guide (MSAG) table and assigned an emergency service number (ESN), and the selective router uses the ESN to pick the PSAP. In transitional location database (LDB) routing, the service order address is supposed to be validated against the 911 Authority's GIS through the location validation function (LVF), matched to an address point or road centerline range, converted to an i3-formatted location record, and delivered as a PIDF-LO that the ESRP sends to the emergency call routing function (ECRF), which picks the PSAP from the boundary the address falls in.

What is a location database (LDB) in NG911?

An LDB is a database of civic locations used during the transition to NG911. The 911 Authority pays for it, and the originating service provider (OSP) updates it with new service orders, the same way it updated the ALI database. Each legacy record is matched to an address point or road centerline range in the 911 Authority's GIS and stored as an i3-formatted location record. When a call arrives, the LDB looks up that record and creates a PIDF-LO the ESRP sends to the ECRF. That lets a 911 Authority test geospatial routing for all devices before making an FCC Phase 2 request.

Why does an ALI-to-GIS comparison have to happen before an i3 CHE goes live?

An i3 call handling system (CHE) expects a PIDF-LO with every call. For legacy callers, that PIDF-LO comes from the location database (LDB), which can only produce it for records that were matched to the 911 Authority's GIS. A one-time comparison and remediation of the ALI data against the GIS (NENA-INF-034.1.1) is what makes those matches possible. It needs MSAG Community and ESN populated in the GIS, it can take a long time, and it has to be done before the CHE goes into production.

Does GIS data still need ESNs during the NG911 transition?

Yes. NENA notes that during transition, GIS data must meet both E9-1-1 and NG9-1-1 requirements (NENA-INF-046.1). Keeping ESN, MSAG community and legacy street name on road centerlines and address points lets GIS stewards synchronize with the MSAG and ALI, run the one-time ALI-to-GIS comparison, and confirm that features fall in the correct PSAP.

Why are MLTS records a problem for LVF validation?

MLTS operators must provide a dispatchable location, which includes details like building, floor or room. Many 911 GIS datasets don't store those details for private buildings, because there's no access to collect them. When the LDB validates MLTS records against the LVF, the street address may match while the sub address can't, creating invalid or unchecked results and discrepancy reports the 911 Authority can't easily resolve.

Does the MLTS validation issue wait for an FCC Phase 2 request?

No. The issue starts as soon as an LDB validates locations against the LVF, which should happen before a 911 Authority makes a Phase 2 request under 47 CFR § 9.29, so geospatial routing can be tested first. MLTS records that can't validate are the ones that can't be fully tested.

← All insights