The differences between consumer eSIM & M2M eSIM

We have been writing about eSIM a lot on the 1oT blog-sphere. Especially when it comes to how does eSIM work and what are the benefits of eSIM.

In this blog post, however, we’d like to focus on the differences between the existing eSIM platforms that can be found on the market today.

General Overview

Starting from the naming perspective, a Subscription Management solution is a general name that covers the entire eSIM ecosystem, including the corresponding remote subscription management servers.

Subscription Management solutions can be split into two variants:

• Proprietary systems. These are developed and deployed on the market by some of the largest device manufacturers or groups of mobile operators. Being an OEM’s proprietary solutions, they work only in a closed and isolated environment. They are also incompatible with any other Subscription Management system in terms of eSIM interoperability or back-end infrastructure integration.

• GSMA-compliant systems. Their main differentiating factor from the proprietary solution is their compliance with GSMA’s Subscription Management technical specifications. It allows for full interoperability and integration with other GSMA-compliant systems.

Today we are focusing on GSMA-compliant solutions in this blog, of which there are two separate variants existing today, with each one dedicated to its own market segment:

• M2M: targeting Industrial M2M and IoT devices, including cellular modules, sensors, trackers, meters and many other components, all applied in an industrial and non-end-user interactive environment.

• Consumer: targeting Consumer devices, like mobile phones, tablets and laptops, as well as Consumer IoT devices including wearables, and other IoT consumer electronics.

The different market targets imply independent design architectures, which are specified and documented in separate sets of GSMA’s technical specifications.

Summarising features discussed so far, they could be presented in the following comparison table.

GSMA-Compliant Solutions

Looking at both variants of the GSMA-compliant solutions from the high-level architecture, we can already clearly see some common as well as unique features in their designs.

Focusing on differences in this blog, there are separate back-end infrastructure platforms and linked to that, a different set of roles assigned to each of them:

• SM-DP and SM-SR for the M2M variant

• SM-DP+ and SM-DS for the Consumer variant
  
  

It has a fundamental effect on the type of used remote management model, with a direction of control in these models:

• Push Model in case of the M2M variant, which is the SM-DP/SM-SR servers driven option. This model relies on the back-end infrastructure of SM-DP/SM-SR for the execution of any eSIM profiles related to management operations.

• Pull Model in the case of the Consumer variant, with an eUICC/device client-driven option. This model puts a client, located either on an eUICC or a consumer device in the centre of control for any eSIM profiles management operations.

Looking further at the roles assigned to each of the platforms, we can see that for M2M variant there are 2 separate entities:

• SM-DP (Data Preparation) being responsible for secure storage of eSIM profiles and their subscriptions, their personalisation with required subscription data, and preparation for secure download and installation onto the eUICC.

• SM-SR (Secure Routing) being responsible for the establishment of a secure channel to each individual eUICC registered to the SM-SR, which later allows for passing remote management operations of download/install, enable, disable, delete, and other functions directly to the eUICC or eSIM profiles.

In the case of the Consumer model, we have:

• SM-DP+ (Data Preparation and Secure Routing) with both responsibilities covered in a single platform. Integration of two functions lowers the complexity of the entire solution and as an effect of shortening implementation time of the project. On the other hand, it does keep a fixed dependency between eSIM profile owner (Mobile Operator) and eUICC owner (Service Provider).

• SM-DS (Discovery Service) being a relatively new and optional add-on to the Consumer variant. It’s been designed for the temporary storage of SM-DP+ issued alerts addressed to specific eUICCs, and can act as a helper function in situations where SM-DP+ address is unknown to an eUICC. The route to a correct SM-DP+ can then be discovered thanks to the SM-DS, after an eUICC contacts it and finds out a pending alert. It could become really handy in the case of an open market and for second-hand mobile phones, which are sold without a valid SM-DP+ address assignment.

From an operational point of view, the differences in M2M push and Consumer pull models define how the eSIM profiles management operations of Download, Enable, Disable, Delete can be executed.

In the M2M and push model, these profile management operations can be run only from the back-end infrastructure side, that means either:

• from operator’s or M2M service provider’s business support systems integrated with their respective SM-DP and SM-SR platforms

• or directly from SM-DP or SM-SR servers.

