4.2 Emergency Call Routing Function (ECRF) & LoST

4.2 Emergency Call Routing Function (ECRF) & LoST

Quick Answer: The Emergency Call Routing Function (ECRF) is the core NG911 spatial routing engine that replaces legacy tabular selective routers. Using the Location-to-Service Translation protocol (LoST, IETF RFC 5222), the ECRF takes a caller's geographic location (conveyed in a PIDF-LO) and a Service URN (such as urn:service:sos) and performs a real-time point-in-polygon spatial intersection against authoritative GIS boundary polygons to return the SIP URI of the destination PSAP. The LoST response includes a <serviceBoundary> GML polygon that allows clients to cache routing decisions. When nomadic callers dial 9-1-1 outside their home ESInet, the hierarchical Forest Guide (FG) discovers and routes queries to the authoritative remote ECRF.

---

Spatial GIS Routing vs. Tabular MSAG/Selective Router

In legacy Enhanced 9-1-1 (E9-1-1), emergency call routing relied on a rigid, multi-step tabular lookup architecture designed around the physical constraints of copper time-division multiplexing (TDM). When a 9-1-1 call arrived at an originating Central Office, the switch extracted the caller's 10-digit telephone number (ANI), matched it against a static Master Street Address Guide (MSAG) tabular range, mapped that range to an Emergency Service Number (ESN), and routed the call across dedicated Centralized Automatic Message Accounting (CAMA) trunks to a legacy selective router.

Next Generation 9-1-1 executes a complete architectural paradigm shift: tabular, static number-based routing is entirely replaced by dynamic, real-time spatial GIS polygon intersection.

---

The LoST Protocol (IETF RFC 5222)

The Location-to-Service Translation (LoST) protocol, standardized in IETF RFC 5222, is the foundational protocol used by endpoints, Originating Service Providers (OSPs), and Emergency Service Routing Proxies (ESRPs) to query the ECRF. LoST is an XML-based protocol transported over HTTP/HTTPS, employing a RESTful client-server paradigm.

+-----------------------+              LoST <findService> Request              +-----------------------+
|    Querying Client    | ---------------------------------------------------> |      ECRF Server      |
|    (ESRP / OSP / CHE) |    [Location (GML / Civic) + Service URN (RFC 5031)] |      (LoST Engine)    |
|                       | <--------------------------------------------------- |                       |
+-----------------------+          LoST <findServiceResponse> Message          +-----------------------+
                                [Destination PSAP SIP URI                                      |
                                 + GML <serviceBoundary> Cache]                                v
                                                                               +-----------------------+
                                                                               |  Authoritative GIS    |
                                                                               |  Boundary Polygons    |
                                                                               +-----------------------+

Structure of a LoST <findService> Query

A client constructs a <findService> request containing two mandatory components:

1. <location>: Contains the caller's location, formatted either as an RFC 5491 geodetic point/shape (GML) or an RFC 5139 civic address.
2. <service>: Contains an emergency Service Uniform Resource Name (URN) defined in RFC 5031 (typically urn:service:sos).

<!-- Example LoST findService Request -->
<findService xmlns="urn:ietf:params:xml:ns:lost1">
  <location id="caller-point-01" profile="geodetic-2d">
    <gml:Point xmlns:gml="http://www.opengis.net/gml" srsName="urn:ogc:def:crs:EPSG::4326">
      <gml:pos>39.739236 -104.990251</gml:pos>
    </gml:Point>
  </location>
  <service>urn:service:sos</service>
</findService>

Structure of a LoST <findServiceResponse>

The ECRF processes the spatial query and returns a <findServiceResponse> containing a <mapping> structure with:

• <uri>: The resolved destination SIP URI (e.g., sip:denver-psap@esinet.colorado.gov).
• <service>: The confirmed service URN.
• <displayName>: A human-readable identifier for the target emergency communications center.
• <expires>: A timestamp defining how long this routing mapping remains valid.
• <serviceBoundary>: An optional GML polygon describing the boundary of the PSAP service area. This allows the querying client (e.g., a mobile device or local ESRP) to cache the routing decision; as long as the device remains within that polygon, it does not need to re-query the ECRF for subsequent emergency calls.

<!-- Example LoST findServiceResponse -->
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
  <mapping expires="2026-09-14T00:00:00Z">
    <displayName>Denver 911 Communications</displayName>
    <service>urn:service:sos</service>
    <serviceBoundary profile="geodetic-2d">
      <gml:Polygon xmlns:gml="http://www.opengis.net/gml">
        <gml:exterior>
          <gml:LinearRing>
            <gml:posList>39.75 -105.01 39.75 -104.97 39.72 -104.97 39.72 -105.01 39.75 -105.01</gml:posList>
          </gml:LinearRing>
        </gml:exterior>
      </gml:Polygon>
    </serviceBoundary>
    <uri>sip:denver-psap@esinet.colorado.gov</uri>
  </mapping>
</findServiceResponse>

---

Service Uniform Resource Name (URN) Taxonomy (RFC 5031)

In legacy 9-1-1 networks, dialed digits (9-1-1) were routed indiscriminately to a primary answering point. In NG911, call signaling relies on standardized Service URNs governed by IETF RFC 5031. This allows networks to route sessions directly to specialized public safety entities based on incident discipline:

