One bank serving several gateways is where the SIM estate stops being an accessory and becomes shared infrastructure. The decision that determines how operable it is comes early and is rarely revisited: whether slots are assigned in blocks or drawn from a common pool.
This guide covers that decision and its consequences: how block assignment protects an estate, when a shared pool is the better answer, how to size the link between the bank and the gateways, how to locate a fault when several devices depend on one bank, and what to document so the arrangement survives a change of staff.
How should slots be assigned across gateways?
In blocks, so the mapping stays comprehensible.
The assignment scheme determines how easy the estate is to reason about under pressure.
Block assignment gives each gateway a contiguous range of slots. The mapping is documented once, and a question about which gateway serves a given number can be answered by reading the range rather than by querying a system. The trade is utilisation: a gateway that underuses its block leaves capacity idle that another gateway cannot reach.
Shared allocation draws from a common pool as needs arise, which uses capacity better and makes the mapping a runtime property rather than a documented one. Every question about the estate then becomes a database query, and the query depends on the allocation software having recorded the state correctly.
Three cases favour blocks. Where each gateway serves a distinct customer or business line, because the boundary is then also a commercial boundary. Where the deployment has to be diagnosable by someone who did not build it, which is most deployments. And where the estate is modest enough that the utilisation difference is immaterial. Shared allocation favours deployments with many gateways and variable load, where the contribution of any one device changes frequently.
What does block assignment protect?
It keeps one gateway’s fault from touching another’s slots.
The protection is operational rather than technical, and it matters during an incident.
Where a fault appears in one gateway, block assignment bounds the investigation. The affected range is known, the unaffected ranges can be confirmed quickly, and the question of whether the problem is the gateway or the bank can be answered by looking at whether other blocks are affected. Under shared allocation the same fault requires establishing which slots were allocated to which device at the time, which is a reconstruction task rather than a lookup.
A second protection is change management. A configuration change to one gateway affects its block and not the estate, which means a change can be made and verified without a maintenance window. Under shared allocation a change to allocation policy is a change to the whole estate, because the policy is the mapping.
A third is customer-facing. Where gateways serve different customers, block assignment provides a natural separation that can be described in a contract and demonstrated in a review, whereas a shared pool requires the separation to be demonstrated by the software rather than by the topology.
When is a shared pool better?
When several gateways underuse their blocks.
The condition is specific and measurable rather than a matter of preference.
Shared allocation earns its complexity where the utilisation difference is material. That happens in three situations: where many gateways each carry variable load and no single device needs a fixed range; where the estate is large enough that idle blocks represent significant capital; and where the allocation software is mature enough that its recorded state is trusted, since a shared pool depends on that record being correct.
The measurable test is straightforward. Measure the utilisation of each block over a representative period. Where several blocks sit well below their capacity while others are constrained, the block scheme is costing something. Where utilisation is broadly even, the difference is immaterial and blocks remain the simpler answer.
A middle arrangement is worth knowing because it suits many deployments: blocks for each gateway’s permanent numbers, plus a shared range for overflow. It preserves the comprehensibility of blocks for the estate’s stable part while allowing capacity to move for the part that varies. The SIMPOOL range from 128 slots at $1,800.00 to 512 slots at $5,400.00 provides the capacity steps within which either arrangement can be built.
How do you size the link between bank and gateways?
Short, stable and segmented.
The link carries SIM signalling rather than user traffic, so throughput is not the constraint and stability is.
Three requirements apply. The link should be stable in latency, because SIM operations are sensitive to stalls and a link that occasionally pauses produces timeouts that look like SIM faults. It should be segmented from general traffic, so that a busy network does not affect SIM operations. And it should be sized for the estate it will serve rather than the one it serves today, because the symptom of an undersized link appears as intermittent SIM behaviour rather than as a clear capacity message.
A wired connection on the same switch is the simplest arrangement and the one to prefer wherever the elements are in the same building. Where they are not, a dedicated path with a defined route is preferable to sharing a general-purpose network, because the failure modes of the second are harder to reason about when something goes wrong.
The sizing question is not how much bandwidth the estate needs but how many gateways the link must serve simultaneously. A link adequate for one gateway may behave differently with four, and the difference is invisible until all four are busy at once. Testing that condition at commissioning is the only reliable way to establish it.
How do you locate a fault across several gateways?
Move the SIM and see whether the fault follows.
A fixed diagnostic order prevents the substitution approach that consumes parts and time.
- Is the fault in one block or several? One block points at the gateway or its slots; several point at the bank or the link.
- Is the SIM visible to its gateway? Visibility without registration points at the SIM or the operator rather than at the pairing.
- Does the fault follow the SIM or the slot? Moving the card to another slot separates the two in one step.
- Does the fault follow the gateway? Moving a known-good SIM to the affected gateway answers whether the device or the bank is involved.
- Does the fault clear when the link is restarted? A fault that clears on restart indicates link stability rather than a hardware failure.
Step one is the one that makes the rest efficient, because it narrows the investigation before any physical work. Step three is the most informative single test, and it takes minutes rather than a spare device.
What should be documented?
Which gateway owns which slots, and why.
The document is what allows the arrangement to be operated by someone who did not design it.
| Item | What to record |
|---|---|
| Assignment scheme | Block or shared, and the reason for the choice |
| Block map | Which gateway owns which slot range |
| Purpose per block | The customer, line or workload each block serves |
| Link topology | The path between bank and gateways, and its segmentation |
| Failure behaviour | What the gateways report when the link is unavailable |
| Reconciliation | The interval at which the register is compared against reported state |
The reconciliation row is the one that keeps the document true rather than merely written. A register drifts whenever a card is replaced in an emergency, and the drift is invisible until a fault is investigated using it.
What belongs in the acceptance test?
Pairing accuracy across every gateway.
The test that matters is the one that catches silent defects rather than the one that confirms the estate works.
- Block boundaries. Confirm each gateway sees the slots its block assigns and no others.
- Pairing accuracy. Exercise one slot per block and confirm the number presented matches the register rather than the physical order.
- Isolation. Remove one gateway from service and confirm the other blocks are unaffected.
- Link under load. Run traffic on every gateway simultaneously and confirm no SIM becomes intermittently unavailable.
- Recovery. Disturb the link and confirm both elements recover without intervention.
Items one and two catch the defects that produce traffic from an unexpected number without any error at all. Item four catches an undersized link, and it is the test most often skipped because it requires every gateway to be busy at once.
Where the deployment is expected to add gateways, record the block count that remains available alongside the slot count. A bank whose slots are fully allocated in blocks has no room to serve a new device without re-planning the assignment, and the re-planning is more disruptive than the original allocation because existing traffic is already mapped against it.
Where the estate carries commercial traffic, the consent and identification expectations described by M3AAWG and, for the North American market, by the CTIA apply to the message rather than to the device. The numbering that recipients see follows the ITU Recommendation E.164, the messaging behaviour is specified by 3GPP, and the equipment side is covered by the ETSI standards catalogue.
Conclusion
A bank serving several gateways is a shared infrastructure decision, and the choice between block assignment and a shared pool determines how diagnosable the estate is. Blocks bound every investigation and make configuration changes local, at the cost of some stranded capacity; a shared pool uses capacity better and makes every question a database query. The measurable test is utilisation per block over a representative period rather than a general preference.
The link between bank and gateways should be short, stable and segmented, and it should be sized for the estate it will serve rather than the one it serves today, because an undersized link presents as intermittent SIM behaviour rather than as a capacity message. Documenting which gateway owns which slots, and reconciling that record against reported state, is what keeps the arrangement operable by whoever inherits it.
Decide the assignment scheme before the estate grows. Send your gateway count, slot requirement and access constraints to service@telarvo.com, or review the published configurations on the SIMPOOL pages.
FAQ
Should each gateway have its own block of slots?
Blocks trade some utilisation for comprehensibility and isolation. They make the mapping readable, bound an investigation to the affected range, and let a configuration change be verified without a maintenance window. A shared pool uses capacity better where several gateways underuse fixed ranges. The measurable test is utilisation per block over a representative period.
How much bandwidth does the link to the SIM bank need?
Throughput is not the constraint, because the link carries SIM signalling rather than user traffic. Stability and segmentation are. The relevant question is how many gateways the link must serve simultaneously, since a path adequate for one gateway may behave differently with four, and the symptom of an undersized link is intermittent SIM behaviour rather than a clear capacity message.
How do I find which gateway is causing a fault?
Start by establishing whether the fault appears in one block or several. One block points at the gateway or its slots; several point at the bank or the link. Then move the SIM to another slot to see whether the fault follows the card or the slot, and move a known-good SIM to the affected gateway to confirm whether the device is involved.
What is the most common silent defect in a shared bank deployment?
A pairing error, where bank slots map to gateway channels in an order that differs from the documentation. Traffic still flows, from an unexpected number, and nothing reports an error. Exercising one slot per block against the register, rather than confirming that the estate passes traffic, is the test that catches it.