SGP.32: your technical questions answered

SGP.32 is GSMA’s new eSIM standard for remote SIM provisioning (RSP) in IoT. Designed specifically for the IoT, it enables lightweight, scalable and low-power IoT deployments so that RSP is practical across millions of devices. It has opened up the market, and is expected to drive an estimated 195 million SGP.32 profile downloads in 2029—70% of all IoT[i]. But it raises many questions.  

Top 3 takeaways in SGP.32's technical questions

1. SGP.32 is suited to a wide range of IoT use cases, from those that exchange high-data volume to sensors that are in location for many years
2. SGP.32 require specific services or functions, such as an eSIM IoT manager (eIM) and IoT profile assistant (IPA). Whilst some may source and manage these themselves, other will prefer a 'one-stop-shop' provider
3. There is likely to be a range of payment models including pay-per-transaction and service fee-based approaches. And often providers will include the capability in overall charges.

Wireless Logic’s Toby Gasston (TG) and Paul Bullock (PB) joined Robin Duke Woolley, CEO at Beecham Research, and Jean-François Gros (JFG), head of IoT services product lines at Thales, on a recent webinar to answer technical questions on:

• When and how to approach SGP.32 investment
• The realities of global deployment
• Managing transition from existing eSIM approaches
• Architectural and operational considerations at scale.

The recorded sessions broken down by question, so you can dive into your areas of interest. Here, we’ve selected 10 of the best.

Top 10 SGP.32 questions answered

Where SGP.32 delivers the most value

1. What are the key use cases for SGP.32?
TG:  All of them! For high-volume solutions that burn through gigabytes or terabytes of data, SGP.32 certainly makes cost management far more attractive. But even at the other end of the scale, such as sensors down manholes for ten years, the whole economic model is ruined if you must send someone to go and pull out a SIM and plug in a new one. So really, there are use cases at every end of the spectrum, and every vertical, that SGP.32 addresses and is relevant for.  

2. Which characteristics determine which IoT deployments will benefit most from SGP.32?
PB: The greatest benefit will be seen with regulated markets and multi-national deployments but, in particular, use cases that have higher than average data volumes. And the reason for that is that over the life of the device, when you’re dealing with higher costs of connectivity, there is more incentive to need to control costs, both from your provider’s point of view and yours. SGP.32 provides new levels of control to enterprises and service providers to contain and reduce costs over time.

TG: Whatever it is, I don’t see a real reason to not engage with SGP.32. If you need to build your own orchestration platform and other elements, that’s expensive and maybe not something you’d want to do, but finding a connectivity provider that can offer you a basic connectivity product on an SGP.32 SIM with options later to do something with it, that should be the de facto standard.

Rolling out SGP.32: roles, platform and provisioning

4. What new roles or platforms (e.g. orchestrators) are needed beyond the technical standard to make SGP.32 commercially viable?
JFG: Technically, SGP.32 is just an API between an eSIM IoT manager (eIM) and an IoT profile assistant (IPA). There is no intelligence behind it.

SGP.32 Buyers’ Guide

For an end-to-end solution, you need an orchestrator because there are multiple mobile network operator (MNO) relationships to monitor, manage and orchestrate. The eSIM orchestrator is how you devise your business rules, such as which MNO profile to use in which country.

Collectively, the functions of these different elements are managed through the connectivity management platform (CMP), the so-called ‘single pane of glass’, to download new profiles and activate them. All this must be orchestrated and automated.

JFG: It depends on the level of expertise, what kind of enterprise it is, and whether it deals with MNOs, OEMs or IoT service providers as they have different levels of expertise and elements in place.

The first key point to understand is the use case, then the elements that are already present, such as CMPs or device management, the level of orchestration and automation and the number of devices. With all that, you can define the best way to go to market, which could be a phased approach. Vendors can provide a ‘one-stop-shop’ – eIM plus orchestration, ‘single pane of glass’, connectivity and so on – and the enterprise can develop and add their own services. You don’t need anything at the beginning; you can start from scratch and evolve over time because there are vendors who can provide everything.

6. Which IPA implementation approaches are being adopted – is there a clear market direction or ranking?
JFG: There are two approaches: IPAe (on the eSIM chip) and IPAd (on the device). The shortest route to market is with IPAe: you can retrofit, don’t have to implement new firmware, and it works across all devices. Of course, you must confirm it works with your module. However, you must determine the business logic you’ll apply. If the IPAe can’t deliver that business logic, you may need to use IPAd. IPAd does require more embedded software development and validation so IPAe will be the preferred model for most IoT devices.

TG: It depends on what the production line looks like and at what point profile loading is feasible. Sometimes, it will involve a Wi-Fi connection, others a cellular bootstrap and sometimes side loading will use a physical connection to the device. You must understand the manufacturing process and discuss with a connectivity provider who has an RSP partner. They should be able to bring that partner into a conversation with you to discuss how profile delivery would happen.

8. Profile swapping brings clear benefits but also added costs. How should organisations assess ‘hidden’ impacts, such as energy consumption and variety of profile size?
TG: The biggest difference with SGP.32 profiles, compared to SGP.22, is the footprint. A consumer SGP.22 profile could be 100 kilobytes, whereas an IoT SGP.32 profile could be less than a kilobyte. It’s important to understand that to manage battery demand. You might have a download cost from your eIM provider, or a monthly cost, and a connectivity provider (MNO) might charge a euro for a profile, then you’ve got to test – is there an onboarding fee? – it depends how different parts of the industry engage. The winners in the market will be those who are willing to engage and be flexible and supportive of customers.

Operational models for SGP.32

PB: They don’t have to source from a single provider. Organisations can multi-source. It’s likely we will see a spectrum of approaches. Some will rely on a ‘one-stop-shop’ provider because their business is not managing connectivity and they reach a commercially satisfactory arrangement with a provider. Some may buy their own SIMs and contract with an eIM provider and so on.

JFG: There are different models depending on the use case. For example, smart meter operators may only do a single transaction in 10 years, they cannot be expected to pay a service fee, they would need a transactional model. However, vehicle cameras and track-and-trace IoT will make regular transactions. They will need more of an ‘all-you-can-eat’ model.

All you need to know about SGP.32

• Your questions on SGP.32: recorded session
• SGP.32 buyers’ guide: what you should be asking about eSIM
• Enterprise eSIM connectivity for global IoT
• SGP.32 eSIM: How to succeed with next generation IoT connectivity
• How to assess and reduce total cost of ownership (TCO) in IoT.