Med SGP.32 kan det udløsende punkt for profilinteraktioner være enheden eller skyen/serveren. Med andre ord understøtter den en push- og en pull-model, hvilket ikke var tilfældet med SGP.02 (kun push) og SGP.22 (kun pull).
Nogle leverandører hævdede, at SGP.22's "pull"-model gav forbrugerne den ultimative fleksibilitet og fjernede virksomhedernes og operatørernes kontrol, men det er stort set forkert. Operatører og virksomheder bevarer fuld kontrol over, hvilke profiler der downloades og aktiveres på IoT-enheder, og det er der en god grund til. Det hjælper med at opretholde servicekvalitet og sikkerhed.
Det samme gælder for SGP.32, hvor kun forhåndsgodkendte og aftalte profiler kan downloades og aktiveres, hvilket betyder, at forholdet til operatøren fortsat er afgørende, selvom en IoT-tjenesteudbyder (eller MVNO) i langt de fleste tilfælde vil administrere dette for dig.
|
Standard
|
Brugssag
|
Enhedsbegrænsninger
|
Tilvejebringelsesmekanisme
|
Skalerbarhed og fleksibilitet
|
|
SGP.02 (M2M)
|
Biler/industrielle/M2M-enheder
|
Hovedløse, ressourcetunge enheder
|
Push-baseret, SMS-centreret
|
Begrænset; ikke designet til IoT-sensorer i stor skala
|
|
SGP.22 (Forbruger)
|
Smartphones, forbrugergadgets
|
Brugergrænseflade-aktiveret, interaktiv
|
Pullbaseret via brugerinteraktion (QR, app)
|
Høj for forbrugere
|
|
SGP.32 (IoT)
|
Strømbesparende, hovedløse IoT-enheder
|
UI-begrænset, netværksbegrænset
|
Push/pull med IPA + eIM, IP-baseret
|
Optimeret til global, skalerbar IoT-udrulning
|