Historically, the SIM Operating System (OS) contained all the functionality and essential services. However, with the growing need for retaining subscribers, carriers have begun offering additional value-added services. As the value-added services were highly customized to a specific carrier's use case, the SIM manufacturers had to figure out how to offer such services on top of the basic features. Therefore extra features and services were moved to standalone units called SIM applets.
SIM applets are small programs inside your UICC or eUICC dedicated to fulfilling a particular task. Simply speaking, SIM applets provide a way to talk to the SIM card directly and build features independent from the standard carrier offerings. Applets can be useful for consumer value-added services like mobile banking or ID verification, but they can be even more useful for IoT/M2M devices.
A SIM applet can report diagnostic data about network quality, device status, or even fulfill the tasks of a microcontroller. With the increasing demand for M2M/IoT, the need for different SIM apps has become a hot topic once again.
Applets are based on Java Card, a limited subset of Java language. The SIM cards operating system (OS) is similarly written in Java Card. The OS is the first and most important SIM Applet.
After compiling the code, you will end up with a .cap output file that can be loaded onto the SIM or carrier profile using commands detailed in the Global Platform Card specification. Depending on the applet and available infrastructure, loading can be done Over The Air via an OTA server or at the time of manufacturing. An OTA Server uses a variation of either SMS or HTTPS messages for the update process.
There are different possibilities where and how to store the applets — each with its own advantages and disadvantages.
Firstly, applet functions can be embedded into the OS itself. This increases the OS size and comes with OTA update restrictions and needs to be done while manufacturing the cards. It is not suitable for all applets, but there can be certain use cases where this approach might be needed. More on that later.
The second possibility is that SIM applets are stored in profile Security Domains (SD). This is the most common approach, but it means that applets are profile specific. And carriers have all the power to decide which applets can be used with their profile. Another problem is that with eSIM (eUICC) or multi-IMSI SIM (multi-IMSI UICC) you can have multiple carrier profiles on one card, but with changing the profile the applets are also changed.
The third solution for storing applets is to store them in a third party application space that can interact with carrier profiles. This solution is not yet released but is in the process of being standardized. The main advantage of this solution is that applets would not be embedded into the OS and would also not be profile specific — perfect for eSIM (eUICC) use case.
Soon you will be able to change the profile without having to think about what happens to your applets.
For an applet to be able to carry out specific actions, it needs to be able to communicate outside of the secure SIM element. This is done using predefined and standardized commands in the SIM Application Toolkit (SAT).
For a cellular module to understand and accept these commands, it needs to support SAT commands. SAT is supported by 99% of today's cellular hardware and is most often also enabled by default. If not, enabling is usually done by a simple AT command. For many uBlox modules, the Toolkit is activated with AT+CFUN=6 command (enabling the SIM-toolkit interface in dedicated mode and fetching of proactive commands by SIM-APPL from the SIM-card).
The SIM card gets locked onto one specific device using its IMEI number. This can be accomplished in two different ways. Either by locking the SIM card to the device it has been inserted into first or by manually assigning an IMEI number via OTA update. Also, the applet can be configured to send notification on change of device.
Every SIM has an amount of reading and writing cycles it can handle. With consumer use cases this has never been a problem, but misconfigured machines can achieve unconventional amounts of these cycles. SIM health reporting will help identify abnormal behavior and proactively warn for a possible SIM failure.
The SIM card monitors Cell ID, Signal Strength, Neighbouring cells, and a lot more to compile analyze of the network quality. This is valuable information to decide on a network to use.
The SIM itself can be geofenced not with GPS, but using Cell ID. A fence can be put to one cell only but also larger areas like one city. A geofence applet can be set up to notify or even shut down the SIM once it attaches to a cell tower that is out of the geofence range.
IoT/M2M devices that are inefficiently programmed or misconfigured can cause network congestion risks due to many devices starting a network session simultaneously and continuously. This will overload networks and result in devices not being able to establish a connection. To overcome the issue, a SIM applet can randomly generate a delay after it has had consistent unsuccessful connection tries. The random delay across a fleet of devices will make sure that not all are connecting at once and help solve network congestion.
With the recent rise in security demands for devices, software authentication is more important than ever before. The applet will protect the server authentication credentials (RSA / ECC keys, session keys) by storing them on the SIMs secure element. A SIM itself has proven to be tamper-proof and rather then implementing a separate hardware secure element on your device it's cheaper, safer, and easier to use the already available SIM secure element.
Tier 1 operators are reluctant to allow applets to be loaded onto their profiles. As discussed in the use case section applets can give valuable insight into the network quality. For operators, this means that everyone running the applet on their profile can monitor their network quality and this is something that many Tier 1 operators are reluctant to allow. To overcome this reluctance the 3rd party applet space on the eUICC would be a solution but until now it has been held back and it's not approved yet.
1oT is looking forward to the release of 3rd party applet space on the eUICC. Until then, we host our applets on carrier profiles. We are providing applet based features through our SIM management platform Terminal, where you can activate applets in addition to all other services with one click based on your needs.