OmniSIM Reach - Centralized Multi-IMSI
OmniSIM REACH, technical description of the network steered Multi-IMSI implementation.
This documentation applies to the following products:
OmniSIM
For all other products, please review their respective documentation
Summary
OmniSIM REACH uses a centralized (network steered) Multi-IMSI mechanism. So, no preferred or blacklist on the SIM, but all decisions on connecting to any network through any IMSI is managed from the core network.
The advantage is “easy to manage, fast to roll-out”:
No time & signalling consuming OTA campaigns are needed to update parameters on the SIM
Instantaneous & 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 straight forward: the SIM applet round-robins over the available IMSIs and waits for an IMSI/network combination to attach to.
Technical overview
Goal
KORE utilizes multiple roaming sponsors to provide global coverage. This is a dynamic area where wholesale pricing & coverage is constantly changing (every 1 – 3 months) due to negotiations, traffic evolvement and regulations. By leveraging multiple roaming sponsors, KORE is able to create an overlapping blanket of roaming coverage and mix & match based on best coverage and price for any local network.
To be able to provide the best price & coverage, roaming steering needs to be flexible and this requires 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 IMSI’s until a connection is established.
The high-level behavior is as follows:
After power-up the SIM starts with the last active IMSI
The device tries to attach to any of the available networks using that IMSI
If no attach is accomplished, the next IMSI is selected after a timeout
The device tries again to attach to any of the available networks using this new IMSI
The SIM keeps running through the IMSI sequence upon timeout, until an attach is accomplished.
Network searching and Location Update attempts usually take some time. As the SIM is intended for IoT and not for consumer, some delay is acceptable. The success rate of having an attach in the end is of more importance.
Generic description of an attach
SIM to Cellular Module Communication
The communication between the SIM (Subscriber Identity Module) and the Cellular Module is governed by the protocols outlined in the ETSI TS 131 102 standard. This standard specifies the structure of files stored on the SIM that provide essential information required by the Cellular Module for network communication.
Examples of information provided by the SIM to the Cellular Module:
Secret Keys: Utilized for authentication processes to ensure secure communication.
OPLMN (Operator PLMN): The list of preferred networks by the mobile device for connecting to the mobile network.
FPLMN (Forbidden PLMN): A list of networks that the device is forbidden to connect to.
IMSI (International Mobile Subscriber Identity): A unique identity associated with all mobile network users.
ICCID (Integrated Circuit Card ID): The unique serial number of the SIM card.
The SIM card may contain small applets enabling several additional features. Some common applets are: Multi IMSI, Service Monitoring and Voice calls whitelisting. This document limits to the centralized steered Multi IMSI applet.
The SIM card and its surrounding are depicted in the picture below:
The Cellular Module communicates to the radio network. This starts with scanning all available radio spectrum for networks. Selection of the network to attach to is based on field strength and possible preferred networks.
Preferred networks can be read from the SIM card (not used by KORE at this moment).
The Cellular Module initiates a location update to the selected local MNO. The local MNO starts communication to the HLR/HSS for authentication, based on the keys derived from the SIM via the Cellular Module.
An update 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 back to the Cellular Module that the service is granted or not.
Once connected, the Cellular Module starts a create session request to the GGSN/PGW and a data session will be established using an APN (Access Point Name) which points to an interface port on the GGSN. Usually this is the internet, but the port may also be a dedicated endpoint, also known as a private APN. From this point on, the device may start communication, e.g. sending data from the sensors to the IoT end-point.
The above is also depicted in the flow diagram further on in this document (chapter flow diagrams).
Multi IMSI applet description
The above is the generic and initial start-up, without Multi IMSI being involved yet. Here, we will describe how Multi IMSI comes into play.
A SIM is powered on and the first IMSI in the list of IMSIs is used by the SIM. The Multi IMSI applet needs to get information of 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.
After a pre-determined number of STATUS messages, the SIM applet requests information of the network service using the update of its LOCI file (Location Information) by sending a PLI (Provide Local Information) to the Cellular Module.
The LOCI file is on the SIM and written by the Cellular Module. This file contains information like Mobile network MCC/MNC, Local Area Information and the Location update status. The Location update status can be: updated, not updated, PLMN not allowed, Location Area not allowed. The last three indicate “limited service”. The status “updated” means “service”.
Should this file indicate a “limited service”, Multi IMSI applet will pick the next IMSI from the list and sends a REFRESH to the Cellular Module. This indicates that there is new information from the SIM to the Cellular Module. Examples of files that are refreshed are: IMSI, FPLMN, OPLMN. The Cellular Module will take the new IMSI and cleared FPLMN and start the attach procedure again.
Should the last IMSI being used, the Multi IMSI applet will use the first in the list again. Essentially cycling (round robin) until an attach is established.
This sequence is depicted in this picture:
Flow diagrams
Power up sequence
The Multi IMSI applet and the network attach by the cellular module are two separate processes:
The applet is triggered by STATUS commands, requesting a PLI / LOCI update after every 4 statuses
The network attach is based on the network scan by the module, attaching using the IMSI and other information as provided by the SIM
The orange arrows depict the STATUS message from the Cellular Module to the SIM Card. In general, the interval between each STATUS message is 20 – 30 seconds.
After booting up and exchanging information the Multi IMSI applet will start a PLI (Provide Local Information) after each 4 statuses. The cellular module responses with the information regarding the MCC, MNC, LAC and service and the network attach status. As described earlier, this results in “service” or “limited service”.
Normal operations, IMSI Switch after service is lost
Once attached to a network, the Multi IMSI applet monitors the service by requesting an update of the LOCI file on the SIM. The Multi IMSI applet sends a PLI to the Cellular Module after each 4 STATUS messages.
In case the Cellular Module reports “limited service”, in response to a PLI, the Multi IMSI applet picks the next IMSI from the list and will send a REFRESH to the Cellular Module, indicating that there is new information available. The Cellular Module will get the new IMSI from the SIM and will start the attach sequence again.
IMSI sequence
The order of IMSIs to be picked is dedicated in a configuration file of the Multi IMSI applet. Standard sequence is 1 > 2 > 3 > 1 ... Where the current implementation is:
IMSI 1: Green
IMSI 2: Blue
IMSI 3: Red
Best practices
It goes without saying that the device software should always wait for the Cellular Module to report service. This can be done using the AT+COPS and AT+CREG Commands. However, in order to get a full update location, it is advised to make sure the APN is set properly all the time and as early in time as possible.
APN definition
The APN is used after the initial attach procedure for the PDP Context activation. This could be with or without username/password credentials (PAP/CHAP) depending on customer implementation.
Be aware that in case the APN does not match with the APNs defined in the Insert Subscriber Data, unpredictable behavior from the local mobile operator can be expected. This can mean a reject of the request, local networks changing the requested APN, removing the username/password or other.
Rejecting the create session or changing APNs in a create session will lead to unpredictable behavior from access to the internet while not expected (e.g. in case of dedicated/private APN) or no internet access at all or even a complete disconnect from a network.
Power cycleIn some cases it is advised to power cycle the cellular module. The reason for this could be a process hanging between SIM and Cellular Module due to multiple network attach attempts, incorrect APN in the start or incorrect population of the FPLMN list.A power cycle is also good to reset the SIM and make sure the attach procedures can be re-done without having all kinds of information cached in the SIM or the Cellular Module.
A power cycle is not recommended to perform within the IMSI cycling process, so at least 5 minutes after powering up the Cellular Module should be considered. A longer period is allowed but most probably brings no added value.
Should network services be lost during operation, it is recommended to allow the Cellular Module at least 5 to 10 minutes to get re-connected as the device may be in motion and needs to find new networks to attach to.
Network monitoring
It is recommended to perform regular network monitoring on device level. A minimum is to have visibility of the network service. Additional parameters to be checked are 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 the 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, max 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. A power cycle is recommended.
SIM Toolkit
Please be aware that the Multi IMSI applet is a network steered Multi IMSI. There is no STK available to control the applet.
Last updated
