Definition
Multi-IMSI (Multiple IMSI) refers to a single SIM card or eSIM that supports storing multiple IMSI/operator eSIM Profiles, which can be remotely switched according to region, cost, and coverage strategy to achieve "one card, multiple networks." Combined with eSIM Profiles, it can significantly reduce roaming costs, improve connection availability, and support Carrier Fallback operator switching.
Technical Implementation
Multi-IMSI can be implemented via a physical Multi-IMSI card or eSIM: a physical card contains multiple IMSIs, with the active IMSI being switched via OTA or SMS; an eSIM stores multiple eSIM Profiles, with the platform sending instructions to activate/deactivate Profiles. Each IMSI corresponds to a different HPLMN, and the device can select a local IMSI based on its current geographical location to avoid roaming.
Use Cases
Typical scenarios: Cross-border deployment — devices are exported to multiple countries, and upon reaching the target country, switch to the local IMSI to enjoy local tariffs; Cost optimization — choose low-cost IMSI according to Geo-Based Pricing ; Redundancy protection — switch to a backup IMSI when the main network fails to achieve Carrier Fallback ; Coverage expansion — switch to other operators when a certain operator's coverage is insufficient.
Management in ICMP
SimtoLink ICMP supports Multi-IMSI card and eSIM profile management: remote switching, policy configuration, linkage with PLMN Selection and Roaming Policy ; Cross-Border Card Management for unified management; Card Diagnostics to diagnose the current active IMSI and network status.
When a Multi-Identity Switch Takes Effect
Multi-IMSI means one plastic SIM, or one embedded SIM, can store several carrier identities, while only one identity at a time is responsible for attach and for producing CDRs. A switch can be triggered by an over-the-air command, by SMS, or by a local policy. Success is not that the platform sent the command. Success is that the device has attached with the new identity and that later usage is recorded on that identity. Each identity has its own home network, authentication parameters, and tariff, so a switch changes who this SIM is a local subscriber of right now.
Before use, both the device conditions and the business conditions have to be met. The module must support the switch method, and it must not lock the old identity under weak coverage. The product must state which identity is enabled in which countries, and which identity to fall back to on failure. Marking the target identity “enabled” only on the platform, while the device has not executed it, leaves the field roaming on the old identity. Keep the switch policy separate from the preferred network. A preferred network selects a visited network under the current identity. Multi-IMSI replaces the identity itself. The two can work together. One list cannot stand in for the other action. The hardware identity remains the device identity. It does not change because the subscription identity switched.
Still Using the Old Reading after a Successful Switch
A common error is a usage report that keeps grouping by the SIM’s factory identity. If traffic after the switch is priced on the old tariff, cost optimization shows up as “we switched, and the bill did not change.” Another error is that both identities are briefly online during the switch, and CDRs in the overlap are either dropped or counted twice. Keep the enabled interval of each identity. A CDR falls into the interval that contains its start time. Do not rewrite history according to whichever identity is current on the day of the query.
A missing fallback path also leaves the device on an identity that cannot register. If the identity for the target country is not yet provisioned, or the module does not recognize the new network parameters, it should be able to return to the last usable identity, and the platform should record the attempt as a failure, not as a success. A test should verify attach on the real network in the target country, or on an agreed test network. A success code from the command API is not enough. Stock, tariff, and diagnostics for a multi-identity SIM should be recorded as “SIM plus current identity,” not as one permanent record under the SIM number alone.
Keep the switch command and the attach result as two records. Acceptance of the command by the network only means the parameters have reached the SIM. If the device does not register again afterward, the current identity has not changed. The diagnostics page should show two times, “command sent” and “attached with the new identity.” Do not fold them into one success flag. After a fallback to the old identity, also keep the reason, so the next policy change does not keep selecting an identity that cannot register at the same place.
Several identities on a plastic SIM and several profiles on an embedded SIM switch by different mechanisms. Do not summarize both with the same phrase “enabled.” A plastic SIM may switch by an internal program or by SMS. An embedded SIM enables one profile and disables another. If the device has kept only the old network parameters, the platform can show the new identity as enabled while the device still registers with the old one. Enabled status should follow the identity the device actually used to register. The platform command status is a separate column.
A switch policy and roaming steering must not overwrite each other. Steering guides the device to a visited network under the current identity. Changing identity replaces the subscription. If one rule says “lowest cost” and another says “keep the current identity,” the device may refuse to switch under weak coverage, or it may switch and immediately be pulled back. The policy should say which rule wins on a conflict, and how many attempts are allowed in a day, so the device does not register back and forth and leave short CDRs that cannot be assigned.
Provisioning status, tariff, and allowed countries must be valid per identity. When a SIM is assigned to a project, provisioning only one identity does not mean another identity that exists on the record can be used in the target country. Diagnostics should show every identity and which one is registering. Do not write a failed identity’s rejection onto the record of the identity that succeeded. After a fallback, usage from the fallback moment is recorded on the old identity. Usage from before the fallback stays where it was.