Update: Watch our free webinar on the IoT eSIM!
Welcome back to the latest update on our journey to IoT eSIM.
Since the last update, we have news regarding the eSIM IoT Remote Manager (eIM). The GSMA’s SAS group recently published the latest version of the SAS documentation, confirming that eIM falls within the scope of SAS-SM. This means the eIM has the same physical and logical security requirements as the existing SM-DP, SM-SR, SM-DP+, and SM-DS platforms in the RSP M2M and Consumer variants.
In today's update, we also focus on eIM. Last time, we discussed the different download methods defined in the IoT eSIM specification, with eIM playing a pivotal role in determining whether it is an indirect or direct download.
Today, let's review the functions of eIM and study its role in the IoT eSIM architecture.
To delve deeper, we see four interfaces connected to the eIM, each playing a particular role:
Each interface is crucial for the profile download process, but it's essential to understand that an eIM must be associated with an eUICC to perform any operation.
The associated eIM stores eIM Configuration Data, which the eUICC uses for verification to respond to commands, preventing unauthorized control or misuse of eUICCs.
Let's consider when and how to associate an eIM with an eUICC.
The GSMA spec SGP.32 outlines scenarios for associating an eIM with an eUICC, leaving room for implementation details.
From our perspective, there are three use cases:
The current eIM (eIM_A) associates the eUICC with a new eIM (eIM_B).
We believe the first scenario will be the most common. Cellular connectivity providers source eUICCs to sell to IoT enterprises, associating them with the provider's eIM.
Additionally, a large multinational company may have its own eIM and request that eUICCs be manufactured with the provider's connectivity but paired with their eIM.
Who controls the eIM is crucial because replacing an associated eSIM requires adding a new eIM. Deleting the old eIM is optional, as eUICC can be associated with multiple eIMs. Still, the current eIM owner (perhaps an MNO) must allow the IoT enterprise to associate a new eIM with the eUICC.
I'll discuss profile swap scenarios later, but first, we'll see why eIM ownership is crucial. At the very least, you should have clear agreements on how the eIM can be used by the IoT enterprise to prevent misunderstandings.
If the IPA can execute an “EuiccMemoryReset” function, this is a workaround to overcome a possible eIM lock-in. This function resets the eIM Configuration Data in the eUICC and frees it from the previous eIM association. The eUICC can then be associated with any eIM, but only via the IPA — the second scenario mentioned above.
To add context to the third scenario, eIM configuration operations (referred to as eCO) include:
In addition to eSIM configuration operations, eIM triggers profile downloads and profile state management operations (PSMO).
These operations include actions from the M2M eSIM variant, such as activating, disabling, and deleting the profile on the eUICC.
In a previous article, we explored methods for downloading profiles. To recap, the eIM can initiate a download in three ways:
by asking the IPA to contact SM-DS
We believe activation codes will be the primary way to activate a new telecom profile, as mentioned before.
The default SM-DP+ is useful for initial connectivity but has limitations. Using an SM-DS is not very popular, even for consumer eSIMs (SGP.22), because it requires significant coordination from device and cellular module manufacturers.
Let's start downloading a profile from an SM-DP+ using the activation code.
You can switch to another connectivity provider in two ways:
If commercial terms and agreements aren't crafted suitably for IoT enterprises seeking flexible, future-proof cellular connectivity, there is a small risk of vendor lock-in.
To switch network operators, you need to start with a new connectivity management platform, such as integrating new APIs, setting up automation rules and notifications (if available on the platform), and so on.
Now follows a quick self-promo of 1oT.
As an IoT enterprise, you want to avoid dealing with multiple network operators or connectivity management platforms, so an independent middleman who coordinates and manages complexity is crucial.
That's why we integrate eIM functionality into our eSIM management tool (supporting M2M eSIM, SGP.02) in the 1oT Terminal. This lets us give customers a wider choice of network operators and enables them to bring their own connectivity deals under the 1oT Terminal umbrella.
As eSIM integrations become easier and easier, we focus on our mission to provide integrations with various network operators so that everything can be managed through the same platform.
Join 1oT's eSIM SGP.32 mailing list to stay updated with our blog series and learn about our process of developing the new IoT eSIM spec.