Navigating the Profile Download of the IoT eSIM Spec

Update: Watch our free webinar on the IoT eSIM!

In the first article of the IoT eSIM Diaries, we looked at the architecture and key benefits of the new specification. If you understand the architecture and components, it's only logical to look at the profile download process next.

In this blog post, we'll look at the different methods for downloading profiles described in SGP.32.

It used to be quite simple: the M2M variant followed the push model, in which a new eSIM profile was pushed onto the Embedded Universal Integrated Circuit Cards (eUICC). The consumer standard, on the other hand, follows the pull method, in which the smartphone user initiates the profile download.

The new specification describes two primary methods for downloading profiles to eUICCs in IoT devices:

1. Direct profile download
2. Indirect profile download

Both methods support different scenarios, such as using an activation code, SM-DS assistance, or relying on a configured default SM-DP+ address in the IoT Profile Assistant (IPA). If you're familiar with SGP.22, the consumer specification, these scenarios should look familiar.

To summarize, we can say that the new IoT eSIM specification provides eight different scenarios for profile download depending on the starting point:

• Direct Profile Download Variants

• Assisted by eIM Using Activation Code
• Assisted by eIM Using SM-DS
• Unassisted by eIM Using SM-DS
• Unassisted by eIM Using Default SM-DP+

• Unassisted by eIM Using Activation Code

• Indirect Profile Download Variants

• Assisted by eIM Using Activation Code
• Assisted by eIM Using SM-DS

• Assisted by eIM Using Default SM-DP+

To discuss the differences between direct and indirect downloads, we must first understand the role of the eSIM IoT Manager (eIM) in the profile download process. As the last blog post mentioned, the eIM is a new component introduced with the IoT eSIM specification.

The role of the eIM differs significantly between the direct and indirect profile download process.

With the direct method, the eIM only initiates the profile download process. In the indirect method, on the other hand, the eIM is at the center of the entire download process and facilitates most communication and authentication processes between SM-DP+, SM-DS, and IPA.

Therefore, the definition of direct or indirect depends on what part the eIM plays in the profile download process. If the IoT device can perform the communication and authentication process itself and communicates directly with the SM-DP+ or the SM-DS, it's a direct profile download.

When it comes to a network-constrained IoT device with low processing power, the eIM can play an important intermediary role, and therefore, the process refers to indirect profile download.

Direct download involves fewer steps and is less complex but requires a more powerful IoT device. On the other hand, indirect download requires fewer demands on the IoT device but places more responsibility on the eIM.

By embracing the work and complexity, a well-developed eIM should enable the mass adoption of IoT by simplifying the management of tiny sensors and smart meters.

Next, let’s look at the download process as a whole, as it has many similarities regardless of how the process is initiated.

1. Initiating the profile download via the activation code, the default SM-DP+ or SM-DS, and eIM (if applicable).
2. Establishing secure connections between IPA and SM-DP+, SM-DS, and eIM (if applicable).
3. Common mutual authentication between the eUICC, IPA, and SM-DP+ or SM-DS involving eIM (if applicable).
4. The SM-DP+ prepares the Bound Profile Package for download.
5. The IPA receives the Bound Profile Package and loads it to the eUICC.
6. All systems, including Operator’s M(V)NO endpoint, are notified of the profile installation.

How is this process better?

Compared to M2M, the profile download process is much more efficient and streamlined.

Instead of creating a profile and submitting it to a suitable M2M’s SM-DP or performing the external SM-DP integration via the ES3 interface, companies can now obtain an activation code from a new network operator whose services they wish to use.

At 1oT, we designed several scenarios for different use cases when developing the eIM.

The eIM must support profile downloading in large quantities, the so-called bulk campaigns. Users can insert activation codes into the eIM for bulk profile downloads over API from network operator systems or through a file upload via a secure channel.

There is also the option to use a campaign activation code that applies to a range of ICCIDs or specific eSIM profile type.

Users can enter activation codes manually as we're also developing a web application to manage the eIM. I may be wrong, but we don't see much benefit in this for large deployments.

When standardized IoT eSIM solutions become available, IoT device manufacturers and service providers will invent new applications. Since we can’t foresee the use cases, we will develop things so enterprises can start innovating and later add or remove features to provide the best user experience.

In the following article, we will look at the eIM, what types of operations there are, how companies can use the eIM, and the exciting changes it brings to the telecommunications market.

If you are interested in experiencing this technology firsthand, you can join 1oT's eSIM SGP.32 mailing list.