OmniSIM Multi-IMSI Top-Tips

Some of the top tips from our OmniSIM guru's on Multi-IMSI.

This documentation applies to the following products:

  • OmniSIM

For all other products, please review their respective documentation

OmniSIM Reach uses a centralized (network-steered) multi-IMSI mechanism. There is no preference or blacklisting of the SIM. All decisions on connecting to any network through any IMSI are managed from the core network. The SIM card may contain small applets enabling additional features.

Overview

The advantage is “easy to manage, fast to roll out”:

  • No time and signaling consuming OTA campaigns are needed to update parameters on the SIM

  • Instantaneous and better targeted deployment of new roaming policies

  • Generic implementation for all SIMs in a group, no waiting for OTA campaigns to finalize

  • 100% target rate, not depending on OTA success rate

The mechanism is straightforward; the SIM applet round-robins over the available IMSIs and waits for an IMSI and network combination to attach to.

Network searching and location update attempts usually take some time. Some delay is acceptable as the SIM is intended for IoT, not consumers. In the end, the success rate of being able to attach to a network is of more importance.

How it works

KORE utilizes multiple roaming carriers to provide global coverage. This is a dynamic area where wholesale pricing and coverage constantly change (every 1–3 months) due to negotiations, traffic evolvement, and regulations. By leveraging multiple roaming carriers, KORE can create an overlapping blanket of roaming coverage and mix and match based on the best coverage and price for any local network.

To provide the best price & coverage, roaming steering needs to be flexible, requiring it to be centralized (managed through our core network). This means no IMSI selection per country within the SIM. Instead, the applet walks through the various IMSIs until a connection is established.

The high-level process:

  1. The SIM is powered up and starts with the last active IMSI.

  2. The device tries to attach to any available network using that IMSI.

  3. The next IMSI is selected if it cannot attach and times out.

  4. The device tries again to attach to any available networks using the new IMSI.

  5. The SIM continues this cycle until it finally attaches to an IMSI.

The cellular module communicates to the radio network. This starts with scanning all available radio spectrum for networks. The selection of networks is based on field strength and possible preferred networks.

The cellular module initiates a location update to the selected local MNO. The local MNO starts communication with the HLR/HSS for authentication based on the keys derived from the SIM via the cellular module.

An updated location is finalized by the HLR/HSS sending roaming allowed / not allowed and granted services. Some other information is exchanged, like MSISDN, barring, and QoS. The MNO reports to the cellular module whether or not the service is granted.

Once connected, the cellular module starts a create session request to the GGSN/PGW, and a data session will be established using an APN, which points to an interface port on the GGSN. Usually, this is the internet, but the port may also be a dedicated endpoint known as a private APN. From then on, the device may start communicating (sending data from the sensors to the IoT endpoint).

Multi-IMSI applet description

The previous high-level process is the generic and initial start-up, without multi-IMSI involvement. Here, we will describe how multi-IMSI comes into play.

  1. The SIM is powered on, and the SIM uses the first IMSI in the list of IMSIs. The Multi-IMSI applet needs to get information for the network attach. Based on the status message from the device to the SIM, the applet determines the time of the latest update of the network service.

  2. After a pre-determined number of status messages, the SIM applet requests information about the network service using its LOCI file (Location Information) update by sending a PLI (Provide Local Information) to the cellular module.

    LOCI

    The LOCI file is on the SIM and written by the cellular module and contains mobile network MCC/MNC information, local area information, and the location update status.

    Location update status

    Location update status includes; updated, not updated, PLMN not allowed, or location area not allowed. Note: Limited service is available for statuses not updated, PLMN not allowed, or location area not allowed. Note: Full service is available for updated status.

  3. If the LOCI file indicates a “limited service,” the SIM will pick the next IMSI from the list and sends a refresh to the cellular module. This indicates new information from the SIM to the cellular module. Example: Refreshed IMSI, FPLMN, or OPLMN.

  4. The cellular module starts the new attach procedure with the new IMSI and cleared FPLMN.

  5. If the IMSI used was the last on the SIM, the Multi-IMSI applet will return to the top of the list and use that IMSI. Essentially cycling (round robin) until an attach is established.

APN definition

The APN is used after the initial attach procedure for the PDP context activation. Depending on the implementation, this could be with or without username/password credentials (PAP/CHAP). Note: If the APN does not match the APNs defined in the Insert Subscriber Data, unpredictable behavior from the local mobile operator can be expected. The behavior could mean a rejection of the request, local networks changing the requested APN, removing the username/password, and others.

Rejecting the create session or changing APNs in a create session can lead to the following:

  • Unpredictable access to the internet when not expected Example: dedicated or private APN

  • No internet access

  • Complete disconnect from a network

Power cycle

Recommended

In some cases, it is advised to power cycle the cellular module. The reason for this include:

  • Process hanging between SIM and cellular module due to multiple network attach attempts

  • Incorrect APN

  • The incorrect population of the FPLMN list

A power cycle is also good for resetting the SIM and ensuring the attach procedures can be redone without having information cached in the SIM or the cellular module.

Not recommended

A power cycle is not recommended during the IMSI cycling process, so at least 5 minutes after powering up the cellular module should be considered. A more extended period is allowed but most probably brings no added value.

Should network services be lost during the operation, allowing the cellular module at least 5 to 10 minutes to reconnect is recommended, as the device may be in motion and needs to find new networks to attach to.

Network monitoring

We recommend performing regular network monitoring at the device level. At a minimum, ensure visibility to the network service. Additional parameters that can be checked include the MNO and IMSI.

IMSI monitoring

As IMSI cycling is inherent to the Multi-iMSI applet, the IMSI should be monitored to avoid continuous cycling.

MNO monitoring

Once an attach is established, the cellular module should stay on that MNO/IMSI combination. The only reason for switching IMSIs is a loss of service which can happen due to loss of coverage or a defect in the network. An IMSI switch can take place, and the cellular module should get a new attach within 40 seconds to a maximum of 5 minutes.

Power cycle

If, after 10 - 15 minutes, the SIM is still sending refresh messages to the cellular module, an issue in communication could be the case, and a power cycle is recommended.

Last updated