The difference between a SIM bank and a SIM pool is mostly about who owns the management layer. A bank concentrates cards; a pool presents them as an estate that can be allocated, monitored and reassigned across several gateways without anyone touching a slot.
This guide covers the server side of that design: what the pool layer adds beyond the physical chassis, how compatibility is confirmed across gateway models, how the estate scales from a single unit to several, and what remote control actually changes about daily operations.
What does a SIM pool server add beyond a chassis?
Allocation, visibility and reassignment across gateways.
The chassis holds the cards; the pool layer decides which gateway uses which card and reports what happened.
Three capabilities distinguish the pool layer. Allocation assigns SIMs to gateways according to a policy, so that capacity can be moved between gateways without a physical change. Visibility reports SIM state, registration and usage across the whole estate from one place. Reassignment moves a number from one gateway to another when traffic patterns change, which is the capability that makes a pool worth having once the estate spans more than one device.
What the pool layer does not do is remove the dependency on the radio. A SIM assigned to a gateway still needs that gateway’s radio to be registered, and a pool cannot compensate for a coverage problem at the radio. The layer manages allocation rather than connectivity, and confusing the two leads to a deployment that expects the pool to solve a radio issue.
How do you confirm compatibility with your gateways?
From the pairing documentation for the model.
Compatibility is a model-level property rather than a family-level one, and it should be confirmed in writing.
The published compatibility statement for the SK SIMPOOL range specifies the SK gateway range, and the SIMBANK128 specifies GoIP gateways, with the 512-slot configuration at $5,400.00 and the 128-slot at $1,800.00 in the pool range. Confirming that statement against your actual gateway models is the step that prevents a deployment from discovering an incompatibility after the hardware arrives.
Three questions settle compatibility quickly. Which gateway models does the pool support for the allocation features you need, not merely for physical connection? Which firmware versions are supported on both sides? And what is the supported ratio of gateways to pool, since a pool that supports one gateway may not support four?
Where a deployment mixes families, the practical approach is to confirm each pairing separately and to document which gateways have been validated rather than assuming uniformity across the estate.
How does the estate scale from one unit to several?
Add capacity in the layer that is actually constrained.
Scaling decisions go wrong when the constraint is identified by assumption rather than measurement.
| Configuration | Slots | List price (USD) | Typical step |
|---|---|---|---|
| SK SIMPOOL 128 | 128 | $1,800.00 | First estate, one or two gateways |
| SK SIMPOOL 256 | 256 | $3,000.00 | Additional gateways without new slot hardware per device |
| SK SIMPOOL 512 | 512 | $5,400.00 | Consolidated estate across several gateways |
Two constraints bind as the estate grows, and they are different. The number of slots limits how many numbers can be held. The number of gateways the pool supports limits how many radios can be served. Adding slots addresses the first and not the second, which is why an expansion plan should state which constraint it is addressing.
A third consideration belongs in the plan: the link between the pool and the gateways has a capacity of its own. A link sized for one gateway may behave differently with four, and the symptom of an undersized link appears as intermittent SIM behaviour rather than as a clear capacity message. Sizing the link for the intended estate rather than the current one avoids a diagnosis that is expensive because it looks like a radio fault.
What does remote control change about operations?
It removes the site visit from routine SIM work.
Remote control converts a physical task into a configuration change, which changes both the cost and the failure mode.
Four routine operations become remote. Assigning a SIM to a different gateway is a policy change. Taking a number out of service is an administrative action. Redistributing capacity when traffic moves between customers is a reassignment rather than a visit. And investigating a fault begins from reported state rather than from a physical inspection.
The failure mode changes alongside. A remote operation that goes wrong is not visible in the same way as a person standing at the rack, so the console’s own reporting becomes the primary control. Two practices reduce the risk: make changes in defined groups rather than across the estate, and confirm the outcome by exercising traffic on the affected SIM rather than by reading a status field, because a status field can report the intended state while the traffic behaves differently.
How should allocation policy be designed?
Allocate by purpose, not by availability.
A pool that assigns any free SIM to any gateway optimises utilisation and destroys comprehensibility.
A workable policy defines groups by purpose — a group for a customer, a market, or a traffic type — and assigns within the group. The result is an estate whose structure reflects the business rather than the hardware, which makes both expansion and investigation easier.
Reserve capacity deliberately rather than incidentally. A pool that runs at full allocation has no room to reassign when a number is withdrawn or a gateway is added, and the resulting scramble produces exactly the ad hoc changes the policy was meant to prevent. Keeping a defined share unallocated is a cost with a purpose.
Record the policy alongside the register. When the person who designed the allocation leaves, the policy is the artefact that keeps the estate operating as intended rather than drifting into whatever the software defaults to.
What should the acceptance test cover?
Confirm allocation, reassignment and reporting.
The pool layer’s value is in operations that a chassis alone cannot perform, so those are the operations to test.
- Allocation. Assign SIMs to each gateway according to the policy and confirm each gateway sees what it should.
- Reassignment. Move a SIM from one gateway to another and confirm traffic follows the change.
- Visibility. Confirm the console reports state for every SIM across every gateway from one place.
- Link stability under load. Run traffic on all gateways simultaneously and confirm no SIM becomes intermittently unavailable.
- Failover. Withdraw a SIM or disturb the link and confirm the estate recovers as designed rather than requiring intervention.
Item four is the one that catches an undersized link, and it is the test most often skipped because it requires the whole estate to be busy at once. Running it before go-live converts a future intermittent fault into a planned change.
Allocation policy should also define what happens when a gateway is withdrawn from service. Where SIMs are assigned by availability, removing a gateway leaves its allocation in an ambiguous state, and the next operator to touch the estate cannot tell whether those numbers are free or reserved. Recording the allocation against a purpose rather than against a device makes the consequence of removal explicit, and it is the difference between a planned withdrawal and an accidental data loss.
A second operational consideration is reporting. Where the pool layer reports state per SIM and per gateway, the first question in any incident — whether the problem affects one number, one gateway or the whole estate — can be answered from one screen rather than by elimination. Where it reports only per gateway, a fault affecting a single number looks identical to a fault affecting the estate until someone investigates.
Where the estate carries commercial traffic, the operational expectations for consent and identification are described by M3AAWG, the numbering follows ITU Recommendation E.164, the messaging behaviour is specified by 3GPP, and the equipment side is covered by the ETSI standards catalogue.
Whichever configuration is chosen, record the supported gateway count alongside the slot count in the asset register, because the two limits are the ones that determine when the next expansion is due.
Where the estate has to satisfy an equipment or market framework, the ETSI standards catalogue covers the network and equipment side of the same requirement.
Conclusion
A SIM pool server adds allocation, visibility and reassignment to the physical chassis, and those three capabilities are what justify the layer once an estate spans more than one gateway. Compatibility is confirmed at model level against the pairing documentation rather than assumed from the family, and scaling decisions should name which constraint they address, because slot capacity and gateway capacity are different limits and the link between pool and radios has a third.
Allocation policy is a design artefact rather than a setting. Defining groups by purpose, reserving some capacity deliberately, and recording the policy alongside the SIM register keeps a large estate comprehensible as people and traffic change. The published range steps from the SK SIMPOOL 128 at $1,800.00 through the 256-slot configuration at $3,000.00 to the 512-slot at $5,400.00, with the SIMBANK128 at $1,600.00 covering deployments whose requirement is a bank for GoIP gateways rather than a pool for the SK range.
Confirm gateway compatibility at model level before ordering. Send your gateway models, firmware versions and target estate size to service@telarvo.com, or review the published configurations on the SIMPOOL pages.
FAQ
What is the difference between a SIM bank and a SIM pool?
A bank concentrates cards in a chassis and presents them to gateways; a pool adds an allocation and management layer on top, so capacity can be assigned, monitored and reassigned across several gateways without physical intervention. The distinction matters once an estate spans more than one device, because that is when allocation becomes an operational task.
How many gateways can one SIM pool serve?
That is a model-level property rather than a family property, so confirm it against the pairing documentation for the exact pool and gateway models you intend to use. Slot capacity and gateway capacity are separate limits, and adding slots does not increase the number of gateways served. Record the validated pairings rather than assuming uniformity across a mixed estate.
Can SIMs be moved between gateways without a site visit?
Yes where the pool layer supports reassignment, which is one of its principal advantages. The operation becomes a policy change rather than a physical task. Because a remote change is not visible the way a person at the rack is, make changes in defined groups and confirm the outcome by exercising traffic on the affected SIM rather than by reading a status field.
How much capacity should be left unallocated?
Enough to reassign when a number is withdrawn, a gateway is added, or a customer’s traffic moves. A pool running at full allocation has no room for any of those events, and the resulting changes are made under pressure and without the policy the estate was designed around. Treat reserved capacity as a deliberate cost with a defined purpose.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “What is the difference between a SIM bank and a SIM pool?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “A bank concentrates cards in a chassis and presents them to gateways; a pool adds an allocation and management layer on top, so capacity can be assigned, monitored and reassigned across several gateways without physical intervention. The distinction matters once an estate spans more than one device, because that is when allocation becomes an operational task.”
}
},
{
“@type”: “Question”,
“name”: “How many gateways can one SIM pool serve?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “That is a model-level property rather than a family property, so confirm it against the pairing documentation for the exact pool and gateway models you intend to use. Slot capacity and gateway capacity are separate limits, and adding slots does not increase the number of gateways served. Record the validated pairings rather than assuming uniformity across a mixed estate.”
}
},
{
“@type”: “Question”,
“name”: “Can SIMs be moved between gateways without a site visit?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Yes where the pool layer supports reassignment, which is one of its principal advantages. The operation becomes a policy change rather than a physical task. Because a remote change is not visible the way a person at the rack is, make changes in defined groups and confirm the outcome by exercising traffic on the affected SIM rather than by reading a status field.”
}
},
{
“@type”: “Question”,
“name”: “How much capacity should be left unallocated?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Enough to reassign when a number is withdrawn, a gateway is added, or a customer’s traffic moves. A pool running at full allocation has no room for any of those events, and the resulting changes are made under pressure and without the policy the estate was designed around. Treat reserved capacity as a deliberate cost with a defined purpose.”
}
}
]
}