NGCS Functional Elements Explained: BCF, ESRP, ECRF, and More

In 1891, Almon Brown Strowger, a Kansas City undertaker, patented a way to take human telephone operators out of the equation.

As the story goes, a local operator who was married to a rival undertaker was steering bereaved customers to her husband’s parlor. That story may be fabricated, but what we do know for certain was that Strowger’s solution was authentic. 

This solution meant that, for the first time in history, a telephone call could route itself. 

For decades, telephone exchanges used these electromechanical switches to automatically connect calls, moving a metal arm through a bank of connections until it reached the line the caller had dialed. 

The selective routers that carried Enhanced 911 into the 2000s were far more capable than Strowger’s switch, but they used the same basic idea that call routing was largely predetermined. A 911 call arrived over provisioned telephone trunks, and the selective router used stored information about the caller to send it to the designated ECC. Changing those routing arrangements typically meant updating databases, circuits, and carrier configurations.

Next Generation 911 (NG911) transfers that decision into software. 

A 911 call arriving on an Emergency Services IP Network (ESInet) today is handled by a sequence of functions, each one asking and answering a single question. Is this call permitted onto the network? Where is the caller standing? Which agency serves that ground? Is that agency taking calls at this moment? Those functions carry names, and collectively they are known as “Next Generation Core Services,” or “NGCS.”

This guide explains what NGCS is, defines each functional element in plain language, walks the path a call takes through them, and covers the standards that govern how they behave. 

What NGCS Means in the NG911 Architecture

Next Generation Core Services is the software-defined call routing, location management, policy, and interconnection infrastructure that takes over the work that legacy selective routing used to perform. NGCS obtains, validates, stores, and routes the IP-based voice, text, and data moving through an NG911 system.

The distinction between NGCS and an ESInet is the one buyers most often need clarified. In short, an ESInet is the managed IP transport layer – think of it as the roadway. NGCS is everything that governs traffic on that roadway: the gate at the on-ramp, the addressing system that identifies destinations, the dispatcher’s ability to reroute during a surge, and the log that records where every vehicle went. Our companion guide, What Is an ESInet?, covers the transport layer in depth.

Most jurisdictions procure the two together, under a single contract held by a primary service provider. That provider is accountable for bringing the component subsystems into one functioning service, which is why understanding the elements individually matters during evaluation.

NGCS Functional Elements Explained

NENA’s i3 architecture defines these elements by the function they perform rather than the box they run in. Several may run on shared infrastructure. Several are duplicated many times over across a call’s journey. The names describe roles.

BCF: Border Control Function

The BCF is the perimeter. It sits at every point where the ESInet meets an outside network: originating carriers, neighboring ESInets, and interconnected service providers. It admits legitimate emergency traffic, rejects everything else, and normalizes the signaling that passes through so that the network behind it sees consistent, well-formed sessions.

In the i3 architecture, the BCF pairs a firewall with a session border controller. Its security responsibilities are substantial. Telephony denial-of-service attacks, malformed SIP messages, and registration floods all arrive at the border, and the BCF is where they stop.

SBC: Session Border Controller

The SBC is the session-handling component operating within the BCF. It manages SIP signaling and media streams across the boundary: anchoring media paths, hiding internal network topology from external parties, handling address translation, and transcoding between codecs when the originating network and the receiving agency speak different audio formats. When call quality problems trace to a specific carrier interconnection, the SBC is usually where the diagnosis begins.

ESRP: Emergency Services Routing Proxy

The ESRP is the decision-maker. It is a SIP proxy that receives a call, determines where the call should go next, and forwards it. A single 911 call typically passes through several ESRPs in sequence – one on entering the ESInet, one at the state or regional level, one serving the destination agency  –  with each handoff narrowing the destination.

The ESRP does not hold the answers itself. It asks. For location-based destinations it queries the ECRF. For operational conditions it consults policy. Then it acts on what comes back.

PRF: Policy Routing Function

The PRF holds the rules the ESRP applies. Policy is where an agency’s operational reality enters the routing decision: time-of-day rules, queue depth thresholds, overflow and diversion arrangements with neighboring agencies, call-type handling, and the alternate destinations that take effect when a center goes dark.

