The use of eUICC/Remote SIM Provisioning will hit 2.4 billion IoT devices in 2032, with SGP.32 IoT standard (eventually) dominating
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 article we explore the drivers of adoption and the evolving dynamics of cellular-based IoT connectivity that will stem from this evolution.
Driven by SIM form-factor changes
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.
Remote SIM provisioning standards
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.
Other approaches: non-standard and non-RSP
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.
Forecast: eUICC/RSP standards accelerate, shift from ‘M2M’ to ‘IoT’
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.
Consider a ‘Connected-by-Design’ approach spanning all of IoT
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’.
Product Manager - Keynote Speaker - Board of directors - Challenger
1yHi Matt - great report as always - as a product manager of connected devices it is to me rarely the technology that prohibits me from selecting one over the other but the commercial model - DM me and we can discuss my arguments for future analysis
Digital growth strategies - Edge Artificial Intelligence & Digital Twin Expertise
1ySagar Shah
Business Development Manager - Solution Sales (Connectivity & Security) chez Avnet Silica
1yThanks Matt, for those insights. I think there are also others points to be considered between SGP.02 and SGP.32/33. More on the business side: 1. SGP.02 should be seen as an insurance model, if you need a SWAP you pay for it, if you don't, you don't pay (At least, this is how we see and market it at Avnet Silica) 2. From the various exchange we have with several SGP.33 future provider, there will have a subscription attached to the use of the SGP.33 on top of the connectivity subscription to be consider on customer business model 3. As of today, even thought a lot of IoT customers think they need this SGP.32/33, they do not consider the fact they will lose negotiation weight with operators if they are splitting their volumes with 5 or 7 providers compare to 1 or 2 as of today. Here I'm only talking about business quires... From what we've seen so far there are lot of to be done on the technical side as well. It doesn't seems to be as straightforward as promised on the paper...