Connectivity architecture
Multi-network isn't a resilience feature in Africa — it's the price of entry
Every multi-IMSI SIM vendor sells “resilience.” In African conditions the word does a lot of hiding. Here's what multi-network actually protects against, what it doesn't, and the four questions that separate a real architecture from a marketing claim.
The claim everyone makes
Every connectivity vendor selling into African IoT says the same word: resilient. Multiple networks, automatic failover, always connected. It's true often enough to sell, and vague enough to hide the parts that matter. In markets where a single-operator SIM drops at every border and coverage shifts week to week, multiple networks on one SIM isn't a premium feature you pay extra for — it's the baseline you need before the deployment works at all. The interesting question isn't whether a vendor has multi-network. It's how it's built underneath.
The question underneath the marketing
Two SIMs can both be "multi-IMSI" and behave completely differently when a network fails, because the architecture underneath is different.
The common pattern: several network profiles on one SIM, all of them routing back to a single core somewhere far away — often a European one. It looks like resilience on the datasheet. But every profile depends on the same distant core, so the failure modes concentrate: one core event, and every profile behind it is affected at once. The redundancy is at the radio layer, not the core layer.
The architecture we run is different by design: each network profile has its own core, and those cores are distributed by region rather than pooled in one place — with geographic redundancy on the cores that carry the most traffic. The point isn't "more profiles." It's that a profile and its core are a matched pair, so a problem in one region's core doesn't darken the profiles anchored elsewhere. That's the difference between redundancy you can put on a slide and redundancy that holds when a network has a bad day. It is the same principle behind the Cloud Connect SIM.
What "failover" actually means — and its one honest limit
When a device loses its primary network, the switch to an alternate profile is handled on the SIM itself. It's autonomous: no support ticket to us, no human in the loop for the switch. The SIM holds a prioritised list of networks, scans for the best available one, and moves. Under normal conditions a first attach on the alternate can complete in tens of seconds.
The honest limit — the one worth stating plainly, because a vendor who hides it is the one to worry about — is this: autonomous failover only helps if there is a reachable alternate. If a network event takes down more than one profile at once, or an upstream operator withdraws a routing, the SIM has nowhere to switch to, and that's no longer a SIM problem — it's an escalation to the underlying network and the MNO. Under adverse conditions a full profile switch can also take minutes rather than seconds. Any operator telling you failover is instant and unconditional is selling you the datasheet, not the network.
Where the traffic breaks out
The other half of a real multi-network architecture is where the data actually exits. The design principle we run to is in-region breakout: data exits at a local packet gateway near the device, not backhauled across the continent to a European point of presence. In-region breakout is what gives you lower latency and keeps traffic compliant with data-sovereignty rules in markets that have them. It holds today across several regions. Africa is the region where in-region breakout is still being built out — the South African in-region gateway is the specific piece of work on the critical path — so the honest position is "design principle, delivered region by region," not "everywhere, today."
Reach and resilience are the same problem
Picture a single run: a truck leaving South Africa, crossing into Zimbabwe at Beitbridge, and heading north toward the Copperbelt. On one SIM, the device moves from one local network to the next as coverage and agreements change — and where the primary profile runs out of a viable local network, an alternate profile takes over. Same corridor, several networks, one SIM, and the operations team isn't fielding a ticket at each border. That's the whole point: in Africa, reach — staying attached across the route — and resilience — surviving a network that fails — are not two features. They're the same problem, solved by the same architecture.
Four questions worth demanding an answer to
If your current SIM provider can't answer these on a call, that's the answer.
- Which layers are you actually redundant at? Radio, roaming, core — or all three?
- Where does the core sit? One distant core with many profiles pointing at it, or a core per profile with geographic redundancy?
- What triggers the failover? An autonomous SIM-side switch, or a support ticket to your provider?
- Where does the traffic break out? In-region, near the device — or backhauled across the continent to a European gateway?
If you want to see the signalling behind an individual device rather than take any of this on trust, that's what the portal is for: see the network events behind each device.
The point
Multi-network in Africa isn't the feature that makes a deployment special. It's the floor a deployment stands on. The vendors worth your time are the ones who can show you the architecture underneath the word — and who tell you where the limits are before you find them yourself.
Worth reading alongside this: how SGP.32 fits alongside multi-IMSI, which covers the profile-lifecycle layer this article deliberately leaves out.
Talk to our engineers about your corridors
Tell us the routes your devices actually run and we'll walk through where the networks change, where the failover points are, and what the architecture underneath has to do to keep up.