2025-06-06 · 7 min read · Technical Whitepapers
A multi-IMSI SIM carries 3-10 subscriber identities on a single chip. When the device powers on in a new country, a Java Card applet reads the LOCI file, checks the current IMSI against visible networks, and — if the network says no — cycles to the next IMSI, clears the forbidden PLMN list, and retries. This entire decision loop runs in 20-30 second polling cycles with no backend intervention. The steering logic — whether round-robin applet or network-steered from the core — is the procurement decision that determines whether your device connects in 40 seconds or 15 minutes.
A device with a multi-IMSI SIM powers on at a container terminal in Rotterdam. Its current IMSI is a Vodafone Netherlands profile. The modem scans visible PLMNs and finds KPN, T-Mobile NL, and Vodafone NL. It attempts to attach with the Vodafone IMSI. The network authenticates it as a local subscriber. Connection established in under 2 seconds. The same device, two hours later, powers on at a distribution center in Istanbul. Its Vodafone Netherlands IMSI is now a roaming visitor. Turkcell rejects the attach — no roaming agreement for this IMSI type. The SIM applet detects the rejection via the LOCI status field, increments to the next IMSI (a Turk Telekom local profile), sends a REFRESH command to the modem, clears the Forbidden PLMN list, and re-attempts. This time Turk Telekom sees a local subscriber. Connection established in roughly 45 seconds. The steering logic that made this decision is a few hundred lines of Java Card bytecode running on the SIM.
The intelligence lives in a SIM Toolkit (STK) applet — a Java Card application installed on the UICC during manufacturing. It does not run continuously. It wakes up on a timer, reads a file, checks a flag, and either goes back to sleep or initiates a switch. The mechanism: every 20-30 seconds, the cellular module sends a STATUS message to the SIM as part of normal GSM/UMTS/LTE protocol operation. The applet counts STATUS messages. After a configurable count — typically every 4th STATUS message — the applet sends a PLI (Provide Local Information) command to the module. The module responds with the contents of the LOCI (Location Information) file. The LOCI contains four critical fields: the MCC and MNC of the serving network, the Location Area Code, and — most importantly — the Location Update Status. The Location Update Status has four possible values: UPDATED (full service — no action needed), NOT UPDATED (attempting to register — wait), PLMN NOT ALLOWED (network rejected — switch IMSI), or LOCATION AREA NOT ALLOWED (tracking area rejection — switch IMSI). When the status reads anything other than UPDATED after a configurable timeout (typically 2-3 minutes of repeated NOT UPDATED readings), the applet triggers the rotation.
There are two fundamentally different approaches to which IMSI gets tried next. Round-robin steering (device-centric): the applet maintains an ordered list of IMSIs — typically 3-10, pre-loaded at the personalization bureau. When the current IMSI fails, the applet selects the next one in sequence regardless of location, cost, or policy. IMSI 1 fails → IMSI 2. IMSI 2 fails → IMSI 3. IMSI 3 fails → back to IMSI 1. The device re-attempts all visible networks with each new IMSI because the applet clears the Forbidden PLMN list after every switch. This is simple, requires zero backend infrastructure, and works anywhere. The downside: the SIM has no knowledge of which IMSI is optimal for the current country — it just cycles until something works. Network-steered steering (centralized): the applet uses the same round-robin mechanism, but the IMSI list and prioritization are managed from the core network, not the SIM. The connectivity provider updates the preferred IMSI order per country based on real-time wholesale pricing, carrier SLA performance, and regulatory changes — typically refreshed every 1-3 months via OTA. The applet still round-robins locally, but the order it follows is centrally optimized. KORE OmniSIM Reach and BICS SIM for Things use this model.
If the applet cycles through all loaded IMSIs and none of them achieves an UPDATED LOCI status — meaning every IMSI was rejected by every visible network — the applet does not give up. It pauses for a backoff period (typically 5-15 minutes, configurable) and restarts the cycle from IMSI 1, clearing the FPLMN list again. The modem rescans and retries. If the device is in an area with genuinely no cellular coverage — a basement, a Faraday-cage environment, deep rural — the cycle continues indefinitely, draining battery at roughly 2-5× the normal idle rate due to repeated PLMN scans and attach attempts. This is the most common cause of "mysterious battery drain" in multi-IMSI IoT deployments: the device is not disconnected — it is continuously searching, switching IMSIs, and re-searching, in a loop that the applet cannot exit because it has no awareness of RF conditions beyond what the LOCI reports. The fix is a CMP-side policy that suspends IMSI rotation after N failed full cycles and reverts to a low-duty-cycle search pattern — but this requires a CMP that supports per-device steering policy, not all do.
The most significant development in steering technology is the convergence of multi-IMSI applets with eUICC (eSIM) platforms. A multi-IMSI-only SIM is fast (sub-minute switching) but static — you cannot add a new IMSI to a deployed SIM without physically replacing it. An eUICC-only SIM is flexible (download any operator profile OTA) but slow — a full profile download consumes 100-500 KB of data and takes 2-15 minutes depending on network conditions. The combined architecture works as follows: deploy an eUICC-compliant SIM (MFF2, iSIM, or removable) with a multi-IMSI profile loaded as the primary operational profile. Day-to-day switching between known carriers in known countries uses the multi-IMSI applet — fast, local, no data consumed. When the device enters a country where none of the loaded IMSIs work, the eUICC layer triggers: the CMP pushes a new operator profile OTA, the device downloads it, and the new IMSIs are added to the applet rotation list. The combined architecture gives you sub-minute switching for 90% of operations and the ability to add new carriers remotely for the remaining 10%.
1. STK support: Does the cellular module support SIM Toolkit (3GPP TS 11.14 / TS 31.111)? Without STK, the applet cannot send PLI commands or receive REFRESH triggers — multi-IMSI steering will not work. Verify this in the module AT command reference, not the datasheet summary. 2. Applet type: Round-robin (no backend needed, works anywhere, but no cost optimization) or network-steered (requires CMP integration, lower data costs, central policy control)? 3. IMSI count: How many IMSIs are pre-loaded? 3 is the minimum for pan-European coverage. 5-7 for global. More IMSIs = longer worst-case attach time (each failed IMSI adds 2-3 minutes of cycling). 4. FPLMN clearing: Does the applet clear the Forbidden PLMN list on every IMSI switch? Without this, a rejected IMSI permanently blacklists networks that might accept the next IMSI. 5. Backoff policy: After how many full cycles does the applet reduce its search rate? If the answer is "never," budget for external power-cycle logic or CMP-side monitoring. 6. eUICC combination: If deploying devices with 10+ year lifecycles, specify eUICC + multi-IMSI. The combined SIM costs EUR 0.50-1.50 more than multi-IMSI-only but saves a truck roll when you need to add a carrier in year 7.