With SGP.32 the trigger point for profile interactions can be the device or the cloud/server. In other words it supports a push and a pull model which was not the case with SGP.02 (push only) and SGP.22 (pull only).
Some vendors claimed that the SGP.22 “pull” model gave consumers the ultimate flexibility and removed enterprise and operator control but this is largely inaccurate. Operators and enterprises retain full control over which profiles are downloaded and activated on IoT devices and for good reason. It helps maintain quality of service and security.
This same is true for SGP.32, only pre-approved and contracted profiles can be downloaded and activated meaning operator relationships remain key although in the vast majority of cases an IoT service provider (or MVNO) will manage this for you.
|
Standard
|
Use Case
|
Device Constraints
|
Provisioning Mechanism
|
Scalability & Flexibility
|
|
SGP.02 (M2M)
|
Automotive/industrial/M2M devices
|
Headless, resource-heavy devices
|
Pushbased, SMS-centric
|
Limited; not designed for wide-scale IoT sensors
|
|
SGP.22 (Consumer)
|
Smartphones, consumer gadgets
|
UI-enabled, interactive
|
Pullbased via user interaction (QR, app)
|
High for consumer
|
|
SGP.32 (IoT)
|
Low-power, headless IoT devices
|
UI-constrained, network-limited
|
Push/pull with IPA + eIM, IPbased
|
Optimised for global, scalable IoT rollouts
|