Key takeaways
- The LVF and the ECRF are two functions reading the same GIS. Both are functional elements in Next Generation Core Services, and both are LoST servers provisioned from the 911 Authority's GIS data. The LVF checks civic addresses before any call. The ECRF uses the caller's location during the call to decide where it routes.
- The LIS holds a different kind of record. It stores where a specific device is, and it belongs to the originating service provider. The GIS can confirm that the address in that record is routable. It can't confirm the phone is actually there.
- The worst failures don't throw errors. A stale record can pass validation, route correctly, and still send a responder to the wrong floor.
Every Next Generation 9-1-1 (NG9-1-1) architecture diagram has the same boxes in it. A Location Information Server (LIS) over here. An Emergency Call Routing Function (ECRF) and a Location Validation Function (LVF) over there. And down at the bottom, usually smaller than everything else and often colored gray, a cylinder labeled GIS.
Four boxes make this look like four pieces of technology to buy. It isn't. Two of the boxes are separate functions reading the same data, one holds a different kind of record entirely, and the small gray cylinder decides whether any of them work.
The differences are doing real work, and the diagram hides them.
What the gray cylinder actually is
Think of geographic information system (GIS) data like music and lyrics. One gives you the melody; the other gives you the meaning. Bring them together, and you have a song.
GIS data has two halves. One half is shape: a point, a line, or a polygon drawn in coordinates. A point might be a driveway, a line a street, a polygon a fire district. The other half is a table: street name, address number, municipality, responsible agency.
Neither half is worth much alone. A shape without a table is geometry; you can look at it, but you can't ask it anything. A table without a shape is a list; you can sort it, but you can't put it on the ground.
GIS binds the two so that every row belongs to exactly one shape. That's when you can ask questions neither half could answer. Which fire district is this address in? What's the nearest cross street? Does 400 Main Street actually sit on the stretch of Main that carries the 400 block?
The binding also makes disagreement visible. When the table says one thing and the geometry says another, GIS shows you. That's the property NG9-1-1 depends on.
LVF vs. ECRF: two functions, one source
Neither the LVF nor the ECRF is the data. Each is a functional element in Next Generation Core Services (NGCS), and each is a Location-to-Service Translation (LoST) protocol server. Under the NENA GIS Data Model, the 911 Authority's GIS data goes into the Spatial Interface, which then provisions the LVF and the ECRF.
The LVF runs before any call: at service initiation, when a location changes, and periodically after that. It validates the location of a fixed or nomadic device against the 911 Authority's provisioned GIS data. It answers whether an address can be found and routed. It doesn't answer whether the address is true, or whether the caller is actually there; no validation can.
The ECRF runs during the call. It takes the call's location, civic or geodetic, and uses the same GIS data to determine, primarily, which public safety answering point (PSAP) should receive the call.
The two are deliberately kept apart. NENA i3 requires the routing and validation functions to be separable, because routing happens in real time during the call while validation happens in advance, when data is provisioned. The routing function therefore carries much higher availability and response-time requirements. A provider can run both on the same servers or on separate clusters.
So these are two functions with different jobs, different timing, and different uptime demands, reading one source. If the GIS is right, both behave. If it's wrong, both are wrong in the same way.
Where it fails without an error
Suppose a desk phone moves from the third floor of an office building to the first, and the record underneath it doesn't. The LVF already passed the address, and it was right to. The ECRF sends the call to the right 911 center, because the building sits inside that center's boundary. The LIS delivers exactly what was provisioned into it.
Every component passes its own test. Nothing errors and nothing alarms, and the responder still goes to the wrong floor. There's no error message for right building, wrong floor.
The LVF can vouch only for the address. It can't vouch for the floor, suite, or room unless the GIS carries a value for each subaddress element of the dispatchable location. That's a costly requirement for GIS data, and routing doesn't need it; the call reaches the right 911 center either way. At a large building, the detail a responder needs most is the detail validation can't check.
Getting those subaddress elements is hard even in today's legacy 911 environment, before NG9-1-1 enters the picture. The FCC has required wireless carriers to deliver dispatchable location, meaning the street address plus the suite, apartment, or similar detail needed to find the caller, whenever it is technically feasible. Yet in its March 2025 Sixth Further Notice of Proposed Rulemaking on wireless location accuracy (FCC 25-22), the Commission called the number of wireless 911 calls delivered with dispatchable location "very small compared to the number of calls delivered with coordinate-based location information," and cited carriers' own live call data showing it on only about 0.9 percent of them.
The LIS holds a different record
The LIS stores the location of a specific endpoint: this phone, this device. When a call originates, the device or a network element queries the LIS, usually over HTTP-Enabled Location Delivery (HELD). It gets back either the location or a reference to it. Either way, the location travels with the call in a Presence Information Data Format Location Object (PIDF-LO).
That record should have cleared the LVF before it went in, which means it has to be built the same way as the GIS data behind the LVF: the same address elements, in the same structure and format that NENA's Civic Location Data Exchange Format (CLDXF) defines. If it isn't, it can't be validated, and a location that can't be validated ultimately won't be routable.
Who answers for that record is more settled than most people assume. Once a 911 Authority serves a Phase 2 valid request, 47 CFR § 9.29(b) puts the LIS on the originating service provider, and § 9.33 puts the cost there too. Getting an accurate record into that LIS is the harder part, especially from a multi-line telephone system, and it's the subject of the next piece in this series: Who Owns the LIS?
Three owners, one record
- The GIS data belongs to the 911 Authority and its designated GIS data providers. It's local government data, publicly funded.
- The ECRF and LVF are provisioned from that GIS through the Spatial Interface and run as part of Next Generation Core Services, usually by a vendor under contract.
- The LIS belongs to the originating service provider under the FCC's Phase 2 rule, whether the provider runs its own or buys the service.
That's three owners, usually with three different funding streams, and one record that has to stay right across all of them. When a phone moves floors, the multi-line telephone system may know it; the 911 database usually doesn't, and no rule says how the two stay in sync.
What each side can do
911 Authorities. Ask your NGCS provider how LVF failures get back to originating service providers and to your GIS team. Ask how long a GIS correction takes to reach the LVF and ECRF. Then decide whether you'll carry floor or subaddress data, and whether you can fund the people to maintain it.
NGCS providers. Show authorities the provisioning path end to end, from a GIS edit to a live routing change, with timestamps. Report validation failures back in terms a county GIS technician can act on.
Originating service providers. Revalidate on change, not just at install. A move inside a building is a location change. Treat floor and suite as part of the record, because the responder does.
The part that can't be bought
An agency can procure core services that include an ECRF and an LVF. A carrier can stand up or contract for a LIS. What nobody can buy is authoritative knowledge of where a county's addresses are, where its boundaries fall, and which building the third floor is in. That has to be created and kept current locally, by people who know the ground.
Every box on the diagram consumes that work. When it's good, the rest of the architecture is close to boring. When it isn't, the system fails politely, in valid formats, all the way to the wrong door.
If you're maintaining that data, or trying to fund the people who do, I'd like to hear how it's going.
Frequently asked questions
What is the difference between the LVF and the ECRF?
Both are NENA i3 functional elements in Next Generation Core Services, and both are LoST servers provisioned from the same 911 Authority GIS data. The Location Validation Function (LVF) checks a civic address before any call, at service initiation, when a location changes, and periodically after that. The Emergency Call Routing Function (ECRF) runs during the call and uses the caller's location to determine which public safety answering point should receive it. NENA i3 requires the two to be separable because routing has much higher availability and response-time requirements than validation.
Is the LVF a database?
No. The LVF is a function that answers validation queries. The data it reads is the 911 Authority's GIS, provisioned to it through the Spatial Interface. The ECRF reads the same data for routing.
Can the LVF validate a floor or suite number?
Only if the GIS carries a value for each subaddress element. If the GIS holds the building address but not its floors or suites, an address with a wrong floor can still validate. Routing doesn't need subaddress data, which is why most GIS doesn't carry it.
Who is responsible for the LIS in NG9-1-1?
Under 47 CFR § 9.29(b), once a 911 Authority serves a Phase 2 valid request, the originating service provider must put in place what it needs to use a Location Information Server or its functional equivalent, either by building it or acquiring the service. Under 47 CFR § 9.33, the provider also bears that cost.
This article is part of the NG9-1-1 location series. Next: Who Owns the LIS? For terms used here, see the NG9-1-1 & GIS glossary.
Sources
- NENA-STA-004, NENA Next Generation 9-1-1 United States Civic Location Data Exchange Format (CLDXF-US) Standard
- NENA-STA-005, NENA Standards for the Provisioning and Maintenance of GIS Data to ECRFs and LVFs
- NENA-STA-006, NENA Standard for NG9-1-1 GIS Data Model
- NENA-STA-010.3, NENA i3 Standard for Next Generation 9-1-1
- NENA-INF-027.1-2018, NENA Information Document for Location Validation Function Consistency
- NENA-INF-028, NENA Information Document for GIS Data Stewardship for Next Generation 9-1-1
- IETF RFC 8917, The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag
- 47 CFR § 9.16 — Multi-line telephone systems; dispatchable location requirements
- 47 CFR § 9.29 — Next Generation 911 transition requirements
- 47 CFR § 9.33 — Cost responsibilities
- FCC 25-22, Wireless E911 Location Accuracy Requirements, Sixth Further Notice of Proposed Rulemaking, PS Docket No. 07-114, 90 Fed. Reg. 19374 (May 7, 2025)