What ‘Local’ Really Means for Global IoT

Customers often use one word – “local” – to describe several different requirements. A local profile, local breakout, local application endpoint and local data processing are related, but they are not interchangeable.

A global IoT provider may receive a request such as:

“We need the service localised in this country.”

Before an architecture can be designed, that request needs to be separated into distinct questions.

1. Which mobile network and subscriber profile will the device use?
2. Is the device temporarily or permanently roaming?
3. Where will the user-plane session be anchored?
4. Where will traffic leave the mobile environment and what destination will it use?
5. Where will application data be stored and processed, and which legal rules apply?

Treating these as one “localisation” feature creates technical gaps and compliance risk.

Permanent roaming is important to many M2M and IoT services because devices may remain outside the profile’s home country for long periods.

BEREC’s 2024 report found permanent roaming particularly relevant to automotive and shipping. It also identified challenges around negotiations, pricing, access, minimum commitments and the creation of a complete multi-country footprint.

The European Commission’s 2025 review found that M2M/IoT providers could access EU-wide permanent-roaming solutions, while also noting reports of potentially restrictive wholesale practices and committing to continued monitoring.

The practical lesson is that permanent roaming is a commercial and regulatory question as well as a technical one. Local breakout does not change the subscriber identity or create permission to roam permanently. A local profile may be the appropriate answer in some markets; negotiated roaming remains appropriate in others.

The packet gateway anchors the mobile-data session. In a central home-routed design, traffic may travel back to a home gateway. In a distributed design, selected sessions can be anchored at a regional gateway.

This is the decision most directly associated with local or regional breakout. It affects the user-plane path, but it must still align with control-plane, charging, policy and operational requirements.

Packet anchoring can be selected by service design – for example by APN, subscriber range, customer, device group or region – rather than being one global setting.

Where traffic leaves the packet gateway is not necessarily its final destination.

A service might route to:

• The public internet.
• An IPsec or WireGuard VPN.
• A private Layer 2 or Layer 3 interconnect.

• A customer data centre.
• A configured cloud or application environment.
• Another regional network service.

Network routing can control the path and exit point. It does not alone determine where every downstream system stores or processes data.

Data residency usually concerns where data is stored or processed. Data sovereignty concerns the legal authority and rules that apply. A cross-border transfer is a legal and operational event that may be permitted subject to defined safeguards.

The GDPR is a useful example of why precision matters. Its Chapter V regulates transfers to third countries; it does not simply say that European data can never leave Europe.[4]

A responsible service design therefore links:

• The network path.
• The application and hosting architecture.
• The parties’ controller and processor roles.
• Contractual safeguards.
• Security controls.
• Audit and operational evidence.

An IPX or packet-gateway provider can help implement and evidence the approved network path. The customer and its advisers still need to determine the full legal requirement.

SGP.32 gives the ecosystem a more flexible way to manage profiles. That is likely to increase the number of combinations a connectivity provider must support:

• A global bootstrap profile followed by a local operational profile.
• A local profile using a regional packet gateway.
• A roaming profile with selective regional breakout.
• Several IMSI providers using a consistent application and policy environment.

If every profile change also requires a new core integration, portal, API and application route, much of the promised flexibility is lost.

The strategic opportunity is to separate provider choice from service behaviour. A programmable core and edge layer can support multiple IMSI or profile relationships while presenting consistent routing, segmentation, visibility and operational controls to the customer.

For every enterprise service, providers should be able to state:

• The profile and roaming model.
• The control-plane and user-plane responsibilities.
• The selected packet-gateway region.
• The allowed routing targets.
• The failover behaviour.
• The observable events and metrics.
• The storage and processing assumptions owned by the application.
• The parties responsible for legal approval and operational support.

That is a more useful definition of “localised connectivity” than a pin on a map.

The next time a customer asks for a “local” service, separate the request into profile, roaming, anchoring, routing and processing decisions. The resulting design will be clearer and much easier to defend.

1. GSMA, SGP.32 v1.3: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-32-v1-3/
2. BEREC, Report on M2M and permanent roaming: https://www.berec.europa.eu/en/all-documents/berec/reports/berec-report-on-m2m-and-permanent-roaming
3. European Commission, 2025 review of the roaming market: https://digital-strategy.ec.europa.eu/en/library/commission-report-review-roaming-market-0
4. EUR-Lex, General Data Protection Regulation: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679