4.3 Location Validation Function (LVF) & Legacy Gateways

4.3 Location Validation Function (LVF) & Legacy Gateways

Quick Answer: The Location Validation Function (LVF) is a core Next Generation Core Services (NGCS) functional entity that validates civic addresses prior to call origination (during service provisioning) using the identical LoST protocol (RFC 5222) and authoritative GIS layers as the ECRF, completely replacing the legacy Master Street Address Guide (MSAG). During the phased migration from legacy E9-1-1 to full NG911, three transitional gateways maintain backward compatibility: the Legacy Network Gateway (LNG) interfaces legacy originating TDM/wireless networks to the ESInet; the Legacy PSAP Gateway (LPG) converts ESInet SIP sessions into CAMA/PRI signaling and emulates an ALI database for legacy call-taking consoles; and the Legacy Selective Router Gateway (LSRG) enables bi-directional inter-tandem trunking and call transfers between the ESInet and legacy E9-1-1 selective routers.

---

The Location Validation Function (LVF) Architectural Role

In legacy 9-1-1, telecommunications carriers validated customer service addresses against a static, tabular Master Street Address Guide (MSAG) maintained by the incumbent local exchange carrier (ILEC). If a subscriber's address contained a slight spelling discrepancy, directional error, or fell outside a provisioned street range, service provisioning halted. MSAG updates required cumbersome 24- to 72-hour batch file exchanges across multiple carrier boundaries.

In Next Generation 9-1-1, the Location Validation Function (LVF) completely replaces the legacy MSAG. The LVF is a specialized validation service hosted on the ESInet that allows Originating Service Providers (OSPs)—including wireline telcos, broadband ISPs, and interconnected VoIP providers—to verify that a customer's civic address is valid and spatially routable prior to service activation.

Core Differences: LVF vs. ECRF

Although the LVF and the Emergency Call Routing Function (ECRF) utilize the exact same LoST protocol (RFC 5222) and query the exact same GIS spatial database, their operational timing and objectives are fundamentally distinct:

PRE-CALL SERVICE PROVISIONING (LVF):
[ Customer Orders VoIP Service ] ──► [ Carrier Provisioning ] ── LoST Query ──► [ LVF Engine ] ◄── [ GIS Layers ]
                                                                                   │
                                     [ Status: Valid / Invalid / Ambiguous ] ◄─────┘

REAL-TIME EMERGENCY CALL PROCESSING (ECRF):
[ Citizen Dials 9-1-1 ] ──► [ SIP INVITE ] ──► [ ESRP Ingress ] ── LoST Query ──► [ ECRF Engine ] ◄── [ GIS Layers ]
                                                                                   │
                                     [ Destination PSAP SIP URI Returned ] ◄───────┘

---

The Spatial Interface (SI) & GIS Data Synchronization

How do the LVF and ECRF maintain absolute data integrity? Under NENA-STA-010, local municipal and county GIS authorities do not manually edit the ECRF/LVF directly. Instead, they publish spatial updates through the Spatial Interface (SI).

Required GIS Layers Provisioned via the Spatial Interface (NENA-STA-006):

1. Site/Structure Address Points (SSAPs): Highly accurate spatial point locations representing individual building footprints, primary access points, and sub-units.
2. Road Centerlines: Vector line layers containing street names, address number ranges (left/right parity), and administrative boundary tags.
3. PSAP Boundary Polygons: Polygons delineating the primary geographic jurisdiction of every answering center.
4. Emergency Service Boundaries (ESBs): Independent polygon layers defining response districts for law enforcement, fire/rescue, and emergency medical services (EMS).
5. Provisioning Boundary: Polygons defining the area for which each GIS data provider is authoritative, so the Spatial Interface accepts a provider's features only inside its boundary.

NENA Quality Guidance: NENA's GIS-MSAG-ALI synchronization guidance (NENA 71-501) recommends reaching at least a 98% match rate before relying on GIS data for ECRF and LVF services, and many state programs set stricter targets. Because the LVF and ECRF are provisioned from the same GIS layers, an address that validates should route correctly, but boundary errors can still misroute calls, so discrepancy reporting remains essential.

---

Transitional Migration Architecture in NG911

The migration from legacy E9-1-1 to Next Generation 9-1-1 is a complex, multi-year evolutionary process. Public safety agencies cannot execute a simultaneous nationwide "flash cut." Consequently, NENA i3 specifications define three specialized transitional gateways to bridge legacy TDM networks with the IP-based ESInet:

+---------------------------------------------------------------------------------------------------+
|                                TRANSITIONAL GATEWAY ARCHITECTURE                                  |
|                                                                                                   |
|  [ Legacy Carrier Network ]                                              [ Legacy PSAP CPE ]      |
|  (Wireline CO / Mobile MSC)                                              (Non-IP Call Consoles)   |
|           │                                                                       ▲               |
|           │ CAMA MF / SS7 ISUP Trunks                                             │ CAMA / PRI    |
|           ▼                                                                       │ (Serial ALI)  |
|   +---------------+      SIP INVITE (LbyV)      +-------------------+             │               |
|   | Legacy Network| --------------------------> |                   |     +---------------+       |
|   | Gateway (LNG) |                             |     EMERGENCY     | ──> |  Legacy PSAP  | ──────┘       |
|   +---------------+                             |    SERVICES IP    |     | Gateway (LPG) |       |
|           │ Queries                             |      NETWORK      |     +---------------+       |
|           ▼ (Legacy ALI)                        |      (ESInet)     |                             |
|     [ Legacy ALI ]                              |                   |                             |
|                                                 +-------------------+                             |
|                                                           ▲                                       |
|                                            Bi-directional │ SIP / CAMA Trunking                   |
|                                                           ▼                                       |
|                                                 +-------------------+                             |
|                                                 |  Legacy Selective |                             |
|                                                 |  Router Gateway   |                             |
|                                                 |      (LSRG)       |                             |
|                                                 +-------------------+                             |
|                                                           │                                       |
|                                                           ▼ CAMA / SS7 Inter-Tandem Trunks        |
|                                                 [ Legacy Selective ]                              |
|                                                 [  Router Switch   ]                              |
+---------------------------------------------------------------------------------------------------+

