EENA's 2026 conference coverage from Riga captures the moment Europe is in right now. NG112 is no longer only a standards diagram or a vendor roadmap. It is becoming the working language for how emergency services think about IP networks, caller location, multimedia, accessibility, and operational trust.
The key shift is simple to describe and hard to implement: emergency communications are moving from a voice-call system with some supporting data into an emergency-data system that still carries voice when voice is the right channel.
That distinction matters. Legacy 112 operations were built around the call. NG112 is built around the emergency session. A session may include voice, real-time text, video, precise location, caller profile information, vehicle data, app data, routing policy, and audit records. The PSAP still needs calm human judgment, but the network can carry far more context than it used to.
ESInet as the operating backbone
EENA's NG112 framing puts the Emergency Services IP Network, or ESInet, at the centre of the model. An ESInet is not merely a faster pipe. It is the emergency services network layer that can support IP-based routing and richer information exchange between originating networks, emergency service functions, and PSAPs.
In practical terms, an ESInet can help emergency services move away from brittle assumptions such as:
- A caller's number reliably identifies the right emergency jurisdiction.
- Voice is the only modality that needs first-class support.
- Location is handled separately from routing.
- Accessibility can be served through parallel systems rather than integrated emergency workflows.
- Cross-border or roaming cases are rare enough to treat as exceptions.
Those assumptions no longer fit the communications environment citizens actually use.
Why location becomes a routing discipline
Location quality is where NG112 becomes real. A modern emergency call may originate from a smartphone, a fixed line, a cloud phone client, a Wi-Fi connected enterprise endpoint, a vehicle, or a VoIP service. Each source has different location evidence and different failure modes.
For mobile calls, handset-derived location such as Advanced Mobile Location can dramatically improve the information available to the PSAP. For enterprise and VoIP calls, the challenge is often civic or dispatchable location: which building, floor, room, subnet, access point, or port should be associated with the caller? For vehicle calls, location may come with incident-specific data generated by the vehicle.
NG112 raises the bar because location is not only displayed to a call taker. It can influence routing. That means bad location can become bad routing.
The most useful programs therefore treat location as operational data with lifecycle management:
- Who owns the record?
- How often is it validated?
- What system is authoritative?
- How are moves, Wi-Fi changes, subnet changes, and new sites handled?
- What happens when the location is missing, ambiguous, stale, or inconsistent?
- Can routing decisions be reconstructed after an incident?
Those questions are just as relevant to an enterprise Teams deployment as they are to a national ESInet. The scale is different. The failure mode is familiar.
Modern phone systems are part of the same emergency chain
One mistake in NG112 discussions is treating enterprise phone systems as a side topic. They are not. A modern emergency calling environment includes cloud PBX, Microsoft Teams, SIP trunks, session border controllers, mobile devices, softphones, and provider-managed routing services.
When a user dials an emergency number from a workplace phone system, the call may cross several administrative boundaries before it reaches a PSAP or emergency service route. If the phone system does not know where the user is, or if the provider cannot use that location correctly, the emergency chain is weakened.
A mature enterprise program should therefore manage emergency calling as a service lifecycle rather than a one-time configuration:
- Maintain location records for offices, floors, shared workspaces, remote sites, and network zones.
- Test emergency routing after network changes and site moves.
- Include Wi-Fi access points, switches, subnets, and civic addresses in location design where supported.
- Document fallback behavior when dynamic location is unavailable.
- Train IT operations teams to treat emergency calling defects as safety incidents, not ordinary tickets.
- Coordinate with carriers and VoIP providers before changing numbering, trunks, SBC policy, or routing.
This is where European NG112 and US-style enterprise E911 thinking overlap. The legal frameworks differ, but both worlds are converging on the same engineering truth: emergency calling quality depends on location data quality.
Wireless carriers and the 4G/5G transition
Mobile operators are also moving through a complicated transition. 2G and 3G networks are being retired in many markets, while emergency calling increasingly relies on 4G and 5G voice services. That shift should improve capability over time, but the transition can create gaps if emergency services, roaming, handset compatibility, IMS configuration, and eCall are not handled carefully.
This matters for NG112 because the future emergency service network can be IP-native only if the access networks are dependable. A sophisticated ESInet cannot compensate for a caller who cannot place an emergency call while roaming or a vehicle whose eCall module depends on a retired network layer.
Wireless migration plans should include emergency-specific evidence:
- VoLTE and VoNR emergency call success across device classes.
- Roaming emergency call behavior for visitors.
- Location delivery performance under 4G and 5G emergency conditions.
- eCall continuity during 2G and 3G retirement.
- PSAP notification and testing before network changes.
- Fallback rules when IMS emergency calling is unavailable.
Public safety cannot be an afterthought in spectrum and network modernization.
What PSAP leaders should take from Riga
The most useful operational takeaway from the 2026 NG112 conversation is that PSAP modernisation has to include people, process, and data governance. Technology expands what is possible, but it also expands what call takers and dispatch systems may need to interpret.
A PSAP receiving richer emergency data needs clear rules:
- Which data is trusted enough to influence dispatch?
- Which data is displayed immediately and which is available on demand?
- How are conflicting locations handled?
- How is multimedia reviewed without slowing the call taker?
- What is retained, for how long, and under which legal basis?
- How are privacy obligations explained to the public?
NG112 is not a reason to flood call takers with every possible signal. It is a reason to design information flows carefully so responders get the right context at the right time.
Editorial perspective
The promise of NG112 is not that emergency services become more digital for the sake of it. The promise is that the emergency chain becomes less blind. Better location, better routing, richer accessibility, and more resilient networks can help PSAPs understand the incident faster and route help more accurately.
The risk is that Europe builds technically advanced systems that are hard to operate, hard to test, or unevenly deployed across borders. That is why the conversation coming out of Riga is useful: it is not just about the destination. It is about the practical work required to get there.
NG112 is becoming the shared architecture for that work. The next question for every country, provider, enterprise, and vendor is whether their part of the chain can prove it is ready.