When a telecommunicator transfers a caller to fire dispatch, the NG9-1-1 Call Handling Equipment (CHE) issues a LoST query with the caller's location and a NENA responder URN such as urn:emergency:service:responder.fire, and the ECRF returns the URI of the fire agency serving that location. The urn:service:sos.* URNs describe the emergency service a caller requests; NENA's urn:emergency:service:responder.* URNs identify the responding agency for transfers and dispatch.

---

Point-in-Polygon (PIP) Spatial Containment Algorithms

When an ECRF evaluates a geodetic point (latitude and longitude), it executes a Point-in-Polygon (PIP) spatial containment algorithm within a spatial database (such as PostGIS):

1. Ray-Casting Algorithm: A theoretical ray is projected from the caller's coordinate point outward to infinity in any direction. The algorithm counts the number of times this ray intersects the edges of a PSAP boundary polygon:
   • Odd number of intersections: The point lies strictly inside the polygon.
   • Even number of intersections: The point lies outside the polygon.
2. Winding Number Algorithm: Computes the total number of times the polygon boundary winds around the coordinate point. A non-zero winding number indicates the point is inside the boundary. The winding number algorithm is computationally preferred when evaluating complex, self-intersecting, or concave jurisdictional polygons.

---

Boundary Topology Integrity: Gaps, Slivers, and Overlaps

NENA GIS standards mandate strict planar topology rules across all emergency service boundary layers. Two severe spatial defects must be rigorously eliminated during GIS data authoring:

BOUNDARY GAP (Unassigned Void):                 BOUNDARY OVERLAP (Dual Contention):
+------------------+     +------------------+   +------------------+==============+------------------+
|      PSAP A      | GAP |      PSAP B      |   |      PSAP A      | OVERLAP AREA |      PSAP B      |
|     Polygon      | (X) |     Polygon      |   |     Polygon      |     (X)      |     Polygon      |
+------------------+     +------------------+   +------------------+==============+------------------+
                    ^                                                              ^
         [Point X lands in void;                                         [Point X lands in both;
          Zero polygons match!]                                           Conflicting URIs returned!]

• Boundary Gaps / Slivers: Unintentional voids left between adjoining PSAP boundaries. If a caller's coordinate falls into a gap, zero polygons match, and the LoST engine returns a notFound error.
• Boundary Overlaps: Erroneous slivers where adjacent jurisdictions both claim the same geographic parcel. If a caller lands in an overlap, the ECRF detects multiple conflicting PSAP URIs, creating routing ambiguity.

---

Default PSAP Fallback Routing & Safety Nets

Under no circumstances may an NG911 network reject or drop an emergency call due to a spatial routing failure. When a point falls into a boundary gap, when geocoding fails, or when carrier location is missing or unparseable:

1. LoST Default Return: The ECRF returns a pre-configured Default PSAP SIP URI provisioned for that broader geographic region (e.g., a designated regional or countywide answering center).
2. ESRP Default Rule Execution: If the ECRF fails to respond or returns an unresolvable error code, the Emergency Service Routing Proxy (ESRP) triggers its pre-programmed default routing rule, delivering the call to a designated primary backup facility.
3. Automated Discrepancy Logging: Every default routing occurrence triggered by a spatial failure automatically logs an error record with the Discrepancy Reporting Web Service (DRS) so GIS personnel can remediate the boundary defect.

---

Inter-ESInet Routing & The Hierarchical Forest Guide (FG)

What happens when a caller in California dials 9-1-1 using an enterprise VoIP softphone provisioned by a corporate network in New York? Or when a mobile subscriber roams across a state line near an ESInet boundary?

A local ESInet's ECRF only maintains authoritative GIS boundary polygons for its own municipal, county, or state territory. When an ECRF receives a LoST query for coordinates outside its provisioned coverage, it cannot resolve the target PSAP. It resolves this through the Forest Guide (FG).

                                    +-----------------------------+
                                    |   Top-Level Forest Guide    |
                                    |          (National)         |
                                    +-----------------------------+
                                              /         \
                                             /           \
                +---------------------------+             +---------------------------+
                | Regional Forest Guide A   |             | Regional Forest Guide B   |
                |    (State / Regional)     |             |    (State / Regional)     |
                +---------------------------+             +---------------------------+
                         /                                              \
                        v                                                v
          +---------------------------+                    +---------------------------+
          |   Local ECRF (Region A)   |                    |   Local ECRF (Region B)   |
          +---------------------------+                    +---------------------------+

The Architecture of the Forest Guide:

• LoST Mapping Architecture (RFC 5582): The Forest Guide is not a monolithic database. In the LoST mapping architecture it is the entry point that knows which trees of LoST servers are authoritative for which coverage regions (loosely analogous to the root of the DNS hierarchy).
• Coverage Region Advertisements: Each Forest Guide peer advertises the broad geographic polygon boundaries (e.g., state borders or regional consortium footprints) for which its subordinate ECRFs are authoritative.
• Query Delegation Flow:
  1. The local ECRF receives a LoST query and evaluates the coordinates, determining they lie outside local coverage.
  2. The local ECRF queries the National or Regional Forest Guide.
  3. The Forest Guide inspects the coordinates against its coverage region database and refers or proxies the query to the authoritative remote ESInet ECRF.
  4. The remote ECRF performs the granular point-in-polygon lookup and returns the destination PSAP SIP URI.
  5. The originating ESRP routes the SIP session across inter-ESInet peering trunks directly to the destination network.