Kasumbalesa IoT connectivity for fleets

Kasumbalesa IoT connectivity, keeping your fleet visible at the copperbelt crossing

Kasumbalesa is where copper and cobalt leave the Congolese copperbelt for the south, and where a lot of fleet trackers go quiet. It is the crossing that shows you whether your connectivity was built for a border or only for the open road.

4 a.m. at Kasumbalesa

The truck has been in the line since the afternoon. It is one of hundreds nose-to-tail on the approach, and the queue has not moved in three hours. In Lusaka a controller has the fleet dashboard open, and one of the trucks on the Kasumbalesa run has stopped reporting. Not moving — reporting. The last position is a timestamp from before midnight, on a stretch of road the controller already knows is a car park.

The device is working. The problem is underneath it. Parked at the border, the tracker is holding to one operator's cell, and that cell is carrying every phone and every device in a queue that runs for kilometres. When it drops, the SIM has nowhere else to go — it is provisioned for one network, so it sits and retries the network that is already saturated. On the far side of the gate the trucks cross into the DRC, and there the device has to find a Congolese network and authenticate onto it before it can report again. For the hours in between, the load is invisible.

By the time the truck clears and the tracker reappears near Lubumbashi, the controller has spent a night guessing. Where in the queue is it. Has it moved. Is the driver where he should be. None of those questions had to go unanswered — the gap was never the device or the driver. It was a SIM that could only ever hold one network, at the one place where one network is never enough.

Why Kasumbalesa is the lane that exposes connectivity weakness

Kasumbalesa is not one border post but two — a Zambian side and a Congolese side, cleared separately, with a single gate between them. A one-stop border post has been recommended but not yet built, and the queues show it: on a bad week the line runs 10 km or more, reported as long as 25 km, with dwell that can reach several days. Freight-press and corridor bodies have tracked the congestion through 2025 and 2026, and a US$600m dry port was agreed in December 2025 to work it down. The crossing sits where several of Southern Africa's key trade corridors meet, including the North–South and Lobito corridors, so a device that goes dark here is dark on a lane that carries a large share of the region's copper.

Three things move against a connected asset at a crossing like this. The networks decide whether the device connects at all — one operator's coverage at the border, one roaming arrangement into the next country. The border adds a second country and a second set of networks on the far side of one physical line, and every crossing means finding a new network and authenticating onto it. And the commercials shift underneath a long dwell, as rate sheets and roaming charges change while the truck sits still. A single-network device meets all three at once at Kasumbalesa, and any one of them is enough to take the tracker offline.

The result is the pattern the controller saw: coverage that tapers as the truck nears the line, a cell that saturates in the queue, and a roaming handover on the DRC side that a single-SIM device cannot pre-empt. It is not a device fault and it is not a driver fault. It is a connectivity design that assumed one network would always be there.

What works at Kasumbalesa, and why

CommsCloud is the operator layer for African IoT — the layer that keeps the connection working while networks, borders and commercials shift underneath it. The CloudConnect™ SIM carries several mobile networks on each side of the border rather than one. On the Zambian side that includes MTN Zambia, Airtel Zambia and Zamtel; on the Congolese side, Vodacom Congo, Airtel Congo RDC and Africell. The SIM holds the strongest available network and switches between them on its own, so the device rides out the saturated cell in the queue and finds a Congolese network on the far side without a manual swap.

Underneath the SIM, autonomous multi-IMSI failover moves the device between networks without anyone touching it. Local PGW breakout keeps the data path short instead of hauling it back across the continent, which is what keeps a tracker responsive at the edge of coverage. And the OEM Settings Library holds the tested configurations for the devices fleets actually run, so a unit is provisioned to behave correctly on this corridor before it ships.

That is the difference between an asset and a traveller. A traveller's phone roams for convenience; a fleet asset has to stay connected, because the whole point of the tracker is that it never stops reporting. One SIM. All Borders. No Downtime.

What the numbers look like once you fix it

CommsCloud runs 780+ client deployments across 50+ African countries, with reach across 650+ mobile networks in 180+ countries and 99.8%+ core-network uptime, and activation in under 24 hours. For BHL Group that meant 600 trucks kept online across six countries on a single platform — replacing five — and a 30% cut in satellite costs.

What the engineering and operations conversation looks like

Most connectivity problems at a border are read as coverage problems and solved by throwing another SIM at them. The more useful conversation starts a level down: how the device is configured, which data profile it runs, how its firmware handles a network drop, and whether it is set to hunt for a new network or to sit and retry the old one. That is the diagnostic we run before we quote anything, and it is why the OEM Settings Library exists — the fix is usually in how the device and the SIM are set up to behave, not in adding hardware.