The Software-Defined Vehicle Needs a Software-Defined Network: 5 Ways Stacuity Supports Automotive Connectivity

Connected vehicles have outgrown the networks that serve them. The software-defined vehicle needs automotive connectivity that can adapt to new regulations, new markets, and new services long after the car has left the factory. Yet much of the connectivity serving vehicles today was designed for a different era, built on lengthy hardware deployments and one-size-fits-all data paths.

At Stacuity, we work as an enablement layer for the MNOs, MVNOs, and managed connectivity service providers who serve automotive OEMs. Our software-defined core network and edge platform equip those providers to solve the challenges OEMs face every day, from data sovereignty and deployment speed to scale, control, and the cost of change.

Data sovereignty has moved from a nice-to-have to non-negotiable. Brazil requires vehicle traffic to stay in-country. India goes further still, with strict licensing and lawful interception requirements. And the list of territories with tight regulatory criteria is growing every year.

The traditional roaming model breaks here. A car in Australia connecting through a European or Asian operator sends its data halfway around the world and back, a loop known as tromboning that adds hundreds of milliseconds of latency and, in tightly regulated markets, puts the OEM on the wrong side of local rules.

Our edge sites solve this. The vehicle connects to local networks exactly as before, but the data session terminates at our in-country packet gateway. Data stays in Brazil, or Australia, or wherever regulation demands, while the connectivity provider retains central control. And where some traffic still needs to reach a central location, telematics data returning to Germany, for example, we route it onwards efficiently.

In automotive, time to market decides who wins. There are many things that impact time to market from an SDV perspective, vehicle safety, compliance, all of that. Our view is: why would we make connectivity any harder?

Because our network is genuinely software-defined, there is no hardware to procure, configure, and roll out on a long project plan. We can stand up a new location in around six weeks. We deployed Brazil, widely considered one of the most difficult markets, in ten.

The most striking example came recently, when a partner asked to trial our edge solution for half a million subscribers. Setting up a distributed network test would normally take six to nine months. Because we already had an edge site where they needed it, setup took four minutes. The full solution went live four and a half weeks later, including integration with their own charging and policy systems. With traditional infrastructure, that is a nine-to-twelve-month project.

Five years ago a connected car mostly streamed music. Today, firmware and software updates over the air, ADAS, and emerging in-vehicle AI produce very different traffic profiles across generations of vehicle, sometimes within the same fleet.

Our platform is elastic in the way the public cloud is elastic. It scales up for the peaks, an overnight software update campaign across a national fleet, and scales back down when demand drops, so providers and OEMs pay for what they use. That matters as much commercially as technically. Connectivity economics only work at automotive scale if the network can breathe with the demand.

In automotive, control over what the connectivity does and where it goes is critical. Most solutions today require a vehicle to connect on three or more separate APNs to separate infotainment, telematics, and other services.

With Stacuity, a single APN can do the work of several. Traffic is identified by type and routed, blocked, or redirected according to rules the connectivity provider configures through our platform using API-driven self-service provisioning. Local DNS, network preferences, and routing policies are all in the provider’s hands, without needing a specialist in a back room to make every change. This programmability is built into the foundations of our network through VSlice, which supports customised network behaviour per region, per vehicle line, and per use case.

Ask any OEM why they stay with an underperforming connectivity solution and the answer is usually the same, the cost of change is higher than the cost of staying. Vehicles live for ten to fifteen years, SIMs are soldered in, and legacy fleets cannot simply be migrated.

We address that problem from both ends. Our edge solution can be retrofitted to vehicles already in the field by repointing the APN, with no SIM swap and no change to the car itself. OEMs suffering latency or compliance problems today can fix them in the existing fleet. And for the longer term, we work with excellent partners in the SGP.32 eSIM ecosystem. This is the new standard that lets OEMs move between operators without the incumbent’s agreement, so connectivity contracts no longer have to be shackled to the full life of the vehicle.

The software-defined vehicle demands a software-defined network. As AI moves into the vehicle and to the edge, and as regulation tightens across more territories, the connectivity layer has to evolve as quickly as the car does. That is the standard we hold ourselves to: flexibility with simplicity, built on a foundation that stays safe, stable, and reliable.