Why Your Multi-Network SIM Didn’t Switch – and What Nobody Told You About How Roaming SIMs Actually Work
You were sold a roaming SIM on the promise it would automatically switch networks when one goes down. EE has an outage. Your CCTV goes dark. You call the supplier and they say it should have switched. It didn’t. This guide explains exactly why – and what you need to do about it.
A CCTV installer fits twelve cameras at a retail park. Each device runs on a multi-network roaming SIM. The supplier’s pitch was clear: “If EE has problems, the SIM will automatically switch to Vodafone or O2.” Three months later, EE has a regional outage. Every camera on the site goes offline at once. The installer calls the SIM supplier. The supplier says the SIM should have switched networks. It didn’t. Nobody can explain why.
This scenario plays out dozens of times every week across the UK. The problem is not a faulty SIM. It is a fundamental misunderstanding of how roaming SIMs, cellular modems, and network selection actually work – sold as a feature that does not exist in the way it was described.
This guide covers everything: how network selection really works, what PLMN and FPLMN mean and why they matter, the difference between steered and unsteered SIMs, why ping reboot often makes the situation worse, what the router hardware has to do with it, and what the real solutions look like – from router configuration through to multi-IMSI, eUICC, and SGP.32.
The Promise vs The Reality
Before going further, here is the key claim and what it actually means in practice:
| What you were sold | What actually happens |
|---|---|
| “Automatically switches to the best network” | The modem selects a network at registration based on a priority list stored on the SIM. It does not continuously monitor performance and switch dynamically. |
| “If EE goes down, it switches to Vodafone” | Only if EE’s signal disappears completely at the modem’s antenna. If EE has signal but broken data, the modem sees nothing wrong and stays on EE. |
| “Multi-network means multi-operator resilience” | It means the SIM has roaming agreements with multiple operators. Which one the modem uses, and when it switches, is governed by firmware and 3GPP standards – not the SIM alone. |
| “Just reboot the router and it’ll reconnect on a working network” | Usually it reconnects on the same network, because the modem stores the last registered network (RPLMN) and tries that first on every restart. |
| “The SIM intelligently picks the strongest signal” | Only true for unsteered SIMs in specific conditions. Steered SIMs have a priority network list and will prefer it even at poor signal. |
The single most important thing to understand: A roaming SIM gives the modem permission to use multiple networks. It does not give the modem the ability to detect broken data and switch automatically. Those are two completely different things – and the industry sells them as if they were one.
How Mobile Network Selection Actually Works: PLMN Explained
Every mobile network in the world has a unique identifier called a PLMN – Public Land Mobile Network code. It is a combination of a country code (MCC) and a network code (MNC). EE in the UK is 234-30. Vodafone UK is 234-15. O2 UK is 234-10. Three UK is 234-20.
When a cellular modem powers on – whether in a router, a CCTV camera, or any other device – it goes through a process called PLMN selection, governed by the 3GPP standard TS 23.122. This process is not “find the best network.” It follows a strict priority order:
- Try the RPLMN – the Registered PLMN, meaning the last network the modem was successfully registered on. This is stored in the modem’s memory and tried first on every restart.
- Try the HPLMN – the Home PLMN associated with the SIM’s home operator.
- Try networks listed in the SIM’s User-controlled PLMN Selector file, in priority order.
- Try networks in the Operator-controlled PLMN Selector file, in priority order.
- Try all other available PLMNs by signal strength.
Notice what is not in this list: data quality, ping response time, latency, backhaul performance, or any application-layer measure of whether a network is actually delivering data. The modem picks a network based on radio signal and priority lists. It does not know whether the internet is reachable via that network.
The RPLMN Problem: Why Rebooting Returns You to the Same Network
The RPLMN is the critical factor most installers and SIM resellers overlook. When a modem successfully registers on a network – say, EE – that PLMN code is stored. On every subsequent restart, the modem tries EE first. If EE’s signal is still present at the antenna, the modem registers on EE again and considers itself connected.
From the modem’s perspective, it is connected. It has radio registration. What it does not know is whether EE’s backhaul is down, whether the data session is routing packets, or whether the internet is reachable. The modem operates at the radio layer. Data failure is an IP-layer event. These are separate things.
This is why rebooting a router or restarting the mobile interface on a failing network often results in the same outcome: the modem finds the same PLMN, re-registers, and returns the same broken connection. Ping reboot – the most common watchdog configuration – triggers a restart when pings fail, but the restart returns the modem to the RPLMN. If that PLMN still has radio signal, nothing changes.
Signal bars do not mean working data. A router can show four bars and a registered status while having no functional internet connection. The bars measure radio signal strength. The data path is a completely separate chain – through the APN, the operator’s packet core, backhaul, and peering. Any link in that chain can fail while the radio layer remains fine.
What the FPLMN List Is – and Why It Makes Things Worse
There is a second list stored on the SIM card that causes serious problems for roaming IoT deployments: the FPLMN – Forbidden PLMN list.
When a modem tries to register on a network and the network actively rejects the attempt – sending an explicit registration denial – the modem writes that network’s PLMN code to the FPLMN list on the SIM. Once a network is on the FPLMN list, the modem will not attempt to register on it again, even if the network becomes fully available. The ban persists on the SIM card itself, surviving reboots.
This is meant to be a useful optimisation: if a network has actively rejected a SIM, there is no point retrying it constantly. But in practice it creates serious problems:
- A temporary network rejection – caused by congestion, a transient core network fault, or a roaming agreement edge case – can permanently blacklist a network on that SIM for the lifetime of that deployment
- Multiple network rejections can fill the FPLMN list, leaving the modem with no valid networks to try
- The FPLMN list is stored on the SIM, not the modem, so replacing the router does not clear it
- A simple router reboot does not clear the FPLMN list – the list persists in SIM memory
This is a common cause of “stuck on No Service” situations that puzzles both installers and SIM suppliers. The modem is not finding a network because networks it has previously tried keep getting added to the FPLMN, and the SIM eventually has nothing left to try.
How to Check and Clear the FPLMN List
The FPLMN list can be read and cleared using AT commands sent directly to the modem. On a Teltonika router, this is done via SSH and gsmctl or direct AT command access. The commands are standardised across modem chipsets:
AT+CRSM=214,28539,0,0,12,”FFFFFFFFFFFFFFFFFFFFFFFF”
AT+CFUN=1
Important: The AT+CFUN=0 step before writing to the FPLMN is critical. Writing to the SIM while the modem is actively scanning or attaching can interrupt the process on some chipsets and cause excessive retry loops. Always disable the radio first, write, then re-enable. Some SIM suppliers warn against clearing the FPLMN too frequently – if the modem is in a loop retrying a genuinely-rejecting network, clearing the FPLMN will just restart the loop.
The FPLMN cannot typically be cleared remotely via a SIM management platform if the device is offline – because the device needs to be online to receive the command. This is the chicken-and-egg problem with FPLMN management at scale: the devices that most need a FPLMN reset are the ones that are not connected.
Steered vs Unsteered SIMs: The Difference That Actually Matters
Not all multi-network roaming SIMs behave the same way. The most important distinction is whether the SIM is steered or unsteered – and most resellers either do not mention this or actively misrepresent it.
Priority network list on SIM
The SIM’s PLMN selector file has a ranked list of preferred networks. The modem will always try to stay on the highest-priority network, even if that network has poor signal or degraded data. Switching to a lower-priority network only happens when the preferred network completely disappears.
- Commercial agreements drive network preference, not signal quality
- Preferred network may not be the best performing at your site
- Slow to switch even when performance is poor
- May return to preferred network after a reboot even if it was the problem
No preferred network – signal decides
The SIM’s PLMN selector file is empty or populated with all networks at equal priority. The modem selects based on signal availability. When signal on the current network drops below threshold, the modem will evaluate alternatives without a commercial bias toward any specific operator.
- No commercial operator preference baked in
- Modem selects based on actual signal conditions
- Better suited for fixed IoT deployments
- Still subject to RPLMN behaviour on reboot
Ask your SIM supplier directly: “Is this SIM steered or unsteered?” and “What is the PLMN priority order on the SIM?” If they cannot answer, or tell you the SIM “automatically picks the best network” without specifying the mechanism, treat that as a steered SIM with marketing language.
Who Controls the Steering?
Steering happens at two levels and both can affect your device independently:
SIM-level steering: The PLMN priority list embedded in the SIM card at manufacture. This determines which network the modem tries first. It is set by the SIM issuer and reflects their wholesale roaming agreements. A SIM issued by an MVNO with a preferential wholesale deal on EE will steer devices to EE first, regardless of signal quality at your specific site.
Network-level Steering of Roaming (SoR): Some visited networks send active messages to roaming devices pushing them toward a partner network. This is the home operator instructing the modem, via an OTA message, to switch to a specific network. An unsteered SIM can be overcome by network-level SoR if the home network has a commercial agreement with a specific visited partner.
A truly steering-immune SIM has an applet that ignores or blocks SoR messages from the home network. Most commodity roaming SIMs do not have this protection.
The Network Selection Stack: Where Ping Reboot Sits
Understanding why ping reboot does not solve the PLMN-stuck problem requires understanding that a cellular router maintains several completely independent layers of state:
Ping reboot detects failure at layer 5. The problem lives at layer 2. When ping reboot triggers a router reboot, the modem reinitialises – but layer 2 runs its PLMN selection process independently, finds the RPLMN still present at layer 1 (radio signal), and re-registers on the same network. Layers 3 and 4 then re-establish on the same broken network. Layer 5 fails again. Ping reboot fires again. The cycle repeats.
What Does Reset the PLMN Layer?
On Teltonika routers running RutOS, these are the mechanisms that operate at or below the PLMN layer:
-
1Low Signal Reconnect
Under Network > Mobile in RutOS. Triggers a modem-level reconnection when signal drops below a configured threshold – not just an IP restart. More likely to cause actual PLMN reselection than a router reboot. Essential for marginal-signal sites. Configure alongside ping reboot, not as a replacement for it.
-
2Operator Whitelist
Configures the modem to only attach to specific operator MCC/MNC codes. Prevents the modem from registering on known-poor networks at the site. Requires a site survey to identify which networks are available and which consistently perform – but once set, it is the cleanest preventive solution.
-
3AT+CFUN=0 / AT+CFUN=1 Cycle via Script
Forces full modem radio reinitialisation, clearing the RPLMN state and triggering a fresh PLMN selection. Can be scripted in RutOS as a scheduled task or triggered by a custom watchdog. Aggressive but effective – and can be combined with FPLMN clearing for a complete modem reset.
-
4Dual SIM with SIM Switch Rules
The most reliable hardware-level solution. On dual-SIM routers (RUTX11, RUTM52, RUTX50, Milesight UR32L, UR35), SIM1 and SIM2 operate as entirely separate modem contexts. When SIM1 fails ping checks, the router switches to SIM2 on a different MNO. No shared RPLMN state. No shared FPLMN. A clean modem context on a network that was not failing.
Can You Fix This Remotely? SIM Management Platforms and Bulk PLMN Reset
One of the most frequently asked questions from fleet operators is whether you can trigger a PLMN reset or FPLMN clear across a fleet of devices remotely, without a site visit. The answer depends on which layer the problem is at and whether the device has any alternative connectivity.
Remote Management via Router Platforms (Teltonika RMS / Milesight Development Platform)
If the device still has a data connection – even a degraded one – remote management platforms can reach it:
Teltonika RMS provides remote SSH access to individual routers. From an SSH session, AT commands can be sent to the modem via gsmctl. This allows remote FPLMN checking and clearing, operator whitelist changes, and modem restart commands. It can be scripted, but RMS does not currently expose bulk AT command execution as a native feature – it requires per-device SSH access or a custom script pushed via RMS.
Milesight Development Platform supports bulk operations across the fleet – firmware updates, configuration changes, and service invocations simultaneously across multiple devices. The platform also provides remote SSH access and REST API control. For fleet operators managing Milesight UR32L, UR35, or UG routers, the Development Platform is the most practical route to scripted bulk modem operations including FPLMN resets and operator whitelist updates. Webhooks can be configured to trigger alerts when a device goes offline – giving you the prompt to action a remote intervention before the device becomes unreachable.
The offline problem: Any remote PLMN reset relies on the device having enough connectivity to receive the command. A device that has hit a full FPLMN list and cannot find any network has no data channel to receive a remote command. For these situations, you need either a fallback connection (dual SIM, or a second WAN path) or a physical site visit. This is why preventing the FPLMN from filling up matters more than having a recovery procedure.
SIM-Level OTA Management
Some enterprise IoT SIM platforms can push OTA commands to the SIM card itself via SMS, independently of the router’s data connection. If the modem has any network registration – even for SMS only – a properly configured SIM management platform can push an OTA update to clear the FPLMN or modify the PLMN priority list.
This capability is not standard across all SIM providers. It requires the SIM to have an OTA-capable applet and the SIM management platform to support FPLMN OTA operations. Ask your SIM supplier specifically whether their platform supports OTA FPLMN management before deploying at scale.
Multi-IMSI SIMs: Better, But Not a Complete Fix
Multi-IMSI SIMs hold multiple independent subscriber identities on a single physical SIM card. An applet on the SIM can switch between these identities, each with its own PLMN relationships and roaming agreements. This is a meaningful step beyond a simple roaming SIM, but it comes with its own caveats.
Independent network identities
- Each IMSI has separate MNO relationships – not just roaming via one MVNO
- Better coverage negotiation in each market
- Can appear as a local subscriber rather than roaming
- Reduces permanent roaming risk in regulated markets
Still modem-dependent
- Switching IMSIs requires a modem stack restart: 30 to 90 seconds of downtime per switch
- Switch triggers vary between providers – some only switch on signal loss, not data failure
- APN must be universal or the device loses data after an IMSI switch
- Not all multi-IMSI SIMs are steering-immune
- FPLMN issues can still occur on each IMSI independently
The key question to ask any multi-IMSI SIM provider: What triggers an IMSI switch? If the answer is “signal loss” – the same trigger as basic PLMN reselection – you have not gained much. If the answer is “data connectivity failure, detected by the SIM platform” or “ping failure to a monitored endpoint,” you have a meaningfully better solution. Very few providers offer the latter.
Permanent Roaming: The Problem You May Not Know You Have
For UK deployments using UK-registered SIMs on UK networks, permanent roaming is not typically an issue. But for any deployment that involves a device staying on a single visited network for extended periods – which is the default state of any static IoT device – permanent roaming restrictions can apply.
Most cellular roaming agreements were designed for traveling consumers returning home after a few weeks. An IoT device installed in a fixed location never “returns home.” Under many roaming agreements and an increasing number of national regulations, a SIM roaming on a visited network for more than 90 days can face connection termination.
Countries with active permanent roaming restrictions or bans include Brazil (ANATEL-enforced 90-day limit), China (ban on inbound permanent roaming), India, Saudi Arabia, UAE, and Australia among others. For UK installers deploying overseas, this is an operational risk that standard multi-network SIMs do not address.
The solution for permanent roaming at scale is local profile provisioning – either via multi-IMSI (where one IMSI appears as a local subscriber in the visited country) or eUICC with remote profile management, which allows a local operator profile to be loaded onto the SIM without physical access.
The Real Fix: eUICC and What SGP.32 Changes
eUICC (Embedded Universal Integrated Circuit Card) is the architecture that addresses most of the problems described above at their root. Rather than a SIM with fixed identities trying to roam, an eUICC can hold multiple complete operator profiles and switch between them over the air.
SGP.02 – M2M eSIM
The original M2M remote SIM provisioning standard. Operator-push model, complex infrastructure. Well-deployed but not designed for lightweight IoT constraints.
Deployed nowSGP.22 – Consumer eSIM
The standard in smartphones. User-initiated QR code profile downloads. Not designed for unattended IoT devices with no screen or user interface.
Not suited to IoTSGP.32 – IoT eSIM
Published by GSMA in 2023. Specifically designed for resource-constrained IoT devices with no UI. Remote, asynchronous, lightweight profile management via eIM and IPA.
Ecosystem maturingSGP.32 is significant because it changes who controls connectivity. With a traditional roaming SIM, the SIM issuer controls the PLMN priority list and the roaming agreements. The operator can only deploy what the SIM allows. With SGP.32, the operator can push a completely new network profile to an entire fleet remotely – switching operator, updating PLMN priorities, adjusting APN settings, or provisioning a local profile for a regulated market – all without physical access to any device.
This means that when EE has a regional outage, a fleet operator with SGP.32-capable devices could push a profile update that moves affected devices to a Vodafone or O2 profile, resolving the issue at scale. That is not real-time automatic failover – it requires a human to identify the problem and initiate the push – but it is fleet-level remote remediation without site visits.
The Hybrid Approach: What Works Now
SGP.32 ecosystem maturity is still developing. Not all routers have eUICC-capable SIM slots. Not all operators offer SGP.32 management. For most UK deployments today, the practical architecture is:
- Unsteered multi-network SIM from a provider who can confirm the SIM is steering-immune and uses a universal APN
- Dual SIM hardware where the deployment criticality warrants it – genuine MNO diversity at the hardware level
- Correct router watchdog configuration – Low Signal Reconnect alongside ping reboot, operator whitelist after site survey
- Remote management platform (RMS or Milesight Development Platform) with alerting on connectivity loss, allowing remote AT command intervention before devices become fully unreachable
- Multi-IMSI on eUICC as the SIM choice where the deployment lifecycle is 5+ years – giving immediate multi-network coverage with the option to reprovision operator profiles later
The question to ask before every deployment: If the primary network at this site fails – not disappears, just delivers broken data – how does my device recover without human intervention? If the answer is “ping reboot will restart the router,” you need to reconsider. If the answer is “dual SIM with a second MNO, and the router switches on ping failure,” you have real resilience.
Questions to Ask Your SIM Supplier Before You Buy
- Is the SIM steered or unsteered? If steered, which operator has priority and why?
- Is it steering-immune? Can network-level Steering of Roaming push the modem to a specific operator against the SIM’s own priority?
- Does it use a universal APN? If an IMSI switch occurs, does the APN stay the same, or will the device lose data while it reconfigures?
- What triggers a network switch? Signal loss only, or data connectivity failure? And how long does it take?
- Does your platform support OTA FPLMN management? If a device fills its FPLMN list, can you clear it remotely?
- Is this eUICC-based? If the deployment runs for 5+ years and the preferred operator changes, can you reprovision without visiting the site?
- What visibility do you get? Can you see which network each device is currently on, current signal quality, and historical network switches?
The Key Points
- A roaming SIM provides permission to use multiple networks. It does not provide automatic, application-aware failover. These are different things, and the industry sells them as one.
- PLMN selection follows 3GPP TS 23.122, not signal quality or data performance. The modem returns to the last registered network (RPLMN) on every restart, even if that network has broken data.
- Signal bars measure radio signal at layer 1. Data connectivity lives at layer 4 and above. A network with four bars can have completely broken data. The modem cannot tell the difference.
- The FPLMN list stores networks the SIM has been rejected from. It lives on the SIM card, survives reboots, and can permanently block a modem from trying valid networks. Clearing it requires AT commands or OTA SIM management.
- Ping reboot is an IP-layer watchdog. It detects layer-5 failure and restarts the router. It does not reach the PLMN layer, so the modem returns to the same broken network after every reboot. Low Signal Reconnect is more appropriate for PLMN-level problems.
- Steered SIMs prioritise commercial partner networks over signal quality. Unsteered SIMs do not. For fixed IoT deployments, unsteered plus steering-immune is significantly better.
- Multi-IMSI SIMs are better than basic roaming SIMs but introduce 30 to 90 seconds of downtime per IMSI switch, and quality varies enormously between providers.
- Dual SIM on separate MNOs with SIM switch rules is the most reliable hardware-level resilience available today. SIM2 has no shared RPLMN or FPLMN state with SIM1.
- Remote management platforms (Teltonika RMS, Milesight Development Platform) allow remote AT command access for FPLMN clearing and modem resets – but only while the device still has connectivity. A fully offline device requires physical intervention.
- SGP.32 eSIM allows remote operator profile provisioning at fleet scale. The ecosystem is maturing and represents the correct long-term architecture for deployments with 5+ year lifespans or regulated-market complexity.