BICS Data Roaming: How to ensure proper device interworking with a Multi-IMSI SIM

[Technical recommendations and trouble-shooting info below]

Single vs Multi IMSI
Many modern IoT roaming SIMs feature more that one IMSI deployed on the SIM applet. This enables them to offer a wider range of local roaming networks to switch to, and sometimes at better roaming data rates.The applet will trigger an IMSI swap if the current IMSI does not have an available roaming agreement with a local network operator. It is a common feature for global deployments of IoT solutions.

However, not all devices are compatible with multi-IMSI SIMs. This may lead to intermittent performance issues as devices do not properly handle IMSI rotation in order to connect to the most suitable network.

Some device firmware may also be set up to force-connect to specific local network using MCC/MNC tables on the device. This may conflict with the IMSI rotation and network selection process. Some devices may also have issues in clearing the forbidden PLMN list.

Multi-Imsi SIMs: Device Compatibility

Before deploying devices with multi-IMSI SIMs, it is important to ensure the device hardware and firmware is capable of managing multi-IMSI connectivity.

Examples:

• Consumer devices (Android/iOS): Provides seamless and full compatibility
• Advanced IoT devices: Should provide seamless and full compatibility
• Basic / rudimentary IoT devices: Please check with the manufacturer if the device firmware and hardware is compatible with Multi-IMSI SIMs. If not, please consider ordering a single-IMSI SIM.

Speak to your device supplier to confirm compatibility. Always test devices across multiple networks before deploying.

Using the correct SIM type
Although non-steered multi-IMSI SIMs are preferable as it offers more local networks (and lower data rates in some countries), some older or simpler devices will perform better with single-IMSI SIMs.

BICS offers both multi-IMSI and single IMSI SIM options through SIMcontrol. Please reach out to our team for single-IMSI network list and data pricing per country.

____________

TECHNICAL RECOMMENDATIONS
How to ensure proper device interworking with a Multi-IMSI SIM solution.

Device Requirements and Recommendations

Device should have a 3 minute minimum active period:

• IMSI rotation may fail if this isn’t ensured. Sleep mode (or disabling modem) in between will disrupt the IMSI rotation sequence.
• This minimum threshold may be higher for devices which need to scan different NB-IoT/LTE-M bands. In this case, we recommend fine tuning your device by reducing the number of bands scanned.
• Device (terminal and modem) should support STK (SIM Toolkit Application) protocol:
• Release 99 implementation is mandatory, in order to ensure successful applet logic.
• IMSI rotation will fail if support of this application is not guaranteed.

What is STK?

STK stands for SIM Toolkit Application. This protocol is specified by:

• 3GPP TS 11.14 (v8 / Rel99).
• 3GPP TS 31.111 (includes USIM Application Toolkit for 3/4G networks).

STK support in devices is mandatory to handle Multi-IMSI solutions.

Which commands within the STK are used for the Multi-IMSI solution?

Multi-IMSI applet is relying on the following standard STK Proactive commands:

• Setup Menu
• Provide Location Info
• Timer Management
• Refresh

Full details of the functioning of commands above can be found in both specifications 3GPP TS 11.14 and 3GPP TS 31.111.

Under which conditions will the Multi-IMSI applet will trigger an IMSI rotation?

Device will be forced to reboot and use a new IMSI identity after a 2 minute period when:

• Network attach is rejected by all networks with the current IMSI (e.g. none of the available networks in this location are allowed in the Roaming Profile with the current IMSI).
• Device lands in a new country where the priority IMSI isn’t currently active.
• The SIM card being notified that the network has “Limited Service” (timeouts during the Authentication procedure or poor coverage for a extended period of time).

My device is unable to switch IMSIs

This can be caused by one of following reasons:

• Active period of the device is shorter than 3 minutes.
• Unexpected STK call flow between device and applet.
• Modem is not supporting STK or debugging mode is active.

What is the forbidden PLMN list and how does it impact network searching?

The forbidden PLMN list is dynamically stored in the SIM and maintained by the device. When a device attempts to connect to a network and is denied, it will insert that network to the fPLMN list, thus preventing it from attempting to connect to the same network again.

If all available networks are added to the fPLMN list, the only way to ensure the modem will keep trying to connect will be to either make manual registration attempts (possible in phones but very unlikely in IoT devices) or clean the content of the fPLMN list.

The BICS Multi-IMSI applet will clear the fPLMN list content after every IMSI rotation.

Which network will my device choose to connect to?

The first time a SIM attempts to connect in a country, if no other preferences are explicitly set, a device will choose based on the signal strength coming from all the available networks. If the strength is better than -85 dBm, a network will be chosen randomly, if the signal strength is lower, the network with the highest signal strength will be selected.

Remark: Networks contained in the forbidden PLMN list will be ignored by the modem during this phase.

For subsequent connections, the SIM will normally instruct the device to register under the last used network (and with the same technology), minimizing the registration time.

Inside a country, BICS is not steering to any specific networks, apart from the screening based on the SIMs Roaming Profile (i.e. which networks are allowed).

How to optimize the network scanning?

Band scanning for LWPA technologies as NB-IoT/LTE-M (currently not available in most African countries) is very time consuming, at 2 minutes per band. In order to optimize the network registration, it is recommended to pre-configure the device by reducing the scanned bands to the minimum required needed for the region:

• Asia: B3,B8
• Europe: B3, B20
• North America: B4,B12
• South America: B4,B28
• Africa: B3,B8
• Oceania: B3,B28

It is also possible to prioritize a RAT over the others via the device configuration.

