What Is an ESInet? Architecture, Standards, and How It Works

The limits of the selective router were obvious, yet it stayed in place in 911 for decades… until March 31, 1998. That’s when a wireless 911 call originating in Allen County, Indiana, reached a dispatch center with the caller’s location displayed on the receiving device. It was the first call of its kind in the U.S., according to the National Emergency Number Association (NENA). 

That first-of-its-kind call was placed over INDIGITAL’s network.

Six years later, the Indiana Wireless 9-1-1 Advisory Board asked INDIGITAL to build a statewide network on that premise, funded by wireless surcharges rather than tax dollars. The IN911 Network became the first large-scale, high-speed, IP-based public safety network in the country. Eventually, it was given a name: the Emergency Services IP Network, or ESInet.

Two decades later, that architecture carries emergency traffic for tens of millions of Americans. 

Here is how it works.

What an ESInet Is

An ESInet is a managed IP network built for one purpose: moving emergency communications between the carriers that originate 911 traffic and the emergency communications centers (ECCs, long known as PSAPs) that answer it. It carries voice, text, location, and data across a private, monitored, redundant path with service held to a strict standard, because a dropped packet here can cost someone their life.

The word managed is important to note here. An ESInet is not the public internet with a security certificate attached. Rather, it is engineered with defined ingress points, continuous monitoring, and geographic redundancy, operated by a provider who is accountable for every second of uptime.

An ESInet is also only half the story. The network moves the traffic, but a separate piece of software, called Next Generation Core Services (NGCS), routes that traffic. In this way, you can think of the ESInet as the road and NGCS as the traffic control system reading conditions and directing each car. People often talk about the two as one thing, and many contracts often bundle them together, but they’re doing two different jobs.

Why the Selective Router Gave Way

Legacy 911 was built on a simple assumption: a telephone number corresponded to a fixed street address, and that address corresponded to one dispatch center. The Master Street Address Guide (MSAG) encoded those relationships, and the selective router executed them.

Three forces made that one-number-one-address-one-center model obsolete:

Mobility. By the early 2000s, the whole premise of the routing table was eroding. Cell phones were no longer a convenience. For a growing share of callers, they were the only phones they had. A person calling 911 might be doing it from a car on the interstate, a mile past the county line, moving at highway speed while the call was still being routed. The selective router had one tool for this problem: a fixed pairing between a circuit and a dispatch center, set at installation and unchanged since. It could not determine where a caller was, only which wire the call had arrived on. And a growing number of calls no longer arrived on a wire at all.

Ownership. Selective routers were generally operated by the incumbent telephone company serving the county seat, a regulatory obligation that came with the territory. That carrier chose the vendor, and the agency inherited whatever feature set had been purchased, whether or not it still matched the county’s needs. When a dispatch center needed something changed (a new agency added to the routing table or a redrawn boundary), there was no path to make that change themselves. They filed a request with the carrier and waited on someone else’s schedule, for a system they depended on every hour of every day but did not control.

Format. A circuit-switched router was built to do one thing: carry a voice call over a dedicated line. It had no way to represent a text message, a photo from a crash scene, a telematics ping from a car’s airbag sensor, or a signal from a connected medical device. These were not features the router did poorly. They were data types that did not fit its design at all. As the ways people needed to reach 911 multiplied, the router’s single, fixed format limited what the network could deliver.

The ESInet resolved all three of these growing problems at the architectural level. IP transport can carry any payload, from voice to text to data. And because it runs on open, standards-based interfaces, no single vendor’s roadmap decides what a jurisdiction can do next. Further, the NENA i3 standard introduced a Policy Routing Function (PRF) that puts routing rules behind a secure API the jurisdiction itself can operate, opening a system that had been sealed since the 1970s.

How an ESInet Works, From Origination to Delivery

1. Origination. A carrier hands the emergency call off to the ESInet as SIP traffic, along with whatever location information the device and network can supply.

2. Border Control Function (BCF). The call enters at the network edge, where the BCF performs security screening, admission control, and protocol normalization. This is the perimeter, and it absorbs the things that should never reach the routing core.

3. Emergency Services Routing Proxy (ESRP). The ESRP is the decision point. It receives the call and queries the services that determine its destination.

4. Emergency Call Routing Function (ECRF). If it is a wireless call, the ECRF compares the caller’s coordinates against GIS boundary layers and returns the address of the correct ECC. If it is a call from a fixed device where the location is sent as an address, the ECRF must first convert that into coordinates. Routing is geospatial, resolved against real jurisdictional polygons at the moment of the call.

5. Policy Routing Function (PRF). Before delivery, the jurisdiction’s own rules apply: time-of-day routing, overflow when every position is occupied, alternate routing during an outage, diversion during a declared event.

6. Delivery. The call arrives at the ECC’s call handling equipment. Location can continue to be refined mid-call. Every step is written to an i3 logging service, producing a complete, timestamped record.

