A 128-slot tier is bought for a project rather than for a rack, and cross-border projects add requirements that a domestic deployment does not have. Specifying it correctly is mostly a matter of separating the limits that look similar.
This article covers what the tier is designed for, why slot count and gateway count are different limits, how registration requirements vary by market, and how link topology and failure domain determine what happens when something breaks.
What a 128-port SIM bank for cross-border projects is designed for
Centralised card management where the gates are no longer next to the cards.
The tier exists to separate the place where subscriptions are held from the place where traffic is carried. In a domestic deployment the two are often the same rack, which is simple and adequate. In a project spanning several sites or several markets, holding the cards centrally and connecting gateways to them over a link allows subscriptions to be managed in one place while the radio equipment sits where the coverage is. The published SIMBANK128 is listed at $1,600, and the SIM pool family covers 128 slots at $1,800 and larger tiers above that.
Three project shapes make the tier appropriate. A deployment with several gateways at more than one site but a single subscription inventory. A project where the cards must be physically controlled in one location for security or commercial reasons while the radio equipment is elsewhere. And a project where subscriptions change frequently enough that remote management saves more than the link costs.
What the tier is not designed for is a small deployment that happens to have a lot of cards. Where the gateways and the cards are in the same room, the benefit of centralisation does not exist, and the additional complexity of a link between two devices is a cost with no matching return. Sizing the tier to the project rather than to the card count is the first decision, and it is the one that most often goes wrong.
| Project shape | Is the 128-slot tier appropriate | Reason |
|---|---|---|
| One site, cards and gateways co-located | Usually not | No centralisation benefit, added link complexity |
| Several gateways, one inventory | Yes | Single point of card management |
| Cards must be controlled centrally | Yes | Physical control separated from radio equipment |
| Subscriptions change frequently | Often | Remote management replaces site visits |
Slot count against gateway count as separate limits
Two numbers, and the smaller one is the constraint.
The slot count describes how many subscriptions the bank can hold. The gateway count describes how many radios can use them, and the number of gateways a bank supports is a separate limit that is not derived from the slot count. A design that assumes a 128-slot bank serves any number of gateways, or that assumes one gateway per slot, will be wrong in one direction or the other. Establishing both limits, and the relationship between them, is the first specification task.
Two further limits apply in practice. The number of subscriptions that can be active simultaneously, which may be lower than the slot count. And the registration requirement per market, which is considered in the next section and which may reduce the effective capacity of the bank in a multi-market project. Where a project spans several countries, the effective slot count is often determined by the market requirements rather than by the hardware.
The practical way to specify is to work from the traffic requirement backwards. The peak concurrency determines the number of gateways, the subscription policy determines the number of active cards per gateway, and the market requirements determine how many of those can be registered at once. The slot count is the last number to fall out of that chain rather than the first, and starting from it is how projects end up with a bank that cannot serve the gateways attached to it.
Registration requirements per market
Where a subscription may be registered is a question for the operator and the regulator.
A cross-border project inherits the rules of every market it touches, and the rules that matter most concern where a subscription may be used and for how long. Those rules are set by operators and by national authorities rather than by the equipment, and they vary considerably. What an equipment design can do is make the position of each subscription explicit and make changes manageable; it cannot make an arrangement permissible that the relevant authority does not allow.
Three design consequences follow from that. The inventory has to record, for each card, which market it is associated with and under what arrangement, so that the position is auditable rather than remembered. The configuration has to allow the set of active cards in each market to be changed without redesigning the deployment, since requirements change. And the link topology has to make it possible to keep activity in one market separate from another, which is a segmentation question rather than a routing one.
The identity that a subscription carries is standardised, and the subscriber identity is defined in ITU-T E.212 while the numbering used to reach a subscriber is defined in ITU-T E.164. Recording both against each slot is what allows an inventory to be checked against an arrangement, and it is the kind of record that a regulator or an operator may reasonably ask to see. The thresholds and permissions for a specific market, however, belong to the compliance owner rather than to this article.
Link topology and segmentation
The link between a bank and its gateways is the part of the design that is easiest to get wrong.
Three topologies are common. A direct link from the bank to a single gateway, which is simple and has no redundancy. A shared link from the bank to several gateways, which reduces cabling and introduces a shared point of failure. And a topology in which the bank connects to a network segment and the gateways are addressed across it, which is flexible and requires the segmentation to be designed deliberately rather than inherited.
Segmentation matters in a cross-border project for two reasons. The first is operational: keeping the traffic of one market separate from another makes it possible to measure and to manage each independently. The second is evidential: where activity has to be explained, a topology in which everything shares one segment produces logs that are difficult to interpret, because the traffic of several markets is interleaved. Separate segments with separate logging produce records that can be read.
The command interface used to read card and slot state is standardised, and the field definitions are described in 3GPP TS 27.005 and its ETSI TS 127 005 equivalent, which is what allows a project to read the state of the inventory from more than one system.
Latency and reliability of the link are the other considerations. The link carries the card-side interface, and while it is not a real-time path in the way a voice call is, a slow or intermittent link degrades the pool in ways that appear as message failures. Where the link crosses a wide area network, its behaviour under load should be measured rather than assumed, and the resulting figures recorded alongside the deployment baseline.
Failure domain and recovery behaviour
What fails together is a design decision, not an accident.
A single bank serving several gateways creates a large failure domain: when the bank becomes unavailable, every gateway that depends on it loses its subscriptions at once. That may be an acceptable trade against the cost and complexity of redundancy, and it should be a decision rather than a discovery. Where the failure domain is not acceptable, the options are a second bank with the cards divided between them, or a design in which each site’s gateways can serve a local set of cards if the link is lost.
The fault and configuration management functions that describe this kind of behaviour formally are set out in ITU-T M.3400, and the vocabulary is useful when recovery behaviour has to be documented for a client or an authority.
Recovery behaviour should be tested rather than assumed, because the time to recover determines how long the failure lasts. The three figures worth measuring are the time for the gateways to detect the loss of the link, the time for sessions to be re-established when it returns, and the number of messages that require manual reconciliation afterwards. A bank that recovers automatically in a minute is a different proposition from one that requires a manual step that nobody has documented.
State persistence deserves specific attention in a cross-border project. Where the mapping between slots and gateways changes after a restart, traffic in one market can begin to be carried by a subscription associated with another, which is a compliance problem as well as a technical one. Testing the mapping before and after a restart, and recording the result, is the check that catches it.
Specification checklist
The checklist covers the limits that are often treated as one number, and it is written to be completed before a supplier is asked for a quotation. Each item produces a stated figure, and the smaller of the limits is the one the design has to respect.
- Slot count and the number of gateways the bank supports, stated as separate limits.
- Number of subscriptions that can be active simultaneously.
- Effective capacity after market registration requirements are applied.
- Per-slot record of the market associated with each subscription, and the arrangement under which it is used.
- Ability to change the active set per market without redesigning the deployment.
- Link topology, with segmentation between markets and the logging that follows from it.
- Measured link behaviour under load, recorded with the baseline.
- Failure domain: what becomes unavailable together and whether that is acceptable.
- Measured recovery times and reconciliation count after a link interruption.
- Slot-to-gateway mapping compared before and after a restart.
The specification is complete when each of those items has a recorded answer rather than an assumption. In a cross-border project that matters more than in a domestic one, because the consequences of a wrong assumption are not confined to the technical deployment.
A procurement outline
The outline converts the requirements into an order of work, starting from the traffic the project has to carry rather than from the equipment. Each step produces a decision that constrains the next, and the sequence ends with the baseline the deployment is commissioned against.
- Peak concurrency, from which the number of gateways is derived.
- Subscriptions per gateway, from which the active card count is derived.
- Market requirements applied, giving the effective slot count needed.
- Topology chosen, with segmentation between markets specified.
- Failure domain accepted or redundancy designed, as a recorded decision.
- Testing completed against the protocol: mapping, link failure, recovery, thermal.
- Baseline recorded: inventory, mapping, recovery times, temperatures, firmware versions.
Derive the slot count from the requirement, not the other way round. Send your market list, peak concurrency and topology constraints to service@telarvo.com, or review the published configurations on the SIM bank page and the SMS gateway range. Telarvo publishes the SIMBANK and SIMPOOL ranges on its product pages, and the configurations referenced above come from those listings.
FAQ
What is a 128-port SIM bank designed for?
Centralised management of subscriptions where the cards and the gateways are not in the same place. It suits a project with several gateways across more than one site but a single card inventory, or one where the cards must be physically controlled in one location. It adds complexity that a co-located deployment does not benefit from, so sizing it to the project matters more than sizing it to the card count.
Is the slot count the same as the number of gateways supported?
No, they are separate limits. The slot count describes how many subscriptions the bank can hold, while the number of gateways that can use them is a different figure that is not derived from it. The number of subscriptions active at once may also be lower than the slot count, and market registration requirements can reduce effective capacity further. Confirm both limits in writing before sizing the order, because the smaller one governs.
How do cross-border projects affect SIM bank specification?
By adding requirements from every market involved, particularly about where a subscription may be used. The equipment can make the position of each subscription explicit and make changes manageable, but it cannot make an arrangement permissible that the relevant authority does not allow. Record the market associated with each slot, and keep activity in different markets segmented so the records can be read separately.
What happens when the link between a SIM bank and its gateways fails?
It depends on the design and should be measured rather than assumed. The three figures worth recording are the time for the gateways to detect the loss, the time for sessions to recover when the link returns, and the number of messages requiring manual reconciliation. Where the failure domain is unacceptable, the options are a second bank with divided cards or a design where each site can serve local cards.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “What is a 128-port SIM bank designed for?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Centralised management of subscriptions where the cards and the gateways are not in the same place. It suits a project with several gateways across more than one site but a single card inventory, or one where the cards must be physically controlled in one location. It adds complexity that a co-located deployment does not benefit from, so sizing it to the project matters more than sizing it to the card count.”
}
},
{
“@type”: “Question”,
“name”: “Is the slot count the same as the number of gateways supported?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “No, they are separate limits. The slot count describes how many subscriptions the bank can hold, while the number of gateways that can use them is a different figure that is not derived from it. The number of subscriptions active at once may also be lower than the slot count, and market registration requirements can reduce effective capacity further. Confirm both limits in writing before sizing the order, because the smaller one governs.”
}
},
{
“@type”: “Question”,
“name”: “How do cross-border projects affect SIM bank specification?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “By adding requirements from every market involved, particularly about where a subscription may be used. The equipment can make the position of each subscription explicit and make changes manageable, but it cannot make an arrangement permissible that the relevant authority does not allow. Record the market associated with each slot, and keep activity in different markets segmented so the records can be read separately.”
}
},
{
“@type”: “Question”,
“name”: “What happens when the link between a SIM bank and its gateways fails?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “It depends on the design and should be measured rather than assumed. The three figures worth recording are the time for the gateways to detect the loss, the time for sessions to recover when the link returns, and the number of messages requiring manual reconciliation. Where the failure domain is unacceptable, the options are a second bank with divided cards or a design where each site can serve local cards.”
}
}
]
}