The number of eUICC/Remote SIM Provisioning (RSP) capable cellular-based IoT connections will grow from 240 million (16% of installed base) to 2.36 billion (40%) between 2022 and 2032, according to the new report from Transforma Insights, ‘Over 2.3 billion cellular connections will be eUICC/Remote SIM Provisioning (RSP) capable in 2032’.
In this blog post we explore the drivers of adoption and the evolving dynamics of cellular-based IoT connectivity that will stem from this evolution.
Until 2016, cellular connected devices were authenticated onto a network using a removable plastic SIM card. This wasn’t particularly appropriate for many IoT use cases, which required a more ruggedised form factor, and the security of being fixed into the device. The Machine Form Factor (MFF, now MFF2) was launched, comprising a chip to be soldered onto the circuit board of the device. This further evolved with the advent of iSIM in 2018, which saw the SIM application moved onto another processor as a virtual element.
As a result of this change in the physical form factor, it was necessary to develop the capability to change the SIM profile through a mechanism other than physically swapping out SIM cards. That mechanism is Remote SIM Provisioning (RSP), i.e. remotely over-the-air switching of profiles on the SIM card without needing to access it physically. This is another additional benefit of embedded SIM, i.e. removing some of the logistics headache of managing connectivity on devices as they are deployed, although it is not an exclusive feature of embedded SIMs.
RSP will be dominated by the standards developed by the GSM Association (GSMA). The first two standards for eSIM architecture were developed as SGP.02 (“M2M”) and SGP.22 (“Consumer”). SGP.02 was introduced in 2014 and SGP.22 in 2016, with a lag of a few years before widespread commercial deployments.
The SGP.02 M2M format is a ‘push’ model whereby changes of eSIM profiles are taken from the SM-DP (Subscription Manager – Data Preparation) and pushed to the SIM by the SM-SR (Subscription Manager – Secure Routing) element that controls it. The challenge with SGP.02 is that it requires cooperation between the subscription management infrastructure of the donor and the recipient networks in order to handle the hand-over. For the network operators there is little incentive to do this. In contrast, the Consumer form uses a ‘pull’ approach with the profile pulled directly from the SM-DP. This approach, however, requires the device to have a more sophisticated UI and a camera (to photograph QR codes), as well as manual intervention to activate the process.
Technical specifications of a third variant, SGP.32 (“IoT”), were finalised by the GSMA Working Group 7 in May 2023, and await finalisation of the associated testing and certification standard (SGP.33), and compliance procedures, at the GSMA. This is expected to be completed by February 2024. Device vendors expect production of SGP.32 compliant devices by the second half of 2024. Compared to SGP.02 it removes some of the business inflexibility and lock-in. With the SM-SR/SM-DP format it was necessary to integrate between subscription management platforms in order to move connections between operators. Moving between them was difficult. In contrast, with SGP.32 there is no need for integration between the two.
Our experience from speaking to stakeholders in the space is that the SGP.02 variant is seen as being somewhat yesterday’s technology. It won’t disappear over-night for several reasons: there are existing deployments, there’s no direct upgrade path to SGP.32, and SGP.32 products are still 18 months from being available. Many are hesitating to upgrade their current M2M version because of the anticipated switch to IoT. However, we also note that several mobile network operators have expressed concerns that SGP.32 represents a significant loss of control for them over managing the customer connection. Support is unlikely to be wholehearted unless enterprise customers demand it.
We should also note, that in addition to these three standards, there are also two non-standard approaches to RSP. Before the availability of the SGP.02 M2M standard, there were a number of implementations of an equivalent capability that were developed as pre-standards by the SIM vendors, mostly to support the demands of automotive OEMs. These lacked interoperability between operators but were useful for initial localisation. These either imitated the SGP.02 (i.e. provider initiated) or SGP.22 (i.e. user initiated) approaches, and in many cases are barely differentiated from the standard.
We should also note that most IoT connections will not have any eUICC/RSP capability over the forecast period. This includes single IMSI SIMs deployed, for instance, by a single carrier in a single market. Or using roaming rather than localisation for supporting connectivity in multiple territories. Multi-IMSI devices also count in this category, although many multi-IMSI offerings include eUICC too (and would therefore be counted by Transforma Insights in the appropriate RSP-capable category). Collectively these non-RSP-capable approaches account for 80% of connections today.
The split between the various types of SIM provisioning are presented in the chart below, as forecast in the report. Over the next decade we will see a significant migration towards the use of RSP standards. The use of a single domestic IMSI will continue to be the most significant, but RSP-capable devices as a whole will increase from 16% of base to 40%. Within that, the standards will dominate.
The Consumer standard grows only relatively slowly as its limitations mean that it will largely be focused on a relatively small set of device types, i.e. consumer electronics. The M2M variant will continue to be relatively strong, only tailing off a little towards the end of the forecast period as it makes way for IoT. For many use cases, and for MNOs, the degree of control within SGP.02 M2M is a valued asset, that they will not necessarily wish to give up by shifting to SGP.32 IoT.
Non-standard variants hang around for quite a while, simply because existing deployments use those technologies and it takes a while for devices using legacy technologies to churn out of the installed base.
The use of eUICC/RSP is just one of many technology choice related to IoT deployments. It is very important that organisations developing IoT solutions do not simply try to bolt on their connectivity choices at the end of the development process. Considerations of which technologies, protocols and architectures to use, and how they will work together, will need to be permeate the whole development process. Transforma Insights calls this approach ‘Connected-by-Design’. It was the subject of a recent report: ‘Connected-by-Design: Optimising Device-to-Cloud Connectivity’.
