Roaming changes what a SIM estate is. A card is issued by one operator in one market, and the address it presents belongs to that operator wherever the card is used, which is the fact that shapes every cross-border deployment.
This article sets out what roaming means for a managed estate, why the address follows the issuing operator, how registration requirements differ by market, how to centralise the estate while leaving radios local, and how to choose between roaming and locally issued subscriptions.
What does a SIM bank for cross-border roaming change for a managed estate?
The card travels; the subscription does not.
A roaming card registered on a visited network still belongs to its home operator, and the arrangement between the two networks determines what the card may do and what it costs.
That has three consequences for a managed estate. The identity presented to the network is the home operator’s, so a deployment that needs a local address cannot obtain one by moving a card. The commercial terms are the home operator’s roaming terms, which are usually less favourable than a local subscription. And the service the card receives depends on the visited network’s acceptance of the home operator’s subscribers, which varies by market and by agreement.
The identifier conventions behind those relationships are described in ITU-T E.212 for the network identity and ITU-T E.118 for the card, and they are the two fields a cross-border register should be keyed on. Where a deployment operates in several markets, those two fields also tell an operator which cards are roaming and which are local.
| Arrangement | Address presented | Commercial terms |
|---|---|---|
| Local subscription | Local operator’s numbering | Local tariff |
| Roaming on a visited network | Home operator’s numbering | Home operator’s roaming terms |
| Remotely provisioned profile | Whatever the profile carries | Depends on the profile arrangement |
Why does the address belong to the issuing operator?
Because the number is allocated to the operator.
A subscription carries a number from the issuing operator’s allocation, and that relationship is unaffected by where the card is used.
This is the point at which many cross-border plans go wrong. A deployment that needs recipients to see a local number cannot achieve that by moving an existing card abroad: the number stays where it was issued. Achieving a local address requires a subscription issued in that market, whether as a physical card obtained locally or as a profile provisioned through an operator that can issue in that market. The numbering plan that governs the allocation is described in ITU-T E.164.
The practical consequence for estate design is that the estate is a set of market-specific subscriptions rather than a pool of interchangeable cards. Capacity in one market cannot be used to cover another, and the register should therefore record the market each subscription belongs to as a primary attribute rather than as a note. Where the deployment is growing into new markets, the question to answer first is which operator can issue there, and second how the cards or profiles reach the radios.
It also explains why a deployment that has ample capacity overall can still fail in one market. Capacity is local because the subscription is local, and a pool that is idle in one country contributes nothing to a shortage in another. Sizing therefore has to be done per market even when the estate is administered centrally, and the sizing figure for each market is the peak it has to serve rather than a share of a global total.
Where a market is served by several operators with different characteristics, the per-market plan should name them, because the achievable rate and the commercial terms differ between them. A market with two suitable operators has a route around a problem; one with a single operator does not, and that fact belongs in the risk section of the plan rather than in an appendix. The per-market estate also carries its own cover requirement, which is covered by the per-number and per-market records described in the SK-SMS Gateway range when the hardware is specified.
Registration requirements per market
Registration is local, and so are the requirements around it.
Markets differ in what a subscription must satisfy before it carries the traffic a deployment intends, and the differences are commercial and regulatory rather than technical.
Three categories of requirement appear repeatedly. Identity requirements, where an operator requires the subscriber to be identified before activation. Usage requirements, where a tariff permits certain traffic profiles and not others. And equipment or registration requirements, where the deployment has to be registered in some way before it can operate. None of these are discoverable from a specification; they come from the operator in each market.
The registration process with the network itself is standardised, and the states a subscription passes through are defined in 3GPP TS 24.301. What differs by market is what has to be in place before the subscription is allowed to reach those states, and that is the part to confirm in writing before cards are ordered.
Centralising the estate while radios stay local
The two decisions are independent.
Cards or profiles can be managed centrally while the radios that use them remain in the markets they serve.
Centralising the estate means one place to issue, allocate, rotate and retire, which reduces the administrative work and makes the register accurate by construction. Leaving the radios local means the transmission happens where the traffic is, which is what keeps the network relationship local and avoids the roaming question entirely. Together they give a deployment that operates locally while being administered centrally.
That architecture has one dependency worth naming: the link between the central estate and the local radios. Where SIM bank or SIM pool hardware is used across sites, the link carries the command traffic, and its latency and availability become part of the deployment’s behaviour. The message path itself is defined in ETSI TS 123 040, and the practical design question is whether a command that must complete quickly can tolerate the link delay or should be issued locally.
Keep the per-market plan short and current. One page per market with the operator, the subscription type, the achievable rate measured on that operator, the cover held and the review date is enough to answer the questions that arise during an incident, and it is far more useful than a single global document that describes a fleet that does not exist.
Cost structure: roaming versus local issuance
The comparison is between convenience and unit cost.
Roaming avoids the work of obtaining a subscription in each market and usually costs more per message than a local tariff.
Whether the premium is worth paying depends on the volume and the duration. A short campaign in a new market can be cheaper on roaming than on the effort of obtaining a local subscription, particularly where the deployment has no entity in the market. A permanent presence with steady volume is almost always cheaper on local issuance, because the roaming premium is paid on every message rather than once.
The comparison should include the costs that are easy to omit: the administrative effort of obtaining and maintaining local subscriptions, the cost of shipping and replacing cards, and the operational cost of a failure in the registration process. Those are the reasons roaming sometimes wins even at volume, and they belong in the calculation rather than in a footnote.
Failover between markets
A subscription cannot be moved to another market to cover a failure.
Because the address belongs to the issuing operator, failover between markets means capacity in each market, not capacity that follows demand.
That changes the redundancy design. A single-site deployment can hold a spare unit and a spare set of cards; a multi-market deployment has to decide, per market, how much local capacity to hold as cover. Holding spare capacity in every market is expensive; holding none means that a market-specific failure has no route around it. The practical approach is to size cover from the cost of the outage in each market rather than uniformly.
Where a deployment does use roaming as a fallback, the fallback should be measured rather than assumed. A roaming path that has never carried traffic in that market may behave differently from the local path in both cost and acceptance, and the only way to know is to test it. The subscription states involved in any case are defined in 3GPP TS 24.301, and the record of which path was used belongs with the per-message log described in NIST SP 800-92.
A deployment outline
The outline follows the order in which the decisions have to be made, starting with the markets and the arrangement behind each one. It is written for a project rather than for a purchase, because the commercial and regulatory answers constrain the hardware rather than the other way round.
- List the markets, and for each one the operator that can issue a subscription locally.
- Record the identity and registration requirements per market, in writing, before ordering.
- Decide per market whether the subscription is local or roaming, and record the reason.
- Key the register on the card identifier, the network identity and the market.
- Decide where the radios sit, and confirm that the link to a central estate can tolerate the command traffic.
- Define the cover per market from the cost of an outage in that market.
- Test the fallback path in each market rather than assuming it behaves like the primary.
The outline produces a per-market estate plan rather than a single pool, which is what a cross-border deployment actually is. A fleet documented this way can answer the question that matters during an incident: which market is affected, which subscriptions serve it, and what the route around the failure is.
Plan per market, not per fleet. Send your market list, volume profile and current subscription arrangements to service@telarvo.com, or review the published configurations on the SIMBANK128 page and the SIM pool range. Telarvo publishes the SIMBANK and SIMPOOL ranges on its product pages, and the configurations referenced above come from those listings.
FAQ
Can a roaming SIM present a local number in another country?
No. The number belongs to the issuing operator, and roaming changes which network carries the traffic rather than which number is presented. A local address requires a subscription issued in that market, obtained either as a physical card or as a profile provisioned there. The distinction matters because pricing and recipient recognition both follow the number. Confirm which address a recipient will see before choosing between the two arrangements.
Is it cheaper to roam or to buy local SIMs?
Roaming is usually cheaper for a short deployment in a market where the organisation has no presence, and local issuance is usually cheaper for steady volume because the roaming premium applies to every message. Include the administrative effort of local issuance in the comparison before deciding. That effort is what usually decides short deployments. Model three years of steady volume rather than the first month, because the premium compounds.
Can one SIM bank serve radios in several countries?
It can, and the arrangement centralises administration while the radios stay local. The dependency is the link between the estate and the radios: command traffic crosses it, so the latency it adds has to be acceptable for the operations that use the link, or those operations should be issued locally. Measure the link before committing to the topology. Record the measured latency with the topology, so that a later change can be compared with the original design.
What has to be checked before ordering cards for a new market?
The identity and registration requirements the operator applies before activation, whether the tariff permits the intended traffic profile, and whether the equipment arrangement is acceptable. Those are commercial and regulatory conditions rather than technical ones, and they come from the operator rather than from a specification. Record each answer per market and date it. Where an answer is not available, record that fact rather than an assumption, because it is the item to resolve before ordering.