Connected vehicles: which functions need a resilient mobile connection?

When a fleet operator selects telematics connectivity, or a vehicle manufacturer specifies an emergency-call unit, the same connection may support services with very different needs. A stored position report can still be useful if it arrives 10 minutes late. An emergency call needs a connection when the incident occurs. The starting point is therefore the service: what happens when connectivity is lost, how long can it wait, and how quickly must it recover?

The immediate operation of on-board driving functions does not depend on a live mobile connection. Connected services have different requirements: routine reports can often wait, while alerts, remote assistance and emergency calls need connectivity within a defined response window.

Multi-network connectivity gives a vehicle access to alternative radio networks along its route. Where a service also needs protection against an operator-core outage, an independent core provides an alternative path, with detection, switching and reconnection times determining how quickly service can resume.

The five examples below show how the impact of losing connectivity determines the resilience each function or service needs.

The table is adapted from Table 3 and Figure 6 of CSL’s white paper The Future of Telematics: The Roles of AI and ML in ADAS, EVs and AVs, Article 4, second edition. As an end-to-end service, next-generation eCall requires support from the in-vehicle system, the mobile network and the emergency service that answers the call.

The on-board functions in the table’s first row use the vehicle’s own sensors and computers, so their immediate operation does not depend on mobile coverage. Connectivity supports the wider lifecycle of those systems, including data uploads and software or model updates. These transfers can be scheduled for suitable connectivity windows, such as when a vehicle is charging at a depot.

A telematics unit can report position and status every few seconds or minutes. Where its specification requires buffering, it stores what it cannot send until the connection returns. Where the delay is not service-affecting, a routine report may be able to wait for the core service to return as well. A scheduled software update can wait hours for its delivery window, under the software update management system that UN Regulation No. 156 requires the vehicle manufacturer to operate.

How long a stored report waits can depend on the coverage available along the vehicle’s route. Ofcom models in-vehicle coverage by applying a 10 dB reduction to the outdoor signal. On that basis, in July 2025, each UK mobile operator provided predicted 4G coverage across 90 to 93 per cent of motorways and A roads. This means that, depending on the operator, the predicted signal fell below Ofcom’s threshold across 7 to 10 per cent of motorway and A-road length, and 17 to 19 per cent of B-road length. A multi-network SIM can improve availability by allowing the vehicle to use another operator where that operator has suitable coverage.

Find out more: Ofcom, Connected Nations UK report 2025

An alert sent from the vehicle to a fleet platform may remain useful after a short interruption, but its value depends on arriving in time for the required response. Security updates have a different delivery window, determined by the vulnerability and the manufacturer’s mitigation process. UN Regulation No. 155 requires manufacturers to demonstrate that cyber threats and vulnerabilities needing a response are mitigated within a reasonable timeframe, rather than setting a single deadline for every update.

Access to multiple radio networks helps a vehicle stay connected as coverage changes along its route. An independent mobile core adds resilience against an outage affecting the active profile’s core. For time-sensitive alerts, the key requirement is whether failure detection, switching and reconnection can restore delivery within the required response window.

Find out more: UN Regulation No. 155, cyber security and cyber security management system

A self-driving service that uses remote assistance asks a person in an operations centre for advice, while the vehicle’s driving system remains responsible for controlling the vehicle. Its response window therefore needs to account for both communications delays and the time needed to assess the request and provide advice. This differs from remote driving, which involves remote control. The remote-driving requirements in 3GPP TS 22.186 include a maximum end-to-end latency of 5 ms, 99.999 per cent reliability and a 25 Mbit/s uplink. These figures should not be treated as the requirements for remote assistance.

Remote assistance needs a response within the service’s defined operating window. That requires resilient connectivity at both the vehicle and the operations centre, together with a clear fallback if communications are unavailable or a reply arrives too late. The Department for Transport’s pilot-scheme guidance for self-driving vehicles asks service operators using remote assistance for validated response plans detailing communications performance and fallback protocols.

Find out more: Department for Transport, Self-driving vehicle pilot scheme: information for applicants

Next-generation eCall opens a voice call to the emergency services over 4G or 5G, and the call includes the vehicle’s data. From 1 January 2027, vehicles approved under the EU eCall regulation after 31 March 2018 will need to meet the next-generation eCall specifications for their certificates of conformity to remain valid. The call follows the serving mobile network’s emergency route, separate from the private route that carries the vehicle’s data to its platform.

