Definition
Carrier Fallback (Carrier Switching) refers to automatically switching to a backup carrier when the primary carrier network is unavailable, signal quality is poor, or a policy is triggered, ensuring connection continuity. Similar to Failover, Carrier Fallback focuses on redundancy at the carrier level, supporting real-time fault detection, policy configuration, and seamless switching. It is a core capability in a Multi-Operator multi-carrier architecture.
Trigger Conditions
Typical triggers for Carrier Fallback include: no signal on the primary network, attachment failure, data session establishment failure; primary network signal consistently below threshold (e.g., RSRP < -100 dBm); primary network congestion or QoS not met; high roaming charges on the primary network, with policy requiring a switch to the local network; primary network failure or maintenance, with proactive notification from the operator. The platform should support configurable trigger thresholds and priorities to avoid false triggers and frequent switching.
Switching Strategy
The switching strategy needs to be planned in advance: priority between primary and backup networks, PLMN Selection order, Preferred Network preference; whether to automatically revert after switching, conditions for reversion, and cooling time; differentiated configuration by device, customer, and region. In cross-border scenarios, Roaming Policy and Geo-Based Pricing need to be considered to avoid switching to a high-cost network causing a surge in expenses.
Implementation in ICMP
SimtoLink ICMP supports Carrier Fallback strategy configuration, combined with Card Diagnostics real-time status and Multi-IMSI capability, to achieve automatic switching between primary and backup networks. Supports OTA delivery of switching strategies, API triggers, and manual switching via the console. The platform records switching events in Audit Trail , facilitating auditing and fault analysis.
Fallback changes the attached network, not the platform region
Carrier fallback happens between the SIM and the radio network. When the primary operator cannot attach, the session cannot be established, or quality stays below a condition written in advance, the device registers with a backup operator using another subscriber identity or another profile. The cloud region where the platform runs, the API address, and the place data is stored do not have to change because of that. Reading it as a data-center switch sends people to migrate customer data before connectivity has recovered. That is the wrong direction.
In practice it can be a multi-identity SIM selecting another subscriber identity, or an embedded SIM enabling another profile. Both paths attach again. The data session in progress is interrupted, and applications that depend on a long-lived connection have to reconnect themselves. The fallback record should state which network was left, which network was entered, why it triggered, and when it happened. Otherwise it is impossible later to tell a policy action from someone swapping the SIM on site.
Signal and cost limits that allow an automatic network change
An automatic network change should be constrained by quality and cost together. Looking only at signal, a device may move onto a high roaming tariff for a slightly stronger received power. Looking only at price, a device stays on a cheap network that can no longer carry data. Usable conditions usually include repeated attach or session failures on the primary, radio quality below a threshold for a period of time, and a known outage on the primary. The threshold must include a duration, so a brief fade in a tunnel or an elevator does not trigger a switch.
After the switch there must be a cooldown, and a rule for when a return to the primary is allowed. Switching back the moment the primary recovers makes the device attach back and forth between the two networks. If geo-based pricing marks the backup network as a high-price zone, the policy should require a person to confirm, or allow only a short emergency stay, not an unlimited one. Multiple identities are a prerequisite. If the SIM has no second identity that can register, a policy on the platform cannot conjure a second operator. The access point after the switch must also be valid on the backup network. See how an access point name is matched.
Session drops and tariff jumps caused by flapping
A policy with no hysteresis and no cooldown makes the device register back and forth at the boundary of two networks. Each registration interrupts the session. The application looks like frequent dropouts, while traffic rises because sessions are rebuilt again and again. On the invoice, some usage is on the primary and some is on the expensive visited network, so the bill is higher than staying on one network. If the original identity is not disabled during fallback, both networks may briefly believe the SIM is online, and overlapping detail records appear.
Another error is configuring an operator change for a platform-region fault. When the region that hosts the API is unavailable, changing the visited network does not restore the management platform. It only makes the device attach again at the wrong time. A preferred-network list and a fallback policy set to opposite priorities are another case: the list pulls the device back to the primary, fallback pushes it away, and the device keeps searching. When investigating, read the sequence of network changes, not only the current attach point. After an emergency switch, there should be a condition for switching back, and the usage from that interval should be checked against which tariff it landed on, so a high-price network is not discovered at month end to have become the default path.
After a switch policy is delivered to the device, confirm with one controlled test that it really changes network and really stops. Use a SIM that can tolerate the interruption. Record the network identifier, access point, and usage attribution before and after the switch. If the backup network cannot be seen at all, the policy retries forever. The device uses power and keeps failing, while the platform shows “fallback configured.” In that case raise an alert instead of searching without limit. Write the policy version on the device side, so a cooldown changed on the platform is not still the old policy on the device, with each side explaining “why it did not switch” differently.