How Global IoT Connectivity Actually Works
Deploying IoT devices across 50 countries quickly reveals the complexity hidden beneath the phrase “global cellular connectivity”.
Understanding how data travels from a device in Kenya to a backend in London, traversing operators, roaming agreements, international gateways, and routing policies, is essential for troubleshooting connectivity failures, optimising latency, and controlling operational costs.
This guide explains the architecture behind global IoT connectivity, how roaming really works, why latency varies between deployments, and how to design connectivity infrastructure for global scale.
Global IoT Connectivity Layers
Layer 1: Radio Access
Device to Local Cell Tower
In every country, an IoT device connects to a local mobile operator’s radio network using country-specific frequency bands.
Example: Device in Germany
A device deployed in Germany may scan:
- 800 MHz
- 900 MHz
- 1800 MHz
- 2100 MHz
It detects networks such as:
- Deutsche Telekom
- Vodafone Germany
- O2 Germany
The device then selects a network based on SIM configuration and available signal strength.
The Challenge
Different countries use different cellular frequency bands.
Europe
- 800 MHz
- 900 MHz
- 1800 MHz
- 2100 MHz
USA
- 700 MHz
- 850 MHz
- 1700 MHz
- 1900 MHz
Asia
A mixture of European and US bands, plus:
- 2300 MHz
- 2500 MHz
Device Requirement
Devices intended for global deployment require multi-band modems that support all target regions.
Common Failure Mode
A device designed only for European bands may fail completely when deployed in the USA because the modem does not support the required frequencies.
Layer 2: Local Operator Core Network
Once connected to a cell tower, traffic moves through the local operator’s core network.
Typical components include:
- MME (Mobility Management Entity) for authentication
- S-GW (Serving Gateway) for packet routing
- P-GW (Packet Gateway) for external network access
The local operator, often called the visited network, provides radio access and packet routing within the country.
Two Connectivity Scenarios
Scenario A: Local SIM
The device uses a SIM issued by a local operator.
- The device is treated as a home subscriber
- Traffic routes directly through the local operator
- No roaming is involved
Scenario B: Roaming SIM
The device uses a SIM issued by a foreign operator.
- The device roams onto a visited network
- Authentication occurs with the home network
- Traffic may route internationally depending on roaming configuration
Layer 3: International Roaming and Data Routing
Example
A UK-issued SIM from Vodafone UK travels to France and connects to Orange France.
Authentication Flow
- The device attempts to register on Orange France
- Orange France queries Vodafone UK
- Vodafone UK validates the IMSI via the HLR or HSS
- Vodafone UK authorises access
- Orange France provides connectivity
The important question comes next:
Where does the data go?
There are two common architectures.
Option 1: Local Breakout
Traffic routes directly from the visited network to the internet or application destination.
Data Path
Device → Orange France → Internet → Server
Benefits
- Lower latency
- Fewer routing hops
- Better performance
- More efficient routing
Typical Latency
20 to 50 ms for local traffic.
Option 2: Home Routing
Traffic routes back to the home operator before reaching the destination.
Data Path
Device → Orange France → Vodafone UK → Internet → Server
Benefits for the Home Operator
- Billing visibility
- Security policy enforcement
- Centralised private APN termination
- Traffic inspection and filtering
Trade-Off
Greater control, but increased latency and longer routing paths.
Typical Latency
100 to 200 ms for the same workload.
Why Some Global IoT Connections Feel Slow
The difference between local breakout and home routing becomes obvious at scale.
A device in France sending data to a French application should ideally stay within France. If traffic is backhauled through the UK first, latency increases significantly.
This is why understanding roaming architecture matters for:
- real-time telemetry
- video telematics
- payment terminals
- industrial control systems
- safety-critical devices
Layer 4: Roaming Agreements and Roaming Tiers
Not all roaming agreements are equal.
Tier 1: Direct Bilateral Agreements
The home operator has a direct technical and commercial agreement with the visited operator.
Example
Vodafone UK ↔ Orange France
Characteristics
- Faster troubleshooting
- More predictable routing
- Lower latency
- Better commercial terms
Tier 2: Roaming Hub
Traffic routes through an intermediary roaming exchange.
Data Path
Device → Orange France → Roaming Hub → Vodafone UK
Characteristics
- Additional network hop
- Higher latency
- Slower fault resolution
Tier 3: Cascaded Roaming
Multiple intermediaries exist between the home and visited network.
Data Path
Device → Orange France → Hub A → Hub B → Vodafone UK
Characteristics
- Multiple routing hops
- Increased latency
- Greater troubleshooting complexity
- Additional wholesale margin layers
Why Roaming Tier Matters
For global IoT deployments, roaming architecture directly affects:
- latency
- throughput
- troubleshooting speed
- reliability
- operational cost
When evaluating connectivity providers, it is worth asking:
“Do you operate direct Tier 1 agreements in our target countries, or is traffic routed through roaming hubs?”
Layer 5: International Gateways and Submarine Cables
Global IoT connectivity depends on physical infrastructure.
International Connectivity Uses
Submarine Fibre Cables
Intercontinental fibre optic cables running along the ocean floor.
Terrestrial Fibre Networks
Land-based fibre routes between neighbouring countries.
Satellite Connectivity
Typically used only in remote or backup scenarios because of higher latency and cost.
Example: Kenya to London Connectivity Path
Physical Route
- Device connects to Safaricom Kenya
- Traffic reaches the operator core in Nairobi
- Data routes via Mombasa international gateway
- Traffic enters a submarine cable system such as EASSy
- Traffic lands in the UK
- Data routes to backend infrastructure in London
Typical Latency Budget
| Segment | Latency |
|---|---|
| Kenya radio and core network | 20 to 40 ms |
| Kenya to UK submarine route | 80 to 120 ms |
| UK routing and backend access | 10 to 20 ms |
| Total | 110 to 180 ms |
Common International Failure Modes
Submarine Cable Damage
Cable faults occur regularly and can force traffic onto alternative routes with higher latency.
Gateway Congestion
Peak traffic periods can create packet loss and increased latency at international exchange points.
Multi-Network SIM Architecture
Traditional Single-IMSI SIM
A traditional SIM contains one IMSI linked to one operator.
Example
Vodafone UK IMSI:
- 234150…
Devices roam globally using Vodafone’s roaming agreements.
Limitations
- Coverage gaps where roaming agreements do not exist
- Single operator dependency
- Potential routing inefficiencies
- Limited resilience
Multi-IMSI SIM
A multi-IMSI SIM stores multiple operator identities.
Example
- Vodafone UK IMSI
- AT&T USA IMSI
- Vodafone Germany IMSI
How It Works
The SIM selects the most appropriate IMSI based on:
- region
- cost
- signal quality
- roaming availability
- policy configuration
Example
A device deployed in the USA can activate a local AT&T profile instead of roaming internationally.
Benefits
Coverage Redundancy
Alternative IMSIs provide fallback connectivity.
Cost Optimisation
Local registration can reduce roaming charges.
Improved Performance
Local connectivity generally lowers latency and improves throughput.
Limitation
SIM storage capacity limits the number of IMSIs available simultaneously.
eSIM and eUICC Global Connectivity
eSIM and eUICC architecture allows connectivity profiles to be provisioned remotely.
Before Deployment
Devices may ship with:
- bootstrap profiles
- regional profiles
- temporary provisioning profiles
After Deployment
Operators can remotely provision:
- local operator profiles
- regional connectivity plans
- replacement network profiles
Example
- Devices in Kenya receive Safaricom profiles
- Devices in Nigeria receive MTN profiles
- Devices in Europe receive regional European profiles
Result
Devices operate as local subscribers rather than roaming subscribers.
This typically improves:
- latency
- cost efficiency
- operational flexibility
Global IoT Connectivity Design Patterns
Pattern 1: Global Roaming with Single Operator
Advantages
- Simple procurement
- Single contract
- Unified management
Disadvantages
- Home routing latency
- Coverage limitations
- Roaming costs
- Single point of failure
Best For
- Small deployments
- Limited regional coverage
- Non-latency-sensitive applications
Pattern 2: Multi-Network SIM Strategy
Advantages
- Local connectivity in major regions
- Improved resilience
- Better cost control
Disadvantages
- Limited IMSI capacity
- Some regions still rely on roaming
Best For
- Medium-scale deployments
- Multi-region operations
- Mixed performance requirements
Pattern 3: eSIM with Regional Provisioning
Advantages
- Local connectivity everywhere
- Lowest roaming exposure
- Flexible operator management
Disadvantages
- eSIM provisioning complexity
- Lifecycle management overhead
Best For
- Large global deployments
- Long-lifecycle devices
- Performance-sensitive workloads
Pattern 4: Hybrid Architecture
Combines:
- preloaded multi-network profiles
- remote eSIM provisioning
- regional optimisation
Benefits
- Faster deployment
- Long-term flexibility
- Improved resilience
Best For
- Enterprise-scale global deployments
- Evolving regional requirements
- High operational complexity
Latency and Performance Optimisation
Comparing Connectivity Models
Single Operator Global Roaming
Device → Visited Network → Home Network → Backend
Typical Latency
180 to 250 ms
Multi-IMSI with Local Breakout
Device → Local Network → Internet → Backend
Typical Latency
120 to 160 ms
eSIM with Local Operator Profile
Device → Local Operator → Internet → Backend
Typical Latency
110 to 150 ms
How to Reduce IoT Connectivity Latency
1. Use Local Breakout
Avoid unnecessary home routing where possible.
2. Deploy Regional Backends
Instead of a single backend in London:
- Europe backend in London
- Asia backend in Singapore
- Africa backend in Johannesburg
Example
Kenya device → Johannesburg backend:
- 40 to 60 ms latency
Compared with:
- 110 to 150 ms to London
3. Use Edge Processing
Process data closer to the mobile edge before forwarding only essential data centrally.
This is particularly useful for:
- video analytics
- industrial monitoring
- telematics
- AI inference workloads
Troubleshooting Global IoT Connectivity
Device Cannot Connect
Possible Causes
- No roaming agreement in-country
- Unsupported frequency bands
- SIM provisioning issue
- IMEI restrictions
Recommended Checks
- Verify local operator compatibility
- Validate modem band support
- Attempt manual network selection
- Confirm roaming permissions with operator
Slow Data Performance
Possible Causes
- Home routing congestion
- Tier 3 roaming architecture
- Local network congestion
- APN limitations
Diagnostics
- Run traceroute analysis
- Identify routing hops
- Compare performance by time of day
- Review roaming tier architecture
Intermittent Connectivity
Possible Causes
- Weak radio signal
- Frequent network switching
- HLR authentication instability
Diagnostics
- Review RSSI and RSRP logs
- Check network reselection frequency
- Monitor authentication failures
How OV Supports Global IoT Connectivity
OV provides global IoT connectivity infrastructure designed for builders deploying connected products internationally. OV operates across 180+ countries and 600+ networks with support for multi-network connectivity, eSIM architectures, and API-first orchestration through the OV ONE platform.
Key capabilities include:
- multi-network IoT connectivity
- local and regional optimisation strategies
- eSIM and eUICC readiness
- API-first connectivity orchestration
- direct MNO core integration
- real-time connectivity visibility through OV ONE
OV ONE gives technical teams visibility into SIM lifecycle management, connectivity performance, network behaviour, and deployment control through a single interface or API.
To discuss global IoT connectivity architecture, contact: connectivity@worldov.com
© 2026 OV (WorldOV). All rights reserved.



