Life Without a Signal: The Car That Stopped Calling for Help

A vehicle is built in one country and sold in another. Its emergency call system is wired to a cellular module, provisioned before the car left the line, configured for a network in a market the manufacturer doesn’t operate in. For four years it works. It reports, it registers, it passes every diagnostic that asks whether it is connected.

Then the carrier in that market retires a generation of network. Not overnight, announced years in advance, in documents nobody in the vehicle program was reading, because the vehicle program shipped in 2021 and moved on.

The module doesn’t error. It attaches to something. It reports as online. What it can no longer do is complete the one call it exists to make.

Nobody finds out until somebody needs it.

Global cellular connectivity for connected vehicles

This is the failure mode that makes mobility different from fleet telematics, and it’s worth being precise about why.

In logistics, the operator owns the vehicle. When a truck goes dark, the person who feels it is the person who can act on it. The feedback loop is short and unpleasant, which is a kind of gift.

In mobility, the party who chose the connectivity and the party experiencing the failure are separated by a supply chain, a dealership, a border, and often a decade. An OEM specifies a module and a connectivity profile during development, and the consequences land years later on a driver in a market the OEM’s connectivity team has never operated in. There is no short feedback loop. There is barely a loop at all.

Three structural properties follow, and none of them have anything to do with coverage.

The vehicle is a permanent roamer for its entire service life. Built in one market, sold in another, it never comes home to its network of origin. Every connection it makes for fifteen years is a roaming connection, governed by commercial agreements that are renegotiated, deprioritized, or retired without reference to the fleet of cars that depend on them.

The hardware is unreachable by design. A telematics control unit is behind trim, wired into the vehicle bus, expected to survive the warranty. There is no field visit to swap a SIM. Multiply by the production run, and the cost of any physical remedy exceeds the value of the feature it would fix.

Nothing in the stack is looking for silence. Automotive diagnostics answer “is the module attached.” They don’t answer “did this vehicle successfully do the thing it’s supposed to do, this month, in this market.” Those are different questions, and only the second one matters.

We see the shape of this at scale. One connected-vehicle safety deployment on our network involves hundreds of thousands of devices, with substantial populations operating simultaneously in three countries on different continents, manufactured in one, driven in the others. At that geometry, a single carrier relationship isn’t a cost decision. It’s a design flaw with a delivery date.

What it costs when you can’t reach the hardware

The costs here don’t sit in an IT budget, which is exactly why they’re underestimated.

Warranty and recall exposure. A connectivity feature that stops functioning across a production run is not a support problem. It’s a product problem, with the legal and reputational handling that, in the case of mandated safety systems, implies a regulatory one.

Feature obsolescence you can’t patch. Connected services are increasingly sold as part of the vehicle’s value and, in some markets, its subscription revenue. A vehicle that can’t reach the network can’t deliver either.

Homologation and launch delay. Every additional market means another carrier relationship, another set of certifications, another negotiation, sequentially, before you can sell. This is where connectivity stops being an engineering line item and becomes a go-to-market constraint.

Diagnostic cost per incident. When a dealer can’t reproduce a connectivity fault, the default remedy is replacing the module. That’s parts, labor, and a customer who now distrusts the feature.

The same failure, one tier down

The structure repeats in shared and micromobility, where the timescales are shorter, and the cost is easier to see, which makes it a useful place to watch the mechanism work.

Whizz rents and rent-to-owns e-bikes to independent delivery riders across New York, Philadelphia, Chicago, and Washington, DC. Most of their riders are gig contractors working for the large food and grocery delivery platforms. Same asymmetry as the OEM case: the company deploys the hardware, someone else is holding it when it fails, and that someone has no diagnostic tooling and no reason to file a useful report.

The published account of their starting position is unusually candid. Whizz began with ordinary SIM cards from a standard mobile operator, which pushed data costs into the thousands of dollars per month, with SIM identification numbers manually entered into their systems, one at a time. And then the sentence that belongs in every edition of this series: when a bike lost connection, resolving it was cumbersome and there was no clear process.

That isn’t a description of an outage. It’s a description of the absence of a method, and the absence of a method is what turns a recoverable fault into a recurring cost. For the rider, the arithmetic is brutal in a way it isn’t for a car owner: New York City’s own study of app-based delivery workers put net take-home pay near $11 an hour with tips, and closer to $4 without. A device that won’t respond at 5:40 a.m. costs a specific person most of a shift.

Different asset, different timescale, identical mechanism: hardware you can’t reach, a failure you learn about last, and no defined next step when it happens.

Why the traditional approach can’t fix this

A conventional operator SIM assumes a subscriber who can be contacted, billed, supported, and handed a replacement SIM. Every one of those assumptions fails when the subscriber is a vehicle that will outlive the contract.

Two capabilities close the gap, and both have to be decided before production, not after.

Provisioning that survives the supply chain and stays changeable afterwards. The connectivity profile has to be installable at the factory and modifiable over the air for the life of the asset, so that a carrier change, a network retirement, or a new market doesn’t require touching hardware. The Whizz deployment is a small, legible version of this: SIMs ship to the manufacturing facility, get installed during production and mapped to specific units, and the platform configures each one automatically the first time it comes online, with later changes pushed remotely. Scale that pattern to a vehicle program and it’s the difference between a software update and a recall.

Observability that answers “did it work,” not “is it attached.” Attachment is not function. The only useful signal is whether a given unit completed its expected behavior in its actual market and whether that changed. Silence has to be a detectable event rather than an absence nobody queried.

What the best mobility programs do differently

The programs that survive a network retirement without a recall conversation share four habits, and again, none of them start with a purchase order.

They track sunset roadmaps per market of sale, as a product input. Carrier network retirements are announced years ahead. The gap isn’t information; it’s ownership. Nobody in the vehicle program is assigned to read them, because the program shipped and the team moved on. The resilient ones assign it and review it at the same cadence as any other lifecycle risk.

They specify connectivity as an updatable subsystem at kickoff. Every other software-defined component in a modern vehicle is expected to change over the air. Connectivity often isn’t, purely by convention. Treating the connectivity profile like any other updatable ECU, a decision made at program start, is what makes every later problem solvable remotely.

They define “working” per market and measure it. Not attachment rate. Whether a given population completed its expected behavior in the market it’s actually driving in this month. That’s a different metric and usually a different dashboard, and it’s the only one that catches a silent degradation.

They instrument the field population, not the validation fleet. Test fleets sit in markets you operate in, on networks you chose. The failure lives where you don’t operate. Sampling the real population is uncomfortable, and it’s the only place the answer is.

The risk leadership consistently misses here is a category error: connectivity is budgeted as a per-unit cost, and it behaves like a product lifecycle dependency. A per-unit cost gets optimized down. A lifecycle dependency gets owned, reviewed, and planned for. The gap between those two treatments is where recalls come from.

The question to take to your team

Mobility’s version of the series question isn’t about silence, because your devices will report as online while failing.

For the markets we ship into: do we know which network generations are scheduled to retire, and could we move our installed base without touching a single vehicle?

If the answer to the second half is no, the answer to the first half doesn’t matter much. You’re not managing a risk. You’re waiting on one.