Rotation is easy to describe and difficult to configure well, because the parameter that matters is not how often the address changes but whether it changes at the moment it would break something. A workload that authenticates and holds state is destroyed by rotation; a workload that treats every request independently is not.
This guide covers the operational side of cellular IP rotation: the four parameters that define a policy, how to choose thresholds, how rotation interacts with long-lived sessions, what to do when a rotation fails, and how a built appliance compares with a self-assembled one over three years.
What are the four parameters of a rotation policy?
Trigger, granularity, cooldown, and session awareness.
A policy is defined by these four, and a configuration that omits any of them produces behaviour nobody chose.
Trigger is what causes a change: elapsed time, completed requests, observed failures, or a manual action. Granularity is what changes: an individual address or the whole estate. Cooldown is how soon another change may follow, which prevents rapid cycling when a failure trigger is active. Session awareness is whether the change may occur while a connection is open, which is the parameter that decides whether stateful workloads survive.
The combination that causes the most damage is a failure trigger with estate-level granularity and no cooldown. When a network-side problem produces many failures at once, that policy rotates every address simultaneously, so a transient fault becomes a full outage. Adding a cooldown and restricting granularity to a single address converts the same event into a bounded change.
Write the policy down as these four parameters rather than as a description. A configuration expressed as “rotate regularly” cannot be audited, and the audit is what matters when a workload breaks and nobody can explain why.
How should rotation thresholds be chosen?
From the workload’s tolerance, not from a general default.
The threshold is a business parameter expressed in technical terms.
Three questions produce the numbers. How long may a single address be used before the workload’s own requirements make a change desirable? What failure rate indicates that an address should be abandoned? And how long must an address remain stable when a session is open? The answers differ per workload, and a single device frequently serves several, so the policy should be expressed per port group rather than globally.
Two practical constraints bound the answer. Aggressive rotation generates churn, which reduces the useful life of a session and can itself produce failures. And rotation changes the address, not the network: an address reassigned by the operator may be indistinguishable in character from the previous one, so rotation is not a remedy for a network-level problem.
Where the trigger is failure-based, pair it with a cooldown and a cap on how many addresses may change within a window. That pairing is what prevents a systemic fault from becoming a systemic change, and it is the single most useful defensive configuration on a rotation-capable device.
How does rotation interact with long-lived sessions?
It breaks them, unless the session is pinned to an address.
Any workload that authenticates, holds a cart, or maintains a websocket depends on address stability for the duration of the interaction.
The mechanism is straightforward: when the address changes mid-session, the far end sees a different source and treats the connection as a new or untrusted one. The result is an authentication challenge, a lost cart, or a dropped connection, depending on the application. None of those is reported as a rotation event, which is why rotation is often blamed on the network rather than recognised as the cause.
Three mitigations exist. Pin stateful workloads to a dedicated port that is excluded from rotation. Configure the device so rotation is deferred while a connection is open, which requires the device to be aware of session state. Or redesign the workload to tolerate address change, which is usually outside the control of the team operating the gateway.
The practical approach is to classify workloads before configuring rotation, because the classification determines the port group each workload belongs to. A workload that cannot tolerate change belongs on pinning; one that can belongs in the rotating group.
What should happen when a rotation fails?
Fall back to a known-good address and record the event.
A failed rotation is a state change that did not complete, and the deployment needs a defined response rather than a retry loop.
Three responses are defensible. Return the port to the address it had before, which is the safest option where the previous address was working. Move the workload to another port in the same group, which preserves service where the group has spare capacity. Or hold the workload and raise an alert, which is appropriate where neither of the first two is available and a short interruption is preferable to an unknown state.
Whichever is chosen, the event should be recorded with enough detail to reconstruct it: the port, the time, the previous address, the attempted change, and the outcome. Without that record, an incident review has no evidence beyond the symptom, and the same fault recurs.
Two failure modes are worth naming. A retry loop with no backoff can leave a port cycling between addresses indefinitely, which produces service instability rather than a clean failure. And a fallback that silently uses a different address than documented makes every subsequent investigation harder, because the recorded state no longer matches the operation.
How does a built appliance compare with a DIY build?
The capital gap is smaller than the operating gap.
Self-assembled SIM hardware is well documented, and the comparison belongs on three-year cost rather than purchase price.
| Cost line | Built appliance | Self-assembled build |
|---|---|---|
| Capital | List price, from $410.00 for four ports | Components, plus spares and enclosures |
| Assembly and commissioning | Configuration only | Engineering time to build, test and document |
| Ongoing reliability | Vendor-supported configuration | Depends on assembly quality and thermal design |
| Fault diagnosis | Single point of support | Internal, across components from several suppliers |
| Replacement | Same model, same configuration | Repeat the build, or hold a spare |
The line that changes decisions is fault diagnosis. A self-assembled deployment distributes support across several component suppliers, and the first fault that spans two of them produces a diagnosis problem rather than a repair. Where the team already operates hardware and has the documentation discipline to support it, that cost is manageable. Where it does not, the appliance’s single support point usually outweighs the capital difference.
The published range starts at the four-port configuration at $410.00, which is a low enough entry point that a pilot build comparison is inexpensive to run. Comparing the two on your own workload for a month produces a better answer than any table.
What should be verified before acceptance?
Rotation behaviour, session protection, fallback.
These are the three properties that determine whether a rotation deployment is operable.
- Trigger accuracy. Exercise each configured trigger and confirm it fires when documented.
- Granularity. Confirm a change affects the intended scope and not a larger one.
- Session protection. Hold a connection open through a rotation window and confirm the documented behaviour.
- Cooldown enforcement. Induce repeated failures and confirm the cooldown limits the rate of change.
- Failure handling. Force a rotation to fail and confirm the fallback behaves as designed rather than cycling.
- Record completeness. From the device record alone, reconstruct one rotation event end to end.
Items three and four are the ones that catch a policy designed on paper and unworkable in practice. A rotation configuration that cannot survive an open connection will break stateful workloads the first time it fires, and a failure trigger without a working cooldown will convert a network problem into an estate-wide change.
Rotation and address health belong together in the operating model. An address that has been used heavily is not equivalent to one that has been idle, and a policy that rotates on a timer treats them identically. Where the device exposes per-address usage, that history can inform when an address should be rested rather than merely changed, which is a different intervention from rotation and often a more useful one.
Documentation matters more in rotation deployments than in static ones, because the state changes. A record that captures the current address, the policy applied to it and the last rotation event is what allows a support conversation to begin from facts. Without it, the first question in any investigation — which address was in use at the time — cannot be answered from the device.
Where the deployment supports commercial traffic, the operational expectations are described by M3AAWG, address translation behaviour on the path is described in RFC 1918 and RFC 3022, and the equipment side is covered by the ETSI standards catalogue. Market-specific obligations are described by organisations such as the CTIA.
Conclusion
Rotation is defined by four parameters, and a policy that omits any of them produces behaviour nobody chose. The dangerous combination is a failure trigger with estate-level granularity and no cooldown, which turns a transient network fault into a simultaneous change across every address. Session awareness is the parameter that decides whether stateful workloads survive, and it should be resolved by classification rather than by configuring the most permissive setting.
The build-versus-buy comparison belongs on three-year cost and on fault diagnosis rather than on purchase price, because the operating difference between a supported configuration and an assembled one appears in the first fault that spans two suppliers. The published range starts at four ports at $410.00, which makes a pilot comparison inexpensive, and the sixteen-port configuration at $1,380.00 allows stateful workloads to be pinned to ports excluded from rotation.
Classify workloads before configuring rotation. Send your workload types, session requirements and address count to service@telarvo.com, or review the published models on the proxy gateway solution pages.
FAQ
How often should a mobile IP rotate?
The interval follows from the workload’s tolerance rather than from a general default. Ask how long a single address may be used before the workload requires a change, and how long an address must remain stable while a session is open. Where the device serves several workloads with different answers, express the policy per port group rather than applying one value across the estate.
Why does rotation break logins?
Because the far end sees a different source address mid-session and treats it as a new or untrusted connection. Any workload that authenticates, holds a cart or maintains a persistent connection depends on address stability for the duration of that interaction. The remedy is to classify workloads and pin the stateful ones to ports excluded from rotation.
What recording should a proxy deployment keep?
Enough to attribute activity to an address, a port, a user and a time, and enough to reconstruct a rotation event including the previous address, the attempted change and the outcome. Without that record an incident review has only the symptom to work from, and the same fault tends to recur because nothing establishes what actually happened.
Is a DIY proxy build cheaper than an appliance?
The capital cost usually is, and the three-year cost often is not. A self-assembled deployment adds engineering time for assembly, testing and documentation, distributes fault diagnosis across several component suppliers, and makes replacement a rebuild rather than a reorder. The published range starts at four ports at $410.00, so a pilot comparison is inexpensive to run on your own workload.