A SIM estate grows in one of two ways: by adding slots, or by replacing the thing that holds them. Which of the two applies to a deployment decides whether growth is an incremental cost or a step change.
This article sets out what modularity means for a SIM estate, the two limits that constrain it, how to add capacity in the layer that is actually short, and how the failure domain changes as the estate grows.
What does modular SIM bank scaling mean for a SIM estate?
Capacity that can be added in units rather than replaced.
A modular estate grows by adding slots or cards to an arrangement that already exists, while a fixed chassis grows only by being replaced with a larger one.
The distinction matters because SIM estate growth is rarely smooth. A deployment that needs a hundred cards today may need two hundred next year because a market was added, and the difference between adding capacity and replacing it is the difference between a purchase and a migration. Migration carries costs that do not appear on a quotation: the work of moving cards, the risk of breaking a configuration, and the period during which the estate is being changed while traffic continues.
The identity conventions that make an estate recordable are standardised internationally, described in ITU-T E.118 for the card and in ITU-T E.212 for the network identity. A modular estate does not change those conventions; it changes how often the register has to be rebuilt.
| Growth path | What changes | What it costs beyond the hardware |
|---|---|---|
| Add slots or units | Capacity increases | Configuration of the new unit |
| Replace a chassis | Everything moves | Migration, re-testing, downtime risk |
| Add a second estate | Two estates to administer | Reconciliation between them |
| Centralise existing cards | Administration changes | Re-cabling and a link dependency |
The two limits: slots and gateways served
An estate is constrained by both, and they run out at different times.
Slot count limits how many cards can be held, while the number of gateways a bank can serve limits how many radios can use them.
Treating the two as one figure is the most common planning mistake in this area. A bank with 128 slots may support a smaller number of gateways, and the gateway limit is reached first in deployments that add radios rather than cards. Conversely, a deployment that adds cards without adding gateways reaches the slot limit while the gateway capacity sits unused. The two ceilings are separate, and the one that matters is whichever the deployment is approaching.
The practical consequence is that capacity planning has to record both figures and the current usage against each. A plan that tracks only the total number of cards in service cannot say which of the two limits will be reached first, and the answer determines whether the next purchase is a bank or a gateway. The message path that depends on the pairing is defined in ETSI TS 123 040.
Adding capacity in the layer that is constrained
Buy the layer that is short, not the layer that is convenient.
Where the slot count is the constraint, more slots solve it; where the gateway count is the constraint, more slots change nothing.
Three measurements identify which applies. The number of cards held against the slot capacity. The number of gateways served against the bank’s supported count. And the number of cards actually in service, which can be well below the number held if the estate has accumulated cards for services that no longer run. The third figure is the one that most often reveals that the estate does not need to grow at all; it needs to be cleaned.
Where both figures are close to their ceilings, the answer is usually a second bank rather than a larger one, because a second bank can be added without moving anything and increases the failure domain at the same time. Where a single larger chassis is available, the comparison is between the unit price and the migration cost, and the migration cost is usually the larger of the two in a live deployment.
Failure domain as the estate grows
A larger chassis concentrates more capacity into one failure.
Growth by replacement increases the share of the estate that stops working when the device fails, which is a cost that does not appear on the invoice.
The practical alternative is growth by addition, which keeps any single failure to the fraction of capacity that the failed unit represents. That is the same principle that applies to any redundancy decision: two smaller units cost more per slot and give a service that survives one failure, while one larger unit is cheaper and gives a service that does not. Which is appropriate follows from the availability target rather than from the unit economics.
The failure domain also changes what a fault means operationally. Where a single bank serves every gateway, a fault removes the whole estate and the response is an incident; where three banks serve it, a fault removes a third and the response is a work item. Recording the mapping between banks and gateways is what allows that distinction to be made in the first minute of an incident rather than after an investigation. Fault management concepts including thresholds and clearing conditions are organised in ITU-T M.3400.
Cost shape: steps versus increments
One curve is smooth and the other has steps in it.
Adding units produces a cost that tracks demand, while replacing a chassis produces a step that has to be justified in advance.
The step is uncomfortable for a commercial reason rather than a technical one: it requires a forecast to justify the purchase, and forecasts in this area are unreliable because estate growth follows business decisions that are themselves uncertain. An incremental path lets the deployment grow with the demand it actually experiences, at the cost of a higher price per slot and more units to manage.
Published list prices make the shape visible. The SIMBANK128 is listed at $1,600 for a 128-slot unit, and the SK SIMPOOL range runs at $1,800, $3,000 and $5,400 for the 128, 256 and 512 models as displayed on the site. Those are list prices and should be confirmed at purchase, and the useful comparison is the step between tiers against the cost of managing two smaller units, which is where the operational side of the decision sits.
Documentation that survives expansion
The register is the artefact that makes growth cheap.
An estate added to without a register becomes a set of devices whose contents nobody can describe, and the next expansion begins with an audit.
Three fields are worth maintaining from the beginning: the bank and port that holds each card, the gateway or gateway group that the bank serves, and the purpose of the card with an owner. With those, adding capacity is a matter of extending the register; without them, it is a matter of discovering what is already installed. Access-control objectives that structure who may change the allocation are organised in NIST SP 800-53 Rev. 5.
Reconciliation belongs in the same discipline. A scheduled comparison of the register against what the equipment reports finds the drift that occurs when cards are moved during maintenance, and it is the measurement that keeps the register usable as the estate grows. Record-keeping practice for the logs that support the comparison is covered in NIST SP 800-92.
A scaling outline
The outline works from the two ceilings, slots held and gateways served, to the expansion that respects both. Each step produces a decision about whether the constraint sits in the estate, the link or the chassis, which is what determines whether the next purchase adds capacity or moves it.
- Record both ceilings: slot capacity and supported gateway count.
- Record actual usage against each, including the count of cards that are held but not in service.
- Retire unused cards before buying capacity; the estate often needs cleaning rather than growing.
- Add capacity in the layer that is constrained rather than the one that is convenient.
- Prefer addition over replacement where the availability target matters.
- Record the mapping between banks and the gateways they serve.
- Maintain the register with bank, port, purpose and owner for every card.
- Reconcile the register against reported state on a schedule.
The outline produces growth that is incremental and documented rather than a series of replacements. Most estates that feel as though they need more capacity turn out to need a retirement exercise first, and the two measurements in the first two steps are what reveal it.
Two habits keep a growing estate cheap to operate. Review the register against reported state on a schedule, because the drift that occurs when cards are moved during maintenance is what makes the next expansion an audit. And record the purpose and owner of every card, because an estate whose contents are described only by quantity accumulates cards that nobody can retire, and retiring them is the cheapest capacity the deployment will ever obtain.
Where a deployment spans several sites, the same reasoning applies per site. A site whose estate is 60 per cent utilised does not need growth, while a site at 95 per cent does, and a single global utilisation figure hides the difference. Keeping the measurement per site is what allows capacity to be moved or added where it is short rather than where it is convenient.
Measure both ceilings before you buy capacity. Send your slot count, gateway count and register state to service@telarvo.com, or review the published configurations on the SIM pool range and the SIMBANK128 page. Telarvo publishes the SIMBANK and SIMPOOL ranges on its product pages, and the configurations referenced above come from those listings.
FAQ
How many SIM cards can one bank serve?
The slot count is one limit and the supported gateway count is another, and they are reached at different points. Check both against the current usage, because the constraint that binds is the one the deployment is approaching rather than the headline slot figure. Ask which of the two limits is closer to being reached, because that is the number that decides the next purchase.
Should we buy a larger bank or a second one?
Where the availability target matters, a second bank is usually better because it keeps a failure to a fraction of the estate and can be added without moving anything. A larger unit is cheaper per slot and concentrates more capacity into one failure, which is a trade rather than a saving. Record the availability target with the choice, because the concentration of capacity is a trade made against a stated requirement.
Do we need to retire unused cards before expanding?
Usually yes. Estates accumulate cards for services that have ended, and the count of cards held is often well above the count in service. Retiring them is free and may remove the apparent need for capacity altogether. Audit the register before buying capacity, because an estate that has accumulated dormant cards may already have the capacity it needs. Retiring them also restores clarity to the inventory, which makes the next capacity decision easier to justify.
What has to be documented to make expansion cheap?
The bank and port holding each card, the gateways each bank serves, and the purpose and owner of each card. With those three fields, expansion is a matter of extending the register; without them, it begins with an audit of what is already installed. Keep the register current rather than comprehensive, because an accurate short register is more useful than an unmaintained detailed one.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How many SIM cards can one bank serve?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “The slot count is one limit and the supported gateway count is another, and they are reached at different points. Check both against the current usage, because the constraint that binds is the one the deployment is approaching rather than the headline slot figure. Ask which of the two limits is closer to being reached, because that is the number that decides the next purchase.”
}
},
{
“@type”: “Question”,
“name”: “Should we buy a larger bank or a second one?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Where the availability target matters, a second bank is usually better because it keeps a failure to a fraction of the estate and can be added without moving anything. A larger unit is cheaper per slot and concentrates more capacity into one failure, which is a trade rather than a saving. Record the availability target with the choice, because the concentration of capacity is a trade made against a stated requirement.”
}
},
{
“@type”: “Question”,
“name”: “Do we need to retire unused cards before expanding?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Usually yes. Estates accumulate cards for services that have ended, and the count of cards held is often well above the count in service. Retiring them is free and may remove the apparent need for capacity altogether. Audit the register before buying capacity, because an estate that has accumulated dormant cards may already have the capacity it needs. Retiring them also restores clarity to the inventory, which makes the next capacity decision easier to justify.”
}
},
{
“@type”: “Question”,
“name”: “What has to be documented to make expansion cheap?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “The bank and port holding each card, the gateways each bank serves, and the purpose and owner of each card. With those three fields, expansion is a matter of extending the register; without them, it begins with an audit of what is already installed. Keep the register current rather than comprehensive, because an accurate short register is more useful than an unmaintained detailed one.”
}
}
]
}