eSIM (eUICC) is introducing possibilities which were not possible before. Yet, every innovation comes with technical aspects that need to be considered. In our eSIM Series, we have already covered how eSIM technically works. Also, we have learned that the two new main components for eSIM are Subscription Manager Data Preparation server (SM-DP) and Subscription Manager Secure Routing server (SM-SR). The first, SM-DP, is the database where carrier (telecom) profiles are stored. And the SM-SR handles the secure information passing between the server and the eSIM.
The SM-DP & SM-SR servers are crucial for successful Remote SIM Provisioning (RSP). Therefore, testing of this functionality is mandatory, but 1oT is not taking full responsibility for it. The main reason is that 1oT does not manufacture the eSIMs itself. Nor do we build the RSP platforms, which includes the SM-SR and SM-DP. We have collaborated with a trusted and acknowledged partner that does all of that. Our RSP platform provider has carried out these tests already. More so, they are entirely GSMA SAS* certified. So we can be sure of the functionality and interoperability and can focus on what we do best - gathering all market players under one roof for the full end-to-end eSIM experience.
Short answer - the hardware! An eSIM might work well with a Samsung handset, for example, that the RSP provider has used in testing, but IoT or M2M solutions won't be using a Samsung handset. We want to be confident that eSIM works with the cellular module our customers' IoT devices are using.
You might think that the differences between a classical Samsung handset and an IoT cellular module are minimal. But that's not the case. Popular IoT cellular modules from manufacturers (like uBlox, Quectel, SIMCom, etc.) might not support automatic APN, Bearer Independent Protocol (BIP) or other standard features which are expected in modern handsets.
The most critical requirement for the device is BIP. Without it, Remote SIM Provisioning will not work successfully. There are other requirements for the devices as well, and you can find them from this GSMA released document (Annex G).
It’s important to note that these requirements are also software dependent, attention needs to be paid to the software version the module is running. We have discovered that many older firmwares might not support RSP. On the other hand, also new updates can break RSP support. Extensive research and tests need to be conducted before running to update the software and 1oT can help you with that.
The obvious tool we need for testing is the cellular module itself. As an example, we will go with a device that supports BIP, this time the uBlox SARA-U201.
If you are not sure about your device, you can double check from the modem specifications. Check for Bearer Independent Protocol (BIP). Or for convenience, you can check from our list of BIP supported hardware.
While developing or prototyping, it's always good to start with an Evaluation Kit (EVK). They are easier to configure and also give some elementary feedback that might not be implemented or available on a prototype device.
The other tool that is very handy is a tracer tool to track the communication between the eSIM and the cellular module. These devices give the exact Application Protocol Data Unit (APDU) commands, which are then passed between the SIM and the device. The commands can be decoded, translated and analyzed.
Actually, there aren't many tracer tools to choose from. Three most common are Comprion MiniMove, UL Security Solutions SmartConnect and the Osmocom SIMtrace 2. While most tracer tools range in prices from 5 000€ to 10 000€, the Osmocom SIMtrace 2 is a community-based solution that only costs around 150€. Yes, you read that correctly, 150€, we didn't miss a zero at the end! For sure, the SIMtrace 2 is not as capable compared to others. But as long as it gives the APDUs, we can perform the translation and decryption of the commands ourselves.
Two weeks after ordering, the SIMtrace 2 finally arrived at our office. We were eager to jump right into using it. One thing to note is that the SIMtrace 2 doesn't come with dedicated graphical user interface software. Instead, Osmocom has provided a command line interface. Installing libosmocore with all preconditions took some time, but eventually, we got everything running smoothly. Next, we inserted the SIM, connected the probes to the device and started the trace. Waiting for the magic to take place.
But nothing. Not a single APDU was showing up and all we got was an error message that the device is unavailable. There must be an issue somewhere. Unfortunately, we weren't able to figure out the problem. Even after several emails back and forth with Osmocom.
So there was nothing other to do but to go with an alternative, a bit more expensive, solution. We decided to go with the UL SmartConnect and a few days the device arrived at our office. We installed the software, inserted SIM, connected the probes and powered it on. It worked, and the APDUs were traced!
For demonstration purposes, we tested the download profile command on the uBlox SARA-U201 cellular module. It is a GSM/HSPA module which supports quad-band (800,850, 900, 1900, 2100) frequencies.
Looking at the software, you will notice that there are not only the APDUs, but the UL software has already translated the raw data according to ETSI TS 102 221 v12.0.0 and 3GPP TS 31.102 v12.6.0. Meaning we end up with common English instead of just raw data!
The trace file includes a lot of information, and we are not able to go through everything it contains in this blog post alone. Instead, we will highlight a few basic and eSIM related entries.
The first entry we see says that the VCC or power was applied to the SIM. Not particularly exciting, so let's have a look at the second entry.
ANSWER TO RESET (ATR) is the first set of data sent from the SIM to the device. It provides information about the SIM card's capabilities. In our example, the raw data looks like this: 3B 9F 96 80 3F C7 82 80 31 E0 73 F6 21 57 57 4A 33 05 81 60 50 00 CB. But the UL software has translated it according to ETSI TS 102 221 v12.0.0.
Further down is the TERMINAL PROFILE entry. This get's a bit more interesting as the Byte 1 shows if SMS-PP download is supported and Byte 12 shows if BIP is supported. Both are needed for remote provisioning and the terminal, in our case the cellular module, is ready for eSIM commands.
Now let's head over to 1oT Terminal and start a new profile download to the eSIM. Monitoring at the same time the UL tracer tool we can soon see an ENVELOPE SMS-PP data download coming in. This marks the start of the new profile download. Now you might wonder why an SMS is coming for a profile download, as BIP is used to bridge barriers like HTTPS to make downloading profiles over the internet possible. The reason is that the SMS is sent to the device with a command to open the BIP channel, after which the download can happen through HTTPS.
During the download procedure, many packets are transferred between the device and the eSIM. For the exact sequence explaining the BIP communication between the cellular module and the eSIM have a look at SGP.11-v3.3 (Annex F).
At the end of the download is a FETCH function. It is used to transfer a close channel command from the eSIM to the cellular module. The FETCH is confirmed by a TERMINAL RESPONSE function which transfers a confirmation from cellular module to the eSIM.
We now have successfully downloaded a profile onto our eSIM. This was a quick look at how tracing communication between the eSIM and cellular module can give valuable information about the inner workings of the eSIM and cellular module.
In our example, the download was successful, but it's an especially useful tool if something breaks. For instance, we have seen issues opening the BIP channel because the same PDP context channel was already used and wasn't automatically closed by the cellular module. The tracer showed correctly that the channel couldn't be opened and it started a sequence of retries.
You can have a look at the SARA-U201 trace file yourself if you are interested in researching the communication process in more depth.
1oT has conducted tests with IoT and M2M cellular modules from different manufacturers while using different network access technologies. Throughout the tests, we have checked all Remote SIM Provisioning commands, traced the communication and have been troubleshooting all the issues. To conclude our findings, we have been publishing 1oT eSIM Test Reports to make it easier for everyone to start with eSIM. All the reports can be found in our eSIM Supported Hardware list or in the folder here. There are many modules waiting in a line to be tested soon.
If your module has not yet been tested with eSIM or you want us to perform a custom test with your IoT device, make sure to contact us at hacking [at] 1oT.mobi.
*GSMA SAS – GSM Association Security Accreditation Scheme.