Spotlight Series
by Matt Hatton, Founding Partner at Transforma Insights
The SGP.32 (“IoT”) standard for Remote SIM Provisioning was unveiled in May 2023, promising a more streamlined and user-friendly mechanism for enterprises to manage the connectivity on their cellular devices.
In this article, based on a recently published Transforma Insights Position Paper, sponsored by Eseye, ‘Key considerations for Enterprises looking to adopt SGP.32’ , the report’s author Matt Hatton examines the reality of the availability and ease of deployment of SGP.32, and why it’s not a magic wand for cellular-based IoT.
What is Remote SIM provisioning?
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. The Machine Form Factor (MFF, now MFF2) or ‘eSIM’ was launched, comprising a chip soldered onto the circuit board of the device. This drove the development of 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. remote over-the-air switching of profiles on the SIM card.
What is SGP.32?
To ensure interoperability of RSP between mobile operators, the GSM Association developed a series of standards. SGP.32 is the third of those standards. Each of the three establish slightly different mechanisms for the user or owner of a device to change the SIM profile while the device is deployed in the field.
The SGP.02 “M2M” format, introduced in 2014, is a ‘push’ model whereby changes of eSIM profiles are taken from the SM-DP (Subscription Manager – Data Preparation), the profile store, and pushed to the SIM by the SM-SR (Subscription Manager – Secure Routing) element that controls the provision of the profile onto the SIM. The challenge with SGP.02 is that it requires cooperation between the subscription management infrastructure of the donor and the recipient networks to handle the hand-over.
In contrast, SGP.22 “Consumer”, which emerged in 2016, uses a ‘pull’ approach with the profile pulled directly from the SM-DP by the user, with the role of the SM-SR split between the SM-DP (or in this approach the ‘SM-DP+’) and the device itself, in the form of a Local Profile Assistant (LPA). In this scenario the ownership of the device is enough to manage the process. 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. This is fine for smartphones, but most IoT devices do not have any of those characteristics.
Technical specifications of a third variant, SGP.32 (“IoT”), were unveiled by the GSMA in May 2023. The SGP.32 “IoT” variant is really an adaptation of the Consumer SM-DP+ approach, allowing a customer to switch its IoT connections (theoretically) to any connectivity provider it chooses without recourse to the operator upon whose SM-SR it currently resides. It has four main relevant features:
Remote UI – The role of the LPA is now partially on the device as the IoT Profile Assistant (IPA) and partially hosted by the network operator or third party, in the form of the eSIM IoT remote Manager (eIM), allowing for the remote control of the IPA without need for manual intervention.
Support for lightweight protocols such as CoAP-based Lightweight M2M (LwM2M) to manage profile downloads and other operations – SGP.32 does not require support for TCP/IP, which is heavier than the UDP used in CoAP, and LwM2M that runs over it. This helps to overcome constraints on latency and bandwidth which are common with newer IoT connectivity technologies, particularly NB-IoT.
No requirement for SMS – NB-IoT devices often don’t support SMS, which was required for SGP.22.
A small footprint – Because much of the functionality of the LPA has been moved into the eIM it reduces the memory and processing requirements on the device itself.
The three approaches are illustrated in the figure below:
Time for a reality check
The capabilities introduced in SGP.32 mark it out as an improvement in many ways on the preceding standards. It also changes the commercial dynamics of how connectivity providers might be selected. Nominally the use of SGP.32 means that every enterprise customer with capable devices is dramatically more footloose than they were previously, with the ability to ‘at the click of a button’ move some or all their connections from one network to another. However, the reality is much more complicated. The focus of the recent Transforma Insights Position Paper is on examining the reality of the availability of SGP.32 and how it will be deployed.
The key considerations include:
Timing – Although the technology itself has been standardised, SGP.32 will not be truly available until 2025. The functional test specification (SGP.33) has only just been unveiled. Furthermore, there is no hardware in production that supports the IPA. We may see a small number of standards-based devices in 2024, but realistically they won’t be in volume until 2025. We should note that there are a number of pre-standard variants of SGP.32, based on an adaptation of SGP.22, but these lack interoperability.
Need for a managed transition – Any company wanting to avail themselves of the superior functionality of SGP.32 will either need to wait or will need to find a connectivity provider that can support their connectivity requirements using an alternative approach (e.g. multi-IMSI or SGP.02) today, with support for transition to SGP.32 at the appropriate time with a common management portal with the same functionality and/or a common set of APIs, so that there is effectively little difference to the experience delivered to the enterprise regardless of which approach is being used.
Willingness and ability to negotiate connectivity contracts – In order to switch connectivity providers, an enterprise will need to have a willing recipient provider, onto whose network it is localising. For that to happen there must be a commercial relationship between the connectivity provider and the SIM owner. This constrains the appeal of the technology to those customers who have relationships with more than one carrier, which might be the case with car makers or other big buyers but less so for most potential users. The other downside is that the negotiating power of that single customer for relatively small numbers of connections in each market will be limited compared to an MNO relying on reciprocal roaming agreements, or MVNOs with much larger volumes of devices within in any given market.
Not as simple as clicking a button – A further major constraint is that, even with SGP.32, it’s not simply a case of switching between providers seamlessly. The way in which connections are supported will vary depending on the network used and many settings will not be specified by the standard and will therefore not automatically carry over from one network to another. There will also be a requirement for back-end integration and other process changes, for instance to change APN settings, set the polling frequency for new eSIM profiles, or manage device security. Any changes to the eSIM profile will need to occur contemporaneously with a switch of those other elements of the deployment. This is a non-trivial task. What is required for SGP.32 to work optimally is a further abstraction and orchestration layer between the networks and the enterprise, handling all those other elements beyond the consideration of which eSIM profile is active on the device.
A useful standard but one to be best delivered as part of a portfolio of managed connectivity
Many enterprises have correctly identified SGP.32 as a potentially highly useful technology, ironing out many of the creases of the previous standards. However it is not a magic wand. Alternative options such as roaming, multi-IMSI or SGP.02 may prove better. Additionally, SGP.32 requires more complexity to realise than many would have expected, as noted above. As such we strongly suggest that SGP.32 will be provided as a managed service by a connectivity provider able to provide the transition, orchestration, and MNO management functions.
Check out the Position Paper to learn more
The article above is a short summary of some of the key messages from the report. In the full Position Paper ‘Key considerations for Enterprises looking to adopt SGP.32’, sponsored by Eseye, we explore in more depth the characteristics and capabilities of SGP.32, further expand on the reality of how it can be used, and identify the key capabilities of a provider of SGP.32 services.