SIM rotation is often described as a feature and rarely described as a policy. The feature decides which card sends the next message; the policy decides when, how often, and what happens to the card afterwards, and it is the policy that determines whether the pool behaves predictably.
This article compares rotation on the four parameters that define any policy — trigger, granularity, cooldown and session awareness — and sets out the failure mode each choice carries, so the decision can be made deliberately rather than inherited from a default setting.
What are the four parameters that define a SIM rotation logic comparison?
Trigger, granularity, cooldown and session awareness.
Every rotation policy, however it is described, resolves those four questions, and two policies that look similar in a management interface can answer them differently.
The trigger is what causes a rotation to happen: a count, a time interval, an error condition or a manual action. Granularity describes what rotates: one card, a group, or the whole estate. Cooldown is the minimum rest a card takes before it is used again. Session awareness determines whether rotation respects a conversation or a workflow that spans several messages, or resets it mid-way. Changing any one of those changes the behaviour of the pool, which is why comparing products by their rotation feature alone produces two deployments that cannot be compared.
Two constraints sit outside the policy and bound all four parameters. The first is the operator’s terms, which determine what a subscription may be used for; the second is the delivery record, which determines whether the policy is having the intended effect. A rotation policy that cannot be evaluated against a per-number delivery figure is a policy nobody can tune.
| Parameter | Options | What it changes |
|---|---|---|
| Trigger | Count, interval, error, manual | How predictable the load on each number is |
| Granularity | Single card, group, estate | How quickly a bad card is isolated |
| Cooldown | None, fixed, adaptive | Whether a card is reused before it has rested |
| Session awareness | Stateless, conversation-aware | Whether multi-message flows stay coherent |
Which trigger should start a rotation?
An interval trigger for predictability; a count for control.
Interval-based rotation spreads load evenly in time and is easy to explain, while count-based rotation gives an exact ceiling per card but produces bursts when several cards reach their count together.
Interval triggers are the safer default because their effect is smooth and their failure mode is mild: if the interval is wrong, load is distributed unevenly rather than concentrated. Count triggers are more precise but require staggering, since a pool that rotates every card at the same count will oscillate between two states rather than rotate smoothly. Error-based triggers are useful as an addition rather than as a policy, because they react after something has gone wrong.
Manual triggers are not a policy at all, but they are sometimes what a deployment actually uses. Where rotation depends on someone noticing a problem, the pool’s behaviour is a function of attention, and the resulting load distribution is invisible until a per-number report is produced. Recording which trigger is in force, and whether it matches the documented intent, is the first step in any review.
Granularity: single SIM versus estate
Fine granularity isolates faults; coarse granularity hides them.
Rotating a single card at a time allows a failing number to be removed without disturbing the pool, while estate-level rotation distributes load evenly and makes individual problems harder to see.
The trade is between smoothness and isolation. A policy that rotates the whole estate at once spreads traffic perfectly evenly and means that a card which becomes ineffective is still rotated in, because the policy does not know it is failing. A policy that rotates individual cards can remove one from the pool and continue, at the cost of a more complex allocation decision and a slightly less even distribution.
The practical answer for most deployments is a middle position: rotate at group level for normal operation, and allow individual cards to be taken out of service for a defined period when their delivery ratio falls. That arrangement needs the per-card delivery figure the earlier section described, which is why reporting and rotation are designed together rather than sequentially.
One further check belongs in the review: confirm that the policy is actually being applied by the platform rather than merely configured. A rotation setting that the scheduler ignores, or a cooldown that the allocation logic does not enforce, produces a policy on paper and a different behaviour in service, and the per-number report is where the two become visibly different.
Why is cooldown the parameter people forget?
Because its absence is invisible until the pool is audited.
Cooldown is the minimum interval before a card is used again, and a policy without one can rotate through a pool so quickly that some cards are reused within minutes.
The effect is not a failure; it is a distribution problem. A pool of twenty cards with no cooldown and a high message rate will reuse the earliest card in the sequence long before the last card has been used once, and the resulting load per number is far less even than the pool size suggests. The deployment then behaves like a smaller pool with the costs of a larger one, which is why cooldown belongs in the policy rather than in tuning.
Adaptive cooldown is the more useful form where the platform supports it: the rest period for a card that is delivering reliably can be shorter than for a card whose delivery ratio has dipped. That requires the same per-card outcome data as the granularity decision, and it is the point at which rotation stops being a setting and becomes a control loop.
Session awareness for stateful workloads
Rotation must not break a conversation.
Where a workflow expects several messages to come from the same number, rotating between them changes the sender identity mid-conversation, which is visible to the recipient and confusing for any reply routing.
Two patterns handle this. The first is to pin a session to a number for its duration, which is simple to reason about and requires the allocation logic to hold state. The second is to route replies by an identifier carried in the message rather than by the sender number, which removes the dependency on the number but requires the inbound path to support it. The message flow that both patterns sit on is defined in ETSI TS 123 040 and 3GPP TS 23.040, and the subscription states that a pinned number must maintain are defined in 3GPP TS 24.301.
Session awareness also affects how a rotation appears to the operator. A policy that ignores sessions produces cleaner per-number statistics and worse recipient experiences, so the two objectives need to be weighed rather than maximised. Where the deployment is notification-only, session awareness matters little; where replies are expected, it decides the design.
What a sound policy documents
Write the four parameters down, with the reasoning.
A policy that exists only as a configuration is a policy that will be changed without discussion, and the next person to review the deployment will have no basis for judging whether the change was wise.
The document should state the trigger and its value, the granularity, the cooldown and whether sessions are pinned. It should also state the ceiling per number, which is the constraint the rotation exists to respect, and the escalation rule for a card whose delivery ratio falls. Where the deployment operates in several markets, the parameters belong per market, because the operator terms and the traffic profile differ.
Keep the policy with the deployment record rather than in a project file. The events that invalidate it are operational — a new market, a changed tariff, a campaign with a different profile — and none of them will be connected to a document nobody looks at. Record-keeping practice for the logs that evaluate the policy is covered in NIST SP 800-92.
A comparison table
The table compares rotation policies on the four parameters that define them, with the consequence of each choice. It is written to be filled in for a specific deployment rather than as a general ranking, because the ordering of the parameters changes with the workload and the market.
- Trigger: what starts a rotation, and is it staggered? An unstaggered count trigger is a defect.
- Granularity: can a single card be removed from service without disturbing the pool?
- Cooldown: is there a minimum rest period, and is it enforced by the platform?
- Session awareness: are multi-message workflows pinned to a number, or routed by identifier?
- Ceiling: what is the maximum per-number volume, and is it enforced rather than advisory?
- Evaluation: which per-number figure is used to judge whether the policy is working?
The comparison is between policies rather than between products, which is what makes it useful. Two deployments running identical hardware can behave completely differently because their rotation policies answer the four parameters differently, and the table is the shortest way to see that. The identity conventions that make per-number reporting possible are described in ITU-T E.164 for numbers and ITU-T E.118 for cards, and reporting is only comparable when both are recorded consistently.
Two habits keep a policy honest once it is in place. First, review it against the per-number report on a schedule rather than after an incident, because the drift is gradual and the report shows it before the traffic does. Second, record every change to a parameter with its reason, so that a later reviewer can see whether the change was a deliberate adjustment or an accident of tuning.
Document the four parameters before tuning them. Send your pool size, current trigger and per-number ceiling to service@telarvo.com, or review the published configurations on the SIM pool range and the SMS gateway solution page. Telarvo publishes the SIMBANK and SIMPOOL ranges on its product pages, and the configurations referenced above come from those listings.
FAQ
How often should SIMs rotate?
Often enough that no single number carries more than its ceiling, and rarely enough that each card gets a rest. A workable starting point is an interval trigger with a cooldown at least as long as the interval, adjusted once per-number delivery figures show which cards are working hardest. The figures to watch are delivery ratio and attempts per number rather than the rotation count itself.
Is count-based rotation better than interval-based?
It is more precise and harder to operate, because unstaggered counts produce bursts. Count-based rotation needs staggering to avoid rotating the whole pool at once, and it needs a cooldown or the same cards reappear early. Interval rotation is the safer default where the platform supports both. Whichever is chosen, write down the cooldown rule because that is where the policy usually fails.
What happens if rotation has no cooldown?
The pool is used unevenly. A fast sequence reuses the first cards long before the last ones have been used once, so the effective pool is smaller than it appears and the load per number is higher than the policy intends. Adding a cooldown is usually the single change that makes a rotation policy behave as described. Compare the attempts per card across the pool to confirm it worked.
Should rotation change the number during a conversation?
Not if replies are expected. Rotating mid-conversation changes the sender identity, which the recipient sees and which complicates reply routing. Pin the session to a number, or route replies by an identifier carried in the message, and decide which of the two before the policy is written. A reply that arrives on a number which is resting is a message the application may never see.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How often should SIMs rotate?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Often enough that no single number carries more than its ceiling, and rarely enough that each card gets a rest. A workable starting point is an interval trigger with a cooldown at least as long as the interval, adjusted once per-number delivery figures show which cards are working hardest. The figures to watch are delivery ratio and attempts per number rather than the rotation count itself.”
}
},
{
“@type”: “Question”,
“name”: “Is count-based rotation better than interval-based?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “It is more precise and harder to operate, because unstaggered counts produce bursts. Count-based rotation needs staggering to avoid rotating the whole pool at once, and it needs a cooldown or the same cards reappear early. Interval rotation is the safer default where the platform supports both. Whichever is chosen, write down the cooldown rule because that is where the policy usually fails.”
}
},
{
“@type”: “Question”,
“name”: “What happens if rotation has no cooldown?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “The pool is used unevenly. A fast sequence reuses the first cards long before the last ones have been used once, so the effective pool is smaller than it appears and the load per number is higher than the policy intends. Adding a cooldown is usually the single change that makes a rotation policy behave as described. Compare the attempts per card across the pool to confirm it worked.”
}
},
{
“@type”: “Question”,
“name”: “Should rotation change the number during a conversation?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Not if replies are expected. Rotating mid-conversation changes the sender identity, which the recipient sees and which complicates reply routing. Pin the session to a number, or route replies by an identifier carried in the message, and decide which of the two before the policy is written. A reply that arrives on a number which is resting is a message the application may never see.”
}
}
]
}