Centralisation is usually justified on capital or on control, and the case that actually persuades is labour. A distributed estate consumes time in small increments that never appear in a business case: a card replaced here, a slot inspected there, a trip that takes half a day to change one item.
This guide makes that case measurable: what centralisation changes about labour per SIM, which operating costs it removes, when it is not justified, how to size the consolidation, and how to measure the result before and after rather than asserting it.
What does centralising a SIM estate actually change?
It converts a distributed estate into one managed inventory.
The change is in how much of the estate is reachable from one place, and what that makes possible.
Three things change together. The physical estate moves from several locations into one, which reduces the number of places a card can be. The logical estate becomes readable from one interface, which turns questions about the estate into queries rather than site visits. And the assignment of SIMs to gateways becomes a configuration property rather than a physical one, which means capacity can move between devices without anyone travelling.
What does not change is the radio. A centralised SIM estate still depends on gateways that have coverage, and a pool cannot compensate for a site where signal is inadequate. The layer being consolidated is the asset rather than the connectivity, and conflating the two leads to a deployment that expects consolidation to solve a coverage problem.
How does labour per SIM change?
Labour per SIM falls as the estate centralises.
The mechanism is that the fixed cost of reaching the estate is paid once rather than per location.
In a distributed estate, every physical operation carries a travel component that is independent of how many cards are involved. Replacing one card costs the same trip as replacing twenty, and the trip is usually the larger part of the task. Centralisation does not make the work faster; it removes the multiplier, so that a batch operation costs one access rather than several.
The same effect applies to diagnosis. Where the estate is readable from one interface, establishing which SIM serves a number is a query, and the query is performed by whoever is investigating rather than by whoever can reach the site. In a deployment with several sites, that change alone frequently accounts for most of the time saved, because diagnosis is more frequent than physical work.
Two costs are added and should be counted. The link between the pool and the gateways becomes part of the failure domain, and it requires monitoring. And the consolidated estate becomes a shared dependency, so a fault in the pool affects every gateway it serves rather than one. Both are real, and both are usually smaller than the labour they replace in estates above a modest size.
Which operating costs does it remove?
Fewer site visits, faster fault location, simpler growth.
Three costs fall, and each can be estimated from your own records rather than from a general claim.
| Cost | How centralisation affects it | How to estimate |
|---|---|---|
| Site access | Batch operations replace individual visits | Count physical SIM operations per month and the access cost per visit |
| Fault location | Questions become queries rather than visits | Count investigations per month and the time to establish which SIM is involved |
| Growth | Capacity moves by configuration rather than by hardware | Count reassignments per month and the effort each currently requires |
| Link dependency | Added, and requires monitoring | Estimate monitoring and recovery effort for one more production link |
The estimate that matters is the third row, because it is the one that grows with the business. An estate whose assignment changes frequently accumulates effort in proportion to how often it changes, and centralisation converts that effort from travel into configuration. Where assignments are stable, the same benefit is small.
Where the estate also has to satisfy an equipment or market framework, the ETSI standards catalogue covers the network and equipment side of the same requirement, and the messaging behaviour behind the traffic is specified by 3GPP.
When is centralisation not justified?
When site visits dominate the operating cost.
The condition sounds counter-intuitive and means something specific: where the estate already sits in one place.
Three situations argue against consolidating. Where all the gateways are in one location and the SIMs are already reachable without travel, because the pool adds a link and a shared dependency without removing any access cost. Where the estate is small enough that physical operations are infrequent, because the fixed cost of the pool is not recovered by a saving that rarely occurs. And where the requirement is frequent physical handling, because a centralised estate in a controlled location makes handling slower rather than faster.
A fourth case is worth naming because it is common: where the constraint is coverage rather than access, the answer is remote radio placement rather than a SIM pool. Both separate the estate from the radio, and only one of them addresses a signal problem.
How do you size the consolidation?
Add capacity in the layer that is constrained.
Sizing decisions go wrong when the constraint is identified by assumption rather than measurement.
Three figures determine the size. The number of SIMs the estate holds today, plus the growth you expect within the planning period. The number of gateways the pool must serve, since slot capacity and gateway capacity are separate limits. And the link capacity required if every gateway is busy simultaneously, because a path adequate for one device may behave differently with four.
The published steps run from the 128-slot configuration at $1,800.00 through 256 slots at $3,000.00 to 512 slots at $5,400.00. Choosing within that range is a question of how many numbers the traffic policy requires, and the step between tiers is small enough that sizing for the planning period rather than for today is usually the cheaper decision.
Where the constraint is the gateway count rather than the slot count, adding slots does not help. Where the constraint is the link, adding slots makes the problem worse rather than better. Writing down which limit each figure addresses is what prevents the purchase from being aimed at the wrong layer.
How do you measure the result?
Simulation of a site visit, measured before and after.
The measurement that settles the case is specific rather than general.
- Count physical SIM operations per month before consolidation, and the access cost per visit.
- Count investigations per month and the time taken to establish which SIM is involved.
- Count reassignments per month and the effort each requires today.
- Re-measure the same three figures a quarter after consolidation.
- Add the new costs, being the link and the shared dependency, rather than comparing gross savings against gross effort.
Item five is the one that keeps the comparison honest. A business case that counts the saving and omits the new dependency will be accurate about the saving and wrong about the net result, and the omission is discovered during the first link failure rather than during the review.
A second measurement belongs in the case: the interval between an assignment change and its effect. In a distributed estate that interval includes travel, and in a centralised one it does not. Where the operation changes assignments frequently in response to customer demand, the interval is part of what the customer experiences, and it is worth recording before consolidation so the improvement is demonstrable rather than assumed.
Where the estate also supports a business that is growing, the planning period matters more than the current figure. A pool sized for today’s estate is re-planned within a year in most growing operations, and the re-planning is more disruptive than the original sizing because traffic is already mapped against it. Sizing for the planning period is the cheaper decision at every tier in the published range.
Where the estate spans sites, the configurations in the SIMPOOL range share the same management model, so a later expansion follows the topology already in place rather than introducing a second one.
Where the deployment has to reference a market or equipment framework, the guidance published by ASHRAE is relevant where the estate sits in a controlled environment, the environmental test standards published by the International Electrotechnical Commission cover the equipment side, and the publications of the ITU Telecommunication Standardization Sector provide a neutral vocabulary for the numbering and interconnection terminology a specification tends to reference.
Conclusion
The case for centralising a SIM estate is labour rather than control, and it is measurable from records the operation already keeps: physical operations per month, investigations per month, and reassignments per month. Centralisation removes the travel multiplier from each, at the cost of a link that becomes part of the failure domain and an estate that becomes a shared dependency.
The changes worth measuring are the third one, because reassignment effort grows with the business, and the fifth, because a comparison that omits the new dependency is accurate about the saving and wrong about the net. Where all the gateways already sit in one accessible location, the case does not apply at all, and where the constraint is coverage rather than access, remote radio placement is the answer rather than a pool.
Measure your own labour before consolidating. Send your estate size, gateway count and physical operation frequency to service@telarvo.com, or review the published configurations on the SIMPOOL pages.
FAQ
What is the main benefit of centralising a SIM estate?
Labour rather than capital. Every physical SIM operation carries a travel component that is independent of how many cards are involved, so centralisation removes the multiplier rather than making the work faster. The same effect applies to diagnosis, which is more frequent than physical work: establishing which SIM serves a number becomes a query rather than a site visit.
Does centralisation improve signal quality?
No. The pool holds the SIMs and the radios carry the signal, so the radio still has to be placed where coverage is adequate. Where the constraint is coverage rather than access, remote radio placement is the answer rather than a SIM pool. Both separate the estate from the radio, and only one addresses a signal problem.
When is a SIM pool not worth consolidating?
Where all the gateways are already in one accessible location, because the pool adds a link and a shared dependency without removing an access cost. Also where the estate is small enough that physical operations are infrequent, and where the requirement is frequent physical handling, because a controlled location makes handling slower rather than faster.
How should the sizing decision be made?
From three figures: the SIMs the estate holds plus expected growth, the number of gateways the pool must serve, and the link capacity required if every gateway is busy at once. Slot capacity and gateway capacity are separate limits, so adding slots does not increase the number of gateways served. Write down which limit each figure addresses before ordering.