What needs to be in place for a successful rollout
For many OEM programs, NG-eCall readiness is still treated as a compliance topic. In reality, it is much more than that. It is a deployment challenge that spans the vehicle, the mobile network, IMS/VoLTE integration, the PSAP, and end-to-end validation. As the regulatory shift toward packet-switched eCall moves forward, OEMs need to think beyond approval and focus on whether the full emergency communication chain is truly ready for real rollout.
NG-eCall readiness is not just about passing requirements
That is the first mindset shift. A compliant subsystem does not automatically mean a deployment-ready system. NG-eCall depends on multiple domains working together, and much of the complexity sits at the interfaces between them. EENA’s NG-eCall guidance reflects this clearly: IMS-based eCall is the long-term direction, and introduction depends on the point where end-to-end testing can be performed, not simply where one isolated component looks ready.
This is why OEMs should stop thinking about NG-eCall as a feature and start treating it as a connected operational flow. The emergency call path begins in the vehicle, but it depends on network behavior, SIP signaling, IMS support, routing logic, and PSAP capability before it can work as intended in the field.
Why NG-eCall readiness is now urgent
The timing matters. EU Delegated Regulation 2024/1180 introduced the transition toward packet-switched specifications for in-vehicle systems. From 1 January 2026, national authorities must refuse new type approvals or approval extensions for vehicles and systems that do not comply with the amended rules. From 1 January 2027, certain vehicles approved after March 2018 that do not comply with the packet-switched specifications will no longer have valid certificates of conformity for registration and entry into service.
On the infrastructure side, EU Delegated Regulation 2024/1084 applies the updated PSAP provisions from 1 January 2026 for infrastructures already deployed, meaning the receiving side of the emergency call chain must also be ready for packet-switched eCall handling.
So this is not a future topic. It is already a live planning issue for OEMs, suppliers, and validation teams.
What NG-eCall readiness actually means in practice
1. Vehicle readiness
The in-vehicle system still has to do the fundamentals correctly. It must detect the event, trigger the emergency call flow, and send the Minimum Set of Data reliably. That sounds straightforward, but vehicle readiness is only the first layer. Even a well-implemented IVS can still run into issues when it moves into a real telecom environment.
2. Mobile network behavior
NG-eCall does not exist in a vacuum. It depends on how the mobile network behaves under real conditions. Coverage, operator behavior, service availability, and transition scenarios all matter. EENA notes that the IVS should only use IMS eCall when informed that the network supports it, and operators should only activate the indicator when NG-eCall coverage exists and at least one routable PSAP can receive it.
That is why rollout planning cannot stop at vehicle integration. Network readiness is part of NG-eCall readiness.
3. IMS / VoLTE integration
This is one of the most important technical layers. In NG-eCall, IMS becomes the communication backbone. EENA states that the SIP INVITE message should be used for initial MSD transport and that a dedicated URN subclass and system information indicator are part of the NG-eCall handling approach.
For OEMs, that means IMS and VoLTE cannot be treated as background telecom details. They directly affect whether emergency communication can be initiated, routed, and handled correctly.
4. PSAP readiness
The receiving side matters just as much as the sending side. Regulation 2024/1084 updates the PSAP framework to support packet-switched eCall handling, while EENA notes that PSAPs may require an MSD reader that can extract the encoded data from the SIP INVITE into a readable format for the call taker.
This is an important point for OEMs: success is not only about placing a call. It is about making sure the emergency services side can receive, interpret, and operationalize the communication correctly.
Why end-to-end validation is the real gate
If there is one takeaway OEM teams should keep in mind, it is this: NG-eCall readiness must be proven end to end.
That is not just a best practice. It is how the ecosystem is moving. EENA ties NG-eCall rollout to the point where end-to-end testing is possible, and commercial-network pilots such as the Deutsche Telekom / Qualcomm / Cetecom setup have been built specifically to verify the IVS, network components, and PSAP together. Those tests validate SIP-based MSD transfer, bi-directional audio, and additional continuity scenarios such as domain handover and CS fallback.
This is where many OEM programs can still underestimate the challenge. Lab readiness is important, but it is not the same as deployment readiness. The closer validation gets to the real communication chain, the more useful it becomes.
What industry testing is showing
The broader industry picture reinforces the same message. ETSI’s NG eCall Plugtests 2025 involved 229 test sessions, 45 participants, 29 IVS devices, 11 PSAPs, and 5 conformance test systems. Of the total planned test cases, 53% were executed, and 87% of executed tests were successful.
That is encouraging progress, but it also shows something important: interoperability work is still active and still necessary. NG-eCall is maturing, but it is not something OEMs should assume will just work once one part of the chain is implemented.
What OEMs should do differently?
The strongest OEM programs usually do five things earlier than others:
- Align vehicle and telecom teams early: NG-eCall sits between automotive and telecom. Treating it as only one side’s responsibility creates gaps later.
- Validate against real network behavior: It is not enough to validate only in a narrow lab environment. Real-world network conditions are part of deployment readiness.
- Treat IMS / VoLTE as core, not secondary: IMS emergency signaling is central to the architecture, not a background dependency.
- Think about PSAP compatibility early: The receiving side must be part of the readiness model, not an afterthought.
- Prove the full chain before rollout: Certification is one milestone. Deployment readiness is what determines real-world performance.
Where Horizon Connect fits
At Horizon Connect, we see NG-eCall as a system integration and validation challenge, not just a standards topic. OEMs need to bring together vehicle readiness, telecom integration, end-to-end validation, and deployment preparation across markets. That is where cross-domain expertise becomes valuable: not only in understanding the specifications, but in helping ensure the full chain is ready to perform when it matters.
Final thought
The industry conversation around NG-eCall is changing. The real challenge is no longer whether one component can pass a requirement. The real challenge is whether the full emergency communication chain is ready for deployment.
That is what NG-eCall readiness really means.
