Do-It-Yourself eSIM RSP (part II)

GSMA have defined three different eSIM architectures. Initial demand came from the M2M industry and led to the SGP.01 standard for M2M devices in 2013. The standard SGP.21 for consumer devices was released in 2015. The latest standard SGP.31 for IoT devices was published in 2022, addressing shortcomings of the initial M2M standard. In this post we show a brief overview of each architecture.


Managing eSIM for M2M devices with SM-DP and SM-S

The GSMA M2M architecture (SGP.01) is a server-driven push model that enables the centralised management of eSIM devices and profiles and involves two system components. The SM-DP (Subscription Manager Data Preparation) represents the profile owner and manages the download of MNO profiles. It securely encrypts the network access credentials (i.e., the profile) and manages the remote provisioning process.


The SM-SR (Subscription Manager Secure Routing) oversees eSIM management and represents the eSIM device owner. It is also the entity that securely delivers the encrypted MNO profile to the eSIM and manages it remotely over its lifetime using a specific set of operations, such as profile activation, deactivation and deletion.


Managing eSIM for consumer devices with SM-DP+

The consumer architecture (SGP.21) follows a client-driven pull model that gives control over remote provisioning and local management of the profile to user of the device. The solution consists of the SM-DP+ (Subscription Manager Data Preparation plus) for the creation and protection of MNO profiles and a specific application on the device, the LPA (Local Profile Assistant) that manages the communication between eSIM and backend.


The optional SM-DS (Subscription Manager Discovery Server) enables automated profile discovery, if selected as an activation method by the Mobile Network Operator.


The best of two worlds – introducing SM-DP+ for IoT devices

The architecture designed by GSMA for M2M (SGP.01) often creates difficult commercial scenarios that stand in the way of effective integration. For example, the SM-SR as the lifecycle manager of an eSIM, needs to integrate with SM-DPs of various MNOs before their profiles can be made available. It can make deployment and operation of a GSMA-compliant RSP system for M2M complex and expensive, contributing considerably to its low uptake within the cost sensitive IoT ecosystem.

In addition, the M2M specification requires SMS and HTTPS communication protocols that have compatibility issues with popular IoT technologies like NB-IoT and LPWA, which usually demand IoT-specific light weight protocols for maximum energy efficiency. The need to overcome these limitations as well as the much greater success of the Consumer RSP specification have driven GSMA to create the SGP.31 standard that defines the following architecture:


While relying on the market-proven components SM-DP+ and SM-DS, SGP.31 introduces a new component in the RSP architecture, the eIM (eSIM IoT remote Manager). It manages the eSIM and profile states remotely, including initiation of profile download requests directly from SM-DP+ or via SM-DS. Additionally, the eIM can take the role of a protocol converter for network constrained devices that do not support HTTPS communication and eSIM devices can be easily associated with different eIMs over their lifetime. As in the consumer solution, a special application is required on the device to manage the communication between eSIM and backend. This is the IPA (IoT Profile Assistant), with the capability to manage the eSIM using a remote system instead of a human user as the major difference to the consumer architecture.

Although there is no doubt that the initial M2M standard will remain available for the foreseeable future, not least due to a significant amount of legacy deployments, it seems equally clear that the future of cellular IoT connectivity will be managed along the principles described in this new standard.


In the next post we describe the components required for an eSIM RSP Management service.

Go back