Logo

How Global IoT Connectivity Actually Works (Architecture)

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

  1. The device attempts to register on Orange France
  2. Orange France queries Vodafone UK
  3. Vodafone UK validates the IMSI via the HLR or HSS
  4. Vodafone UK authorises access
  5. 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

  1. Device connects to Safaricom Kenya
  2. Traffic reaches the operator core in Nairobi
  3. Data routes via Mombasa international gateway
  4. Traffic enters a submarine cable system such as EASSy
  5. Traffic lands in the UK
  6. 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

  1. No roaming agreement in-country
  2. Unsupported frequency bands
  3. SIM provisioning issue
  4. 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

  1. Home routing congestion
  2. Tier 3 roaming architecture
  3. Local network congestion
  4. APN limitations

Diagnostics

  • Run traceroute analysis
  • Identify routing hops
  • Compare performance by time of day
  • Review roaming tier architecture

Intermittent Connectivity

Possible Causes

  1. Weak radio signal
  2. Frequent network switching
  3. 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.