An independent core can provide an alternative registration path when the active profile’s core is unavailable. For next-generation eCall, the complete configuration needs validation across the in-vehicle system, the profiles and the networks intended to support the emergency call. Testing should establish how long the unit takes to detect a failure, switch profile, register and successfully place the call.

UK deployment also depends on emergency-service infrastructure readiness. The Department for Transport’s guidance states that next-generation eCall may not operate and should not be relied upon in an emergency before 31 March 2027, while supporting UK telecoms infrastructure is upgraded.

Find out more: Commission Delegated Regulation (EU) 2024/1180, amending the EU eCall regulation

A mobile operator runs a radio network, comprising the masts and spectrum the vehicle connects to, and a core network behind it. The core authenticates each SIM, assigns it an address, routes its traffic and connects its calls. Where one radio network has no signal, a multi-network SIM with a roaming profile can attach to another available radio network. However, the profile’s registration still depends on its issuing mobile operator’s core, and that core dependency is not shown on coverage maps.

The CSL Critical Connectivity® Failure Atlas, CSL’s research database, analyses 45 major infrastructure failures from 2018 to 2026. Among them, shared core or core-routing dependencies contributed to national outages in Canada and Japan in 2022 and in Australia in 2023. In Canada, after a routing filter was deleted during a core network update, more than 12 million customers lost wireless or wireline service, with disruption to 911 access. In Japan, the regulator recorded 61 hours 25 minutes of material impact after a routing misconfiguration during maintenance on one core router.

Resilience against a core failure requires the second profile to use an independent mobile operator core. Access to another radio network improves radio availability, but it does not provide core resilience where both paths still depend on the same underlying core.

Related reading: The Physics of Critical Connectivity Failure

Before selecting a telematics unit and its connectivity services, establish four requirements:

• What needs a connection? Separate on-board decisions from services that exchange data, request assistance or place emergency calls.
• How long can each service wait? Define delivery deadlines, response windows and what the vehicle does if communications are unavailable.
• What resilience does it need? Match access to multiple radio networks and independent cores to the service’s requirements, then test coverage, latency and reconnection on the vehicle’s routes.
• How will recovery be demonstrated? Test a controlled failure of the primary core path, recording failure detection, switching, registration and service-restoration times. Confirm private routing for the relevant data services on both paths, and validate emergency calling separately through the mobile network’s emergency route.

With these points established, the connectivity can be designed around the needs of each service.

CSL brings connectivity, provisioning, private routing, connection monitoring and support together as a managed service. Where required, this can also include the equipment needed for the deployment. CSL IoTM Platform manages SIM subscriptions and eSIM profiles from multiple mobile operators across fleets and borders, helping each vehicle service use the connectivity designed for it.

For tracking, reporting and alerts, CSL’s multi-network IoT SIMs give vehicles access to alternative radio networks as they move between coverage areas. Where a service also requires resilience against an operator-core outage, CSL DualCore® architecture provides two paths through independent operator cores. Switching decisions are made locally on the SIM, so a switch does not depend on an instruction reaching the device over the affected connection. Both paths can use private encrypted routing for data services. Where emergency calling is supported by the device and service, calls are handled separately through the emergency-calling capabilities of the serving mobile network.

For compatible telematics units, emergency-call units and fixed equipment, rSIM® technology provides these independent paths on one SIM or eSIM, combining two multi-network roaming profiles with on-SIM switching logic. Logic on the SIM tests the active path at configurable intervals and switches profile after a set period of failure. Because the switching decision is made on the SIM, the device does not need a second SIM slot or device-level profile-switching logic. This can reduce the bill of materials and simplify development and integration compared with a dual-SIM design. Both profiles support voice over LTE. For next-generation eCall applications, CSL also validates emergency-call support across the intended device, profile and network configuration, including call establishment after a profile switch. Each device type is validated before rollout, covering the SIM form factor, modem behaviour and routing configuration.

The same approach extends to the infrastructure supporting connected vehicles. At depots, roadside cabinets and operations centres, a CSL DualSIM® Router configured for core independence provides alternative core paths for connected equipment. This allows connectivity resilience to be addressed at both ends of the service.

Find out more: rSIM technology

Related reading: Vehicle Telematics and Core Resilience | CSL Group

CSL provides managed connectivity for critical IoT and safety applications, supporting more than 3.5 million active direct connections. Our specialists can help define the coverage, recovery and core-resilience requirements of your connected fleet or automated service.