Physical AI, eSIM, and connectivity strategy for African IoT operators

What this page is for

Physical AI (AI systems that sense, decide, and actuate in the physical world) is running ahead of the connectivity layer underneath it. For African IoT operators, that gap is a strategic problem, not a future one. This is CommsCloud's structural view of the intersection: what Physical AI means for African deployments, why eSIM and the SGP.32 standards matter, and where African connectivity forces different design choices than a European or North American operator would make. Written for OEM product leads, IoT solution providers, and enterprise buyers whose Physical AI roadmap depends on connectivity behaving predictably across the corridors they run.

What Physical AI is, and why African IoT operators should care

Physical AI is the label the industry is settling on for systems where AI sits inside a machine that acts, not behind a browser. The machine may be a tractor guidance system, an underground mining vehicle, a cold-chain reefer, a driver-behaviour dashcam, an insulin pump, or a substation health monitor. The AI runs at the edge for real-time reaction and in the cloud for training and fleet-wide learning: the whole loop depends on the connectivity between the two.

As Kigen's Loic Bonvarlet writes on Wevolver in his June 2026 piece "How Physical AI Is Redefining Mobile and Why eSIM Matters", Physical AI needs a mobile network that behaves differently from the one built for phones. His frame is correct and worth engaging with. What the piece doesn't cover (because it isn't its job to) is what Physical AI looks like when the deployment is in Malawi, or across Beitbridge, or in the Copperbelt. That's the African operator's job, and that's what this page does.

The African use cases are already commercial. Precision agriculture across the Free State and southern Zambia depends on autonomous or semi-autonomous machinery streaming telemetry to fleet platforms. Cold-chain logistics on the Durban–Lusaka–Lubumbashi–Nairobi–Mombasa corridor uses temperature, GPS, and door-state data with AI models that flag anomalies before spoilage. Fleet and driver-behaviour analytics run edge-side inference and cloud-side model refinement. Connected medical devices are moving into rural clinics with AI-assisted diagnostics. Grid monitoring is being retrofitted onto ageing substations across the SADC region. Every one of these deployments is Physical AI in production today, and every one lives or dies on the connectivity layer underneath.

The strategic point for the African IoT operator: Physical AI raises the stakes on connectivity. A dashboard-based deployment tolerates intermittence by buffering data; a Physical AI deployment cannot, because the decision loop lives in real time. What was a "let's improve visibility" problem is now a "the AI cannot act if the connectivity is down" problem. That reframing is the reason this page exists.

The always-on connectivity requirement

Intermittent connectivity used to be a visibility issue. In a Physical AI deployment, it is a safety issue and a P&L issue at the same time. If the model deciding whether an autonomous tractor turns left or right needs a fresh field-condition update stuck behind a lost handover, the tractor doesn't turn. If the reefer intervention depends on a live temperature stream that drops out across the coverage gap between Livingstone and Lusaka, the intervention window closes. If the driver-behaviour model stops inferring because the SIM lost its network at Beitbridge on a Tuesday morning, the safety event never fires.

The African IoT industry is trying to solve an asset problem with roaming SIMs and travel products. That framing gets sharper under Physical AI. Roaming was engineered for a phone in a pocket for two weeks, not for a mission-critical asset whose operating model assumes a live decision loop across four countries and 3–5 years of deployment.

Connectivity for Physical AI in Africa has to be treated as a stack where four layers depend on each other (device, connectivity, cloud/application, and operations), and if any single layer breaks, the others cannot compensate. When a Physical AI deployment fails, the failure usually lives in one specific layer. The buyer's job is to know which. The operator's job (CommsCloud's job) is to make sure the connectivity layer is not the one that broke, and to be able to prove it. Our Layer Diagnosis Protocol is the operational form of that discipline.

The always-on requirement is not "high uptime with best-effort SLA." It's a design principle that flows backwards into SIM technology, MNO strategy, failover architecture, and operations partner. If any of those is wrong, the Physical AI loop is wrong.

Edge vs cloud: where AI actually runs

Physical AI is usually a split: inference runs at the edge on the device, training and model refinement runs in the cloud, and the two ends need to talk to each other reliably. The reason inference runs at the edge is latency. A driver-behaviour model alerting on a fatigue event 800 milliseconds after it starts is not going to route through a cloud endpoint 3,000 kilometres away. A precision-agri implement making a spray-decision every 200 milliseconds is not going to wait for cloud round-trip. Edge inference is a physics constraint, not a preference.

Training stays in the cloud because a single device sees a narrow slice of the world, and fleet-wide learning is what makes the model good. The connectivity layer's job is to move edge inference results, raw telemetry, and model updates in both directions on a predictable cadence: the two-way flow the next section's standards are built for.

There is a privacy-by-design point underneath this. Edge inference lets sensitive data (driver footage, patient vitals, precision-agri yield maps) stay on the device, with only the model output travelling to the cloud. That reduces data-sovereignty surface area, which matters in African markets where the regulatory environment is uneven. Treat edge inference as a data-residency tool as well as a latency tool.

eSIM, SGP.32, and iFPP: the standards enabling scale

The industry has spent five years moving from the consumer eSIM standard (SGP.22) to an IoT-specific one that fits embedded devices. SGP.32 is that standard, ratified by the GSMA and now in commercial deployment. It matters because the old eSIM stack assumed a human on the device pressing "consent". No such human exists on a soil-moisture sensor or an in-vehicle telematics unit. SGP.32 replaces that model with an IoT Profile Assistant (IPA) that lets remote profile management work at fleet scale, without a screen and without a human. For the full breakdown, see our SGP.32 explainer.

Below SGP.32 sits iFPP: in-factory profile provisioning. iFPP lets an OEM install a bootstrap eSIM profile at the factory, then have it replaced remotely once the device is deployed. For an OEM shipping 100,000 units into 12 African countries, iFPP is the difference between a workable supply chain and a broken one. Without it, the OEM would need to know the final country of deployment at factory time, which they usually don't.

Kigen is one of the notable eSIM operating system vendors in this conversation and has published useful reference material on the OEM side of the stack, including the Wevolver piece cited above, which they sponsored. Their OEM IoT eSIM guide is worth reading if you are on the product engineering side. We work in the layer above the operating system and the network (the operations layer that turns SGP.32 capability into a working African deployment), so our view is complementary to theirs, not overlapping.

The important point for an African IoT operator deciding now: SGP.32 and iFPP are not a future story: they are shipping. The choice you make on your next hardware revision (SGP.32-capable module, OEM iFPP roadmap, connectivity strategy assuming remote profile management from day one) determines whether your Physical AI deployment carries cleanly through 2030 or gets stuck at the country boundary.

The African reality: why the network layer matters

This is where the Kigen article stops and the African operator perspective starts. The network underneath eSIM in Africa is not the network that runs under eSIM in Germany or the United States. Six things are structurally different.

Coverage variance. MNO coverage inside a single African country is more uneven than in most of Europe, and cross-corridor coverage shifts month to month. A deployment on Beitbridge sees different network availability on a Tuesday morning than on a Saturday afternoon. Static coverage maps are not a useful design input; live signalling intelligence is.

MNO fragmentation. A cross-border deployment across five African countries touches five, sometimes eight, sometimes twelve MNOs. Direct commercial relationships with every MNO along a corridor is not economically viable, and roaming as the substitute has the cost and reliability profile every African operator knows too well.

PLMN block risk. Individual MNOs block PLMN routings on their own timescales, sometimes without notice, sometimes for commercial reasons unrelated to the deployment. A Physical AI deployment that assumes a particular IMSI-to-MNO routing can find it gone one morning. The operations layer has to have already switched routing before the device notices.

Home-network fallback. When multi-IMSI orchestration cannot find a viable network, the SIM's home-network fallback determines whether the device stays connected at reduced quality or drops entirely. Getting this right is an operations question, not a hardware question.

Multi-IMSI architecture. Multiple network profiles on one SIM is the mechanism that lets a device stay connected across borders without manual intervention. The design choice isn't "multi-IMSI yes or no". That's decided. It's which orchestration and which IMSI lanes, and that determines everything downstream. This is what multi-IMSI orchestration has to deliver in practice.

Network choice. The multi-IMSI network we operate on is our Layer 1: the core we run our operations layer above. There are others; the choice matters. The African operator picking that layer in 2026 is picking the network that will carry Physical AI deployments through 2030, and the criteria differ from what a European operator would apply.

CommsCloud's Africa positioning rests on two pillars from our four-pillar durability frame. Pillar 1 is the quality-of-service moat: the operational reality that time-to-resolution in Africa matters more than in any other region, and a connectivity-only vendor cannot solve that because their cost-to-serve model is their revenue model. Pillar 3 is eUICC network-independence: the readiness that converts single-network dependency into multi-network orchestration, so the Physical AI operator is not locked to any single network relationship for the 3–5 year device lifecycle. Both pillars matter more for Physical AI than for the previous generation of dashboard IoT, because operational tolerance for failure is lower and the deployment horizon is longer.

The Layer Diagnosis approach for Physical AI deployments

Physical AI systems have more layers of failure surface than typical IoT deployments. A dashboard-based fleet-management platform has roughly the seven layers we describe in the Layer Diagnosis Protocol: device, dashboard, SIM, MNO signalling, billing, coverage, client-side config. A Physical AI deployment adds two: the edge inference layer and the cloud training layer. Nine layers of potential failure, each of which can look like a connectivity problem to the operator.

Which is why the Layer Diagnosis approach matters more here than anywhere else. The playbook: for every layer, know who controls it, what the operator actively mediates, and what the client can see themselves. When a Physical AI deployment starts producing anomalous behaviour, the operations team can identify which of the nine layers the anomaly lives at, rather than defaulting to "the SIM is broken."

The framing changes the buying conversation. A buyer choosing a connectivity partner for a Physical AI deployment should ask what the partner mediates and diagnoses at every layer, not just the ones they own. If the answer is "we can only see the SIM," the partner is a component supplier, not an operations partner. The buyer needs the second one.

What operator-grade connectivity looks like for African Physical AI

The operator-grade discipline that Physical AI in Africa needs is not a marketing claim: it's a shape. Four things characterise it.

An agentic operations layer above the network. CommsCloud's position in the stack is Layer 2: the operations layer that runs above the Layer 1 multi-IMSI network. That layer is where multi-IMSI orchestration decisions get made, where rate-management logic lives, where the Layer Diagnosis Report gets generated when a device starts drifting. A small team using AI to multiply its reach can carry the operational load of Physical AI deployments across a dozen African markets, at operator-grade discipline, without scaling headcount linearly with device count.

Network-independence via eUICC. Operational readiness on eUICC means the Physical AI deployment is not architecturally locked to any single network relationship. If the network underneath us drifts, or a better one emerges, or a specific corridor needs a different arrangement, the multi-network orchestration handles it. That optionality is what "operator-grade" means over a 3–5 year device lifecycle.

A two-phase deployment architecture. Phase one (available now) is eUICC + API: multi-IMSI orchestration on an eUICC, with our API for provisioning, monitoring, and diagnostics. Phase two (on the roadmap) is deeper core integration for the deployments that need it. The right sequencing is phase one now, phase two when the specific deployment's economics justify the additional integration effort. Compounding the wrong solution (bolting deeper integration onto a deployment that doesn't need it) is a specific class of expensive mistake worth naming.

The client-enablement layer. Support, SLA, and training that turns the buyer into a competent diagnostic partner. We do not only work at our own layers of the stack; we equip the client to diagnose at theirs. For a Physical AI deployment, that means visibility into SIM state, signalling events, rate configuration, and diagnostic outputs, so the client can identify what they are looking at before opening a ticket.

How to design connectivity into your Physical AI product from day one

If you are on the product engineering side of a Physical AI deployment aimed at African markets, the practical checklist is short.

1. Specify SGP.32-capable modules. Small cost delta versus a legacy eSIM stack, large operational upside, and it positions your roadmap for the 2027–2028 shift in industry defaults.
2. Get iFPP into the OEM conversation early. If your OEM does not have iFPP on the roadmap, the supply-chain arithmetic hurts at scale.
3. Design the connectivity layer as network-independent orchestration, not a single-MNO dependency. Multi-IMSI is table stakes. The design question is which orchestration and which failover behaviour.
4. Design the diagnostic surface into the device. A Physical AI device should expose SIM state, signalling events, and modem behaviour to the operator's diagnostic pipeline. Without that, the operator cannot mediate the connectivity layer for you.
5. Choose an operations partner, not a component supplier. The partner should be able to describe what they do at every layer of the stack, including the ones they don't own.
6. Assume a 3–5 year device lifecycle. The connectivity architecture chosen today has to still be viable in 2030. Network-independence is what makes it viable.

None of this is difficult. All of it gets more expensive the later you address it.