Why is the initial attach to NB-IoT sometimes taking very long?

Some devices (i.e. Quectel BG95/96), while being configured to search only for NB-IoT radio access, are experiencing long delays to perform the initial network attach. This may happen within auto-selection network mode, when a SIM card isn’t instructed to connect to a specific network.

If the outcome of the required connectivity tests is showing this misbehaviour, it is recommended to use a manual network selection setup, while taking into consideration the static nature of NB-IoT devices and that coverage offered by BICS is subject to change.

What other best practices are recommended to optimize the device behaviour?

Recommendations we advise to firmware and app developers for an improved service:

• The fPLMN list should be cleared by the device after every power cycle.
• Pre-configured APN (flickswitch, bicsapn)
• Perform manual network attach when device is out of service for an extended period of time.

What is a LPWAN device?

LPWAN Devices are made to optimise battery consumption, meaning they will trigger sleep mode to minimize the time a device is active.

Sleep mode will be initiated not only by PSM/eDRX modes inside the network, but also by the upper application on the device. In order to ensure that network registration can occur, a device should stay active for at least 3 minutes after the initial registration to the network.

TROUBLESHOOTING

My device is up and running but it’s not trying to connect to any network

This can be caused by one of following reasons:

• Full fPLMN list.
• To solve this situation, it’s highly recommended to have means on the device to clear the forbidden PLMN list periodically, like this new registration attempts will occur, and eventual IMSI rotation will be triggered.
• Out of coverage.
• Stuck on an IMSI without available networks.

My device is attached but it cannot exchange any data

This can be caused by one of following reasons:

• APN isn’t configured, hence data session isn’t created.
• APN in the device isn’t aligned with the APNs present in the APN group.
• Network interface isn’t associated to the EPS bearer.
• Under NB-IoT/LTE-M, can be due to VPMN policies.

Android devices: Auto-APN assignation

Within the different OEMs powered by Android, and also between different OS versions within a same brand, we could expect a variety of the APNs that will be automatically loaded by the device whenever a BICS SIM is inserted:

• Google root Database may be overwritten by OEM customisations.
• While changing from one profile to the other among the ones implemented within our SIM solution, those APN settings may change.

Those scenarios above may lead to a service disruption, therefore it’s a clear ambition on BICS to approach the different OEMs in order to harmonise that APN assignation.

My device is connected but it doesn’t receive SMS

In order to be capable of receiving an SMS the device needs to be attached via the proper leg (MSC/VLR). This is guaranteed for all smartphones but not for all IoT devices. Scenarios where this won’t happen are listed below:

• The device doesn't support SMS and is made to be data-only.
• LTE-M/NB-IoT devices without 2G support (SMS via SGd interface towards MME isn’t yet a reality for the vast majority of networks)
• Per configuration, the device is in datacentric mode (PS attach only). Please ensure then that CS/PS attach is configured

Device user data may have a limited lifetime - Timers in CGNAT while going to Internet

Most typical IoT use case consists on devices sending data towards servers accessible in the public Internet. On that scenario, CGNATs within BICS network are leveraging that communication, by mapping private to public end-user IPs. In order to keep a robust and properly dimensioned service, we are defining a default profile that limits duration of those sessions when they become idle. 

Current policy is as below:

• Default profile: TCP – 300 secs, UDP – 300 secs, AnyIP - 60 secs.

This default profile is applicable for all APNs by default.

Since it’s a natural behavior in IoT ecosystem not to have a continuous flow of data but rather a periodic sampling one, we depict below the potential impact one can expect:

• If TCP session needs to be re-created (data sampling period above the thresholds), there will be extra control messages and headers to send same amount of payload.
• Be also aware that CGNAT won’t be the only element in the flow implementing those profiles (i.e. 600 secs for TCP sessions is quite common in servers exposed to public Internet).
• Advanced IoT protocols are MQTT/CoAP are optimized on this sense, since they keep connections up via a heartbeat mechanism.

A2P SMS Coding schema: device isn’t reacting properly to commands

Some IoT devices aren’t supporting all coding schemas for SMS, meaning that the text inside an SMS may not be properly interpreted. Therefore, one should bear in mind that currently, A2P campaigns towards an endpoint are following the approach depicted below:

• A2P SMS tool in SFT Portal will use per default UCS2 schema.
• A2P SMS API will provide enough flexibility to choose specific coding schema among 7 bit alphabet (GSM), 8-bit data and 16 bit (UCS2).
• SMS Alphabets: Difference among popular OEMs while decoding
• While sending A2P SMS, different schemas to encode the data are available:
• GSM 7-bit: The default alphabet as per of 3GPP definition (TS 23.038) that contains most commonly used letters and symbols in many languages into a 7-bit representation for use on GSM networks. Starting from release 8, national languages can be supported by using Shift Tables.
• GSM 8-bit: Utilizes an extra bit allowing the sender to add UTF-8 encoded characters. Unlike GSM 7-bit encoding, which is used for text messages and supports a limited character set, GSM 8-bit encoding treats the information as raw data, leveraging the sending of non-text data such as ringtones, operator logos, or WAP push messages.
• UCS-2: each character is represented by a fixed length of 16 bits (2 bytes). This encoding can represent up to 65,536 characters, covering a wide range of languages and symbols, making it suitable for emojis, special characters, etc.

However, due to varying behaviors of different OEM implementations, it comes that decoding may not be always smooth and consistent for all devices:

To ensure consistency, our recommendation is to stick to GSM 7-bit encoding whenever possible, to ensure all endpoints receive the same content.