Device Requirements and Recommendations
How to ensure proper device interworking with a Multi-IMSI SIM solution?
Device should have a 3 minute minimum active period:
o IMSI rotation may fail if this isn’t ensured. Sleep mode (or disabling modem) in between will disrupt the IMSI rotation sequence.
o 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 SIM Toolkit Application protocol:
o Release 99 implementation is mandatory, in order to ensure successful applet logic.
o IMSI rotation will fail if support of this application is not guaranteed.
What is Multi-IMSI solution?
Multi-IMSI stands for Multiple International Mobile Subscriber Identities. A SIM card containing multiple IMSIs enables subscribers to switch carriers as required and connect to significantly more networks: 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 therefore an essential feature for global deployments of IoT solutions.
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.
Our 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 customer’s Roaming Profile or blacklisting.
Within the default Roaming Profile inherited from BICS, SFT customer has the possibility to customize their own profiles, removing/blacklisting any of those networks.
How to optimize the network scanning?
Band scanning for LWPA technologies as NB-IoT/LTE-M 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 (bicsapn, asia.bics, america.bics etc).
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.
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.
Use of a private APN on customer premises
Using a private APN is leveraging several use cases for a SFT customer, i.e. subscribers may be connected to Customer DCN instead of the regular Internet path. Nonetheless, in such scenario the settings have to be adjusted by the customer itself in order to ensure the proper APN is used:
IoT devices should be pre-configured on that sense (AT+CGDCONT=1,”IP”,”privateApn”).
For smartphones, a manual setting is required to persist privateApn over the ones that could be auto-loaded by the OEM.
Apple devices: BICS Carrier Bundle
Since iOS/iPadOS 17.1 version (released in October 2023), SFT SIM cards will be automatically recognized by Apple devices, loading our operator bundle:
APN auto-configuration: bicsapn.
“Data Roaming” toggle doesn’t need to be manually enabled to initiate a data session.
eSIM menu is branded.
BICS label within the Data Mobile settings.
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 our SFT SIM is inserted:
Google root Database may be overwritten by OEM customizations.
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 harmonize 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. These timers are obviously not applicable for APNs meant for private connectivity (that traffic isn’t doing breakout via Internet).
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, except for private APNs that can be requested/purchased. Therefore, a customized profile is still possible.
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:
Samsung follows the 7-bit GSM alphabet even for incoming SMS encoded with 8-bit, removing the most significant bit and decoding the resulting character.
iPhone is supporting 8-bit GSM and UCS-2 alphabets, including symbols, emojis and other special characters.
Other Android powered OEMs as Oneplus or Oppo seem to support 8-bit GSM alphabet.
To ensure consistency, our recommendation is to stick to GSM 7-bit encoding whenever possible, to ensure all endpoints receive the same content.
What is the Samsung Regional block?
Some Samsung devices don’t allow SIMs to function which belong to a different region to the one they are trying to operate in. A call (longer than 5 mins) using a different SIM provider (as BICS SIMs do not support voice service) will unblock the device.