7. Legacy interworking. Centers that have not yet cut over to i3 call handling receive traffic through legacy gateways, which translate between the ESInet and older equipment so a county can modernize on its own schedule.

The whole sequence resolves in well under a second.

The NENA i3 Standard, and What Compliance Actually Means

NENA’s i3 standard defines the functional elements, interfaces, and call flows of NG911. It is the blueprint the industry agreed to build toward, and geospatial routing is at the center. In practice, NG911 deployments fall into three broad categories, and the distance between them is significant:

Fully i3-aligned NGCS implements the standard’s functional elements and routes calls geospatially, with the interfaces necessary to interoperate across providers and support text, data, and future media types.

Transitional deployments use interim IP protocols, most commonly ATIS RFAI, developed as a bridge while i3 was being finalized. They move traffic over IP and represent real progress, though they do not deliver the full i3 feature set.

IP selective routing (IPSR) modernizes the transport while preserving legacy behavior. Calls are still matched against a routing database rather than against the caller’s live location. 

For anyone evaluating a proposal, the useful questions include: Which i3 functional elements are actually deployed and in production? Are calls routed against live geospatial data today, or against a static database? Which interfaces are open, and what does interconnection with a neighboring provider require?

INDIGITAL’s position on this is straightforward. We built to the emerging i3 architecture while NENA was still defining it, and those early deployments shaped how statewide ESInet design evolved. Each subsequent deployment advances further toward the full realization of i3 requirements.

ESInet Deployment Models

An ESInet can be deployed under several different technical and operating models, and no single model is inherently the right choice for every 911 authority. Networks may be dedicated or shared, hosted on premises or in the cloud, and owned outright or delivered as a managed service. What matters is whether the resulting architecture provides the resilience, geodiversity, interoperability, operational support, and portability that NG911 requires. National 911 Program guidance similarly emphasizes shared infrastructure, redundancy, interconnection, and testing as central considerations in ESInet planning rather than treating deployment location or ownership structure as ends in themselves.

Dedicated vs. shared. A dedicated ESInet serves a single authority. A shared ESInet aggregates multiple jurisdictions onto common infrastructure, distributing cost and operational burden across participants. Most statewide networks are shared by design.

On-premises vs. cloud. Core services can run in provider-operated data centers, in commercial cloud, or in a hybrid arrangement. The relevant question is less about where the servers sit than about how failure is handled: geographic separation between instances, independent power and transport, and demonstrated failover.

Managed service vs. owned infrastructure. Some authorities contract for a fully managed service; others own the infrastructure and contract separately for operations and support. Ownership provides greater control but requires more internal technical and operational capacity. A managed service shifts much of the day-to-day operational responsibility to the provider, making the provider’s staffing, expertise, resilience, and support capabilities critical.

The following questions apply regardless of the deployment model:

• Is transport diversity physically real? Do redundant connections follow genuinely separate routes and avoid common points of failure?
• How is the network monitored and supported? Who staffs the network operations center, what coverage is provided outside normal business hours, and what is the escalation process for a critical outage?
• How does the ESInet interconnect with other networks? What technical and operational requirements apply when connecting to an adjacent ESInet, and has that interoperability been tested under production conditions?
• What happens if the authority changes providers? Which data, configurations, interfaces, network assets, and other components can be transferred, and what assistance is the incumbent provider required to provide during the transition?

What Twenty Years of Operating an ESInet Teaches You

INDIGITAL deployed one of the nation’s first statewide ESInets in Indiana in 2004, building to the emerging NENA i3 architecture while the standard was still being defined, and has operated it continuously since. Today, our networks serve more than 60 million people across 26 states and 200-plus jurisdictions, at county, regional, and statewide scale.

That experience has enabled a specific set of capabilities:

In-house development. INDIGITAL builds its core NGCS functional elements internally, including call routing, policy routing, boundary services, ALI and HELD location functions, and the Text Control API. Independence from third-party roadmaps means faster iteration and direct control over standards alignment. Motorola Solutions runs INDIGITAL-built NGCS sub-elements inside its own offering.

Interoperability in production. INDIGITAL maintains more production-ready interconnections with other NGCS providers than any competitor, using open interfaces at no added cost to the jurisdiction. Calls cross network and provider boundaries because the connections were built and tested before anyone needed them.

Resilience as architecture. Transport diversity across fiber, LTE, and Starlink; geographic redundancy; and demonstrated cross-network failover, including a documented 2024 rerouting test between two ESInets in South Carolina and Florida. In June 2026, Frost & Sullivan recognized INDIGITAL with its 2026 U.S. Product Leadership Award for Disaster Recovery Solutions, the only company named in that category.

People in the state. Market managers and field coordinators embedded where they serve, many with prior dispatch experience, and a live person on the phone at any hour.

Every jurisdiction reaches the NG911 transition from a different starting point. If you are evaluating what end-state architecture would look like for yours, INDIGITAL has done this in 26 states at every scale.

911 Is Our Calling™

Learn more about our next-generation core services and start your journey today.