In the case of the Consumer and pull model, which is initiated from the local device side. There are several methods existing today, including:

• QR activation code, arguably the most popular option, and the most reliable backup option if other more sophisticated methods fail. In its 2D barcode format, it contains a Matching ID number and SM-DP+ address, which are used for reaching a dedicated SM-DP+ server and downloading a dedicated eSIM profile package identified with the MatchingID.

• default SM-DP+ address activation, with an eUICC pre-provisioned with operator’s SM-DP+ address, mostly useful with the operator subsidised mobile phones market. It is a fully automatic activation and doesn’t require any interaction from the end-user except turning on the device itself.

• SM-DS activation, which might be handy in situations when an end-user purchases a mobile phone device and eSIM subscription separately.

In order to be able to handle eSIM profiles management directly from the eUICC and device, the Consumer variant architecture requires one more additional element which is Local Profile Assistant (LPA). LPA represents a local identity responsible for direct communication with SM-DP+, and it can reside either in the device (more frequent) or on the eUICC (less popular).

We can say that LPA serves as an entry point for all the end-user activities related to eSIM profile management, including:

• add profile (local operation name for profile download),

• enable, disable or delete a profile,

• set or edit profile name,

• list all locally available profiles.

These operations can be executed either from the mobile device OS level or an operator’s dedicated mobile app.

Again, listing recently discussed features in the comparison table.

From the entire solution’s security perspective, both variants are based on the Public Key Infrastructure (PKI). All PKI certificates defined within the solution have a validation chain whose root is a certificate generated by a Certificate Issuer (CI). The CI is a certification authority organisation appointed by the GSMA CI’s certificate. It acts as the sole trusted root for the purpose of authentication of all the system entities - eUICC, SM-DP+, SM-DS, SM-DP, SM-SR.

Also from the individual eSIM profile side, both solutions have approached similar security measures. With M2M variant, an owner of the profile protects certain operations on individual eSIM profiles through the management of policy update rules on both endpoints (eSIM profile with POL1 and SM-SR with POL2).

In the Consumer variant, it’s been expanded with a profile policy management mechanism applied on the SM-DP+, eSIM and eUICC side, again with the same goal of profile owners enforcing the conditions of use under which eSIM profile and corresponding services are provided.

More Comparisons

There are some M2M specific mechanisms that are present only in the M2M variant. They are:

• Fall-Back Mechanism - This mechanism shall be activated to recover from accidental loss of network connectivity with the currently enabled profile. In such a situation, the eUICC automatically disables the currently enabled profile (that just lost its own connectivity) and enables another profile with the set Fall-Back Attribute.

• Roll-Back Mechanism - Similar to Fall-Back in its nature. This is applied to revert the Enable Profile operation when a newly enabled profile’s connectivity fails, back to previously enabled profile. It forms an internal part of the enable operation procedure in situations of connectivity failure. It’s activated by default, and there’s no need for its configuration.

• Emergency Profile Operation - Allows for an automatic local switch to a specific profile assigned for emergency cases. Such an emergency call profile must comply with regulatory requirements and only provides the capability to make and receive emergency calls from a public safety call centre. It’s an important and highly demanded feature by the automotive industry to comply with eCall and local regulations.

• Profile Lifecycle Management Authorisation enables delegated authority to other M2M service providers. It allows the operator, who owns the set of eSIM profiles, to grant authorisations to an M2M service provider (who doesn’t own that set of eSIM profiles) for performing a strictly predefined list of operations (e.g. only Enable and Disable) or receiving certain notifications.

• Operator Notifications Configuration allows the operator to define which notifications it would like to receive for a dedicated set of profiles, whenever the status of these profiles has changed.

Conclusion

In this blog, we focused on the existing features in Subscription Management solutions designed according to GSMA specifications. They were developed with the intent to suit specific M2M or Consumer markets and meet their various needs.

Currently, 1oT offers a GSMA certified Subscription Management solution dedicated to the Industrial IoT and M2M markets. It is supported with dedicated eUICC products available in plastic and industrial form factors, and range of eSIM profiles from our carrier roaming partners.

Stay tuned for our Part 2 of the Consumer vs M2M eSIM blog post, where we will review and look closer at real-life eSIM deployment examples.