---

1. Legacy Network Gateway (LNG)

The Legacy Network Gateway (LNG) is deployed at the ingress perimeter of the ESInet facing legacy Originating Service Providers. It acts as the bridge connecting legacy Central Offices (COs) and wireless Mobile Switching Centers (MSCs) to the modern NGCS core.

Core Engineering Functions of the LNG:

1. Signaling Ingress Conversion: Receives legacy TDM trunk signaling—including Centralized Automatic Message Accounting (CAMA) multi-frequency (MF) tones and SS7 ISDN User Part (ISUP) call setup messages.
2. Location Discovery & Extraction: In legacy networks, location is not delivered in the voice path. The LNG extracts the caller's 10-digit telephone number (ANI) or wireless pseudo-ANI (pANI / ESRK / ESRD) and initiates an out-of-band location lookup to the legacy ALI database (or the wireless MPC/GMLC) using standardized interfaces such as E2.
3. PIDF-LO Construction: The LNG converts the tabular ALI record or geodetic coordinate into an RFC 4119 / RFC 5139 compliant PIDF-LO XML document.
4. SIP Session Generation: The LNG constructs an RFC 3261 SIP INVITE addressed to urn:service:sos, embeds the newly created PIDF-LO as Location by Value (LbyV) in a multipart MIME body, and transmits the call across the Border Control Function (BCF) into the ESInet.

---

2. Legacy PSAP Gateway (LPG)

The Legacy PSAP Gateway (LPG) is deployed at the egress perimeter of the ESInet facing an answering center that has not yet upgraded its Call Handling Equipment (CHE) to native NENA i3 SIP capabilities.

Core Engineering Functions of the LPG:

1. SIP-to-TDM Signaling Conversion: Receives native SIP INVITE requests from the ESInet (via the BCF) and converts them into legacy analog CAMA MF trunk signaling or ISDN Primary Rate Interface (PRI) signaling compatible with legacy PSAP PBX hardware.
2. Voice Media Decoding: Decodes IP-based RTP media streams (G.711 mu-law) and outputs standard 64 kbps DS0 analog/TDM voice channels.
3. Emulated ALI Database: Because legacy call-taking consoles cannot parse SIP signaling or XML PIDF-LO documents, the LPG operates as an emulated local ALI database:
   • When an incoming call arrives, the LPG extracts the PIDF-LO from the SIP INVITE and populates an internal temporary cache indexed by the caller's ANI.
   • When the legacy call-taker console answers the trunk, it automatically initiates an out-of-band ALI dip over an RS-232 serial connection or point-to-point IP link.
   • The LPG intercepts the serial dip, formats the cached PIDF-LO data into a NENA-format tabular ALI record the legacy console already understands, and returns it to the console screen.

---

3. Legacy Selective Router Gateway (LSRG)

The Legacy Selective Router Gateway (LSRG) provides bi-directional inter-tandem trunking between an ESInet and an incumbent legacy E9-1-1 Selective Router (SR). The LSRG is indispensable during phased regional cutovers, allowing calls to be transferred seamlessly between modernized NG911 PSAPs and legacy PSAPs.

Two Primary Operational Use Cases of the LSRG:

Use Case A: ESInet to Legacy Selective Router (NG911 PSAP -> Legacy PSAP Transfer)

An NG911 PSAP receives a call that belongs to an adjacent rural jurisdiction whose PSAP still operates on a legacy selective router:

1. The NG911 telecommunicator initiates a transfer in CAD/CHE.
2. The ESInet ESRP routes the SIP INVITE to the LSRG.
3. The LSRG converts the SIP session into dedicated CAMA or SS7 inter-tandem trunks connecting to the legacy Selective Router.
4. The LSRG maps the call to a pseudo-ANI or legacy Emergency Service Number (ESN) recognized by the selective router, ensuring the selective router directs the call to the appropriate legacy PSAP.

Use Case B: Legacy Selective Router to ESInet (Legacy PSAP -> NG911 PSAP Transfer)

A legacy Central Office or legacy selective router receives a call that must be routed to a modernized PSAP operating on the ESInet:

1. The legacy selective router forwards the call across inter-tandem trunks to the LSRG.
2. The LSRG extracts the calling digits, performs a location dip to acquire tabular ALI data, and converts the information into a PIDF-LO.
3. The LSRG issues an RFC 3261 SIP INVITE with urn:service:sos and embedded PIDF-LO into the ESInet, where the ESRP and ECRF take over routing.

---

Summary of Transitional Gateway Functions