This is the element that separates NG911 routing from everything before it. A jurisdiction can change its own call-handling behavior by editing a policy rule, and the change takes effect on the next call. Under selective routing, the equivalent change was a service order with a lead time measured in weeks.

ECRF: Emergency Call Routing Function

The ECRF answers the question of jurisdiction. Given a caller’s location  –  a civic address or a set of coordinates  –  and the service being requested, it returns the address of the agency responsible for that ground. It does this using the LoST protocol, an IETF specification designed for exactly this purpose, and it draws its answers from GIS boundary data.

The ECRF is where the accuracy of a state’s geospatial data becomes operationally visible. Boundaries maintained carefully produce correct routing. Boundaries with gaps, overlaps, or stale annexations produce calls delivered to the wrong center. 

LVF: Location Validation Function

The LVF uses the same interface as the ECRF and runs before any call is placed. When an originating service provider (OSP) provisions a subscriber address, the LVF checks that address against the authoritative GIS data and confirms it can be routed. Addresses that fail validation get corrected while there is time to correct them, rather than during an emergency.

LDB: Location Database

The LDB stores location records associated with subscribers and devices. In deployments still carrying transitional traffic, it performs the role ALI held in the E911 world, supplying the location information delivered alongside a call to the answering position.

LIS and HELD: Where Wireless and VoIP Location Originates

A Location Information Server is maintained by the originating service provider and holds the current location of a device on that provider’s network. HELD, which stands for HTTP-Enabled Location Delivery, is the IETF protocol used to retrieve that location, either as a value delivered with the call or as a reference the network dereferences during call processing. HELD is a protocol rather than a functional element, and it is worth being precise about that distinction when reading a specification. The element that performs the dereference during a live call is the Location Retrieval Function, or LRF.

The i3 Logging Service

Every functional element that touches a call writes an event to the logging service, in a standardized i3 format, with synchronized timestamps. The result is a reconstructible record of a call’s full path across every element and every network it crossed. For after-action review, for regulatory reporting, and for the moment a call went somewhere unexpected, this log is the evidence.

Elements You Will Come Across During Transition

Few jurisdictions arrive at end-state NG911 in a single step. Legacy Network Gateways and Legacy PSAP Gateways translate between IP and TDM worlds so that a modernized network can serve agencies still operating legacy call handling equipment, and so that carriers still delivering traffic over legacy trunks can reach an ESInet. These gateways are designed to be removed.

How the Elements Work Together to Route a Call

If we were to follow a single wireless 911 call from a highway shoulder, we’d see that after the caller dials 911, the originating carrier’s network establishes a SIP session and attaches the caller’s location, either as coordinates delivered with the call or as a reference the emergency network can dereference from the carrier’s LIS.

The session arrives at the ESInet’s edge and meets the BCF. The BCF authenticates the interconnection, inspects the signaling, and admits the session. The SBC anchors the media path and normalizes the codec.

The first ESRP receives the call. Before choosing a next hop, it sends the caller’s location to the ECRF, which compares that location against the GIS boundary layers and returns the URI of the agency whose jurisdiction contains the point. The ESRP then evaluates the applicable PRF rules: whether the destination agency is accepting calls, whether its queue has crossed a diversion threshold, whether a time-of-day or emergency policy redirects the call elsewhere.

With both answers in hand, the ESRP forwards the call. Depending on the deployment, it may hand off to a state-level ESRP, which repeats the pattern at finer granularity. The final ESRP delivers the call to the destination agency, along with the location information and any additional data available from an Additional Data Repository.

Lastly, the call rings and a telecommunicator answers. The whole sequence has taken a fraction of a second, and every step of it has been written to the i3 logging service.

Standards: What Governs How These Elements Behave

Interoperability across the NG911 ecosystem depends on every element implementing the same specifications the same way.

NENA i3 (NENA-STA-010) is the governing architecture. It defines each functional element, the interfaces between them, and the behavior each is expected to exhibit. INDIGITAL has built to i3 since before the standard was finalized, and continues to advance its platform toward the full realization of i3 functional requirements as the standard evolves.

IETF specifications supply the underlying protocols. SIP, maintained through the SIPCORE working group, carries the sessions. LoST defines the ECRF and LVF query interface. HELD governs location retrieval. Geolocation conveyance in SIP and the best-current-practice guidance for emergency calling round out the set. These are open, published specifications, which is what makes cross-provider interconnection possible at all.

ATIS J-STD-110, developed jointly by ATIS and TIA, specifies the architecture and requirements for native SMS text-to-911. It governs how text messages reach an emergency network and how they are delivered to an answering position. INDIGITAL’s Text Control API is built to this standard.

A word on how compliance claims should be read: i3 describes a large surface area, and vendors implement it at differing depths. During evaluation, ask which specific functional elements a provider implements natively, which it obtains from a third party, and which interfaces have been demonstrated in production against another provider’s equipment. Those three answers tell you more than a compliance checkbox.

Build Versus Buy: Why It Matters Who Writes the Code

Most NGCS providers assemble their offering. They license an ECRF from one vendor, an SBC from another, and integrate the pieces under a single contract. The arrangement works, and it carries a specific consequence: the provider’s ability to fix, extend, or adapt any given element is bounded by another company’s roadmap.

INDIGITAL develops its core NGCS functional elements in-house, including call routing, policy routing, boundary services, location functions, and the Text Control API. That ownership shows up in three places that matter to a 911 authority:

Response time on defects and requests. When a jurisdiction needs behavior changed, the engineers who wrote the code are INDIGITAL employees. There is no vendor escalation path and no waiting for someone else’s release cycle.

Interoperability. INDIGITAL has established more production-ready interconnections across NGCS providers than any other company in the market, moving calls and data across AT&T, Intrado, Motorola Solutions, and NGA networks without additional cost to counties or states. Building those interconnections requires the freedom to modify signaling behavior on both sides of a boundary.

Independent validation. Motorola Solutions, one of the largest NGCS providers in the country, uses INDIGITAL-built sub-elements inside its own NGCS offering, including BCF, ESRP, SBC, monitoring, and i3 logging components. A competitor’s decision to run your code in its own production emergency network is a form of technical due diligence that no marketing claim replaces.

INDIGITAL has built and run Next Generation Core Services since deploying the nation’s first ESInet in 2004, and today operates NG911 infrastructure serving more than 60 million people across 26 states. Every core functional element is developed in-house, to NENA i3 architecture, on open standards.

Explore INDIGITAL’s NGCS platform.

911 Is Our Calling.™

Frequently asked questions

What does NGCS stand for? NGCS stands for Next Generation Core Services. It refers to the collection of software functions that route, validate, and manage IP-based 911 calls and data in an NG911 network, including the Border Control Function (BCF), Emergency Services Routing Proxy (ESRP), Emergency Call Routing Function (ECRF), Location Validation Function (LVF), and Policy Routing Function (PRF).

What is the difference between NGCS and an ESInet? An ESInet is the managed IP network that transports 911 traffic, while NGCS is the set of software services that decide how that traffic is routed and secured. The ESInet provides connectivity; NGCS provides the routing intelligence, location validation, policy enforcement, and logging that operate across it. Most jurisdictions procure both under a single contract.

Who provides NGCS in my state? NGCS is provided by the entity holding your state or regional 911 authority’s core services contract, which varies by state and sometimes by region within a state. State 911 boards and authorities publish current provider information, and your 911 coordinator can confirm which provider serves your agency. INDIGITAL holds direct NGCS contracts in Indiana, Alabama, New Hampshire, Rhode Island, and Vermont, and provides NGCS and routing for Peninsula Fiber Network across Michigan.

What is the difference between an ECRF and an LVF? An ECRF determines where to route a live 911 call based on the caller’s location, while an LVF validates location records before any call occurs. Both use the same LoST protocol interface and the same underlying GIS data. The ECRF operates in real time during call processing; the LVF operates during address provisioning so errors are corrected in advance.

Is a Border Control Function the same as a firewall? A firewall is one component of a Border Control Function. The i3 BCF combines firewall capabilities with a session border controller, adding SIP-aware inspection, media handling, topology hiding, and protection against telephony denial-of-service attacks that a general-purpose firewall does not provide.

Does NG911 still use ALI? End-state NG911 replaces ALI with location delivered directly by the originating network, retrieved through protocols such as HELD and stored in a Location Database. Jurisdictions still carrying transitional traffic often maintain ALI in parallel during migration, retiring it as legacy gateways are removed.