SGP.22 vs SGP.32 - wat de verschuiving in eSIM-standaarden betekent voor reisonnectiviteit

Doel: Geef kopers van reiseSIMs en reis-/MVNO-operators een standaardkenniskaart van consumenten- versus IoT Remote SIM Provisioning - zodat het gesprek in de industrie over 'de volgende eSIM-standaard' niet twee verschillende wegen vervaagt.

Doelgroep: Praktijkmensen die consumentenreisconnectiviteit verzenden of kopen (en iedereen die aangrenzende IoT-/reishardware evalueert), niet GSMA-commissieleden.

Als je een reiseSIM koopt, een QR-code scant en met data landt, bevind je je al binnen een GSMA Remote SIM Provisioning (RSP) architectuur - zelfs als je de specificatienummers nooit ziet. Die nummers zijn belangrijk.SGP.22 is de technische standaard voor consumenten RSP achter smartphone- en reiseSIM-stromen.SGP.32 is de technische standaard voor IoT RSP voor headless, beperkte en vlootschaalapparaten. Ze delen enkele bouwstenen. Ze lossen verschillende problemen op.

Dat onderscheid is gemakkelijk te vervagen in marketingpresentaties. Het is ook het verschil tussen een reiziger die een tijdelijk profiel op een telefoon installeert en een onderneming die connectiviteit orkestreert over duizenden sensoren die nooit een scherm zullen zien. Voor reismerken, MVNO's en iedereen die bouwt op consumenten eSIM-stacks, is weten waar SGP.22 eindigt en SGP.32 begint essentieel - niet omdat reizigers GSMA PDF's nodig hebben, maar omdat het gesprek in de industrie vaak consumenten- en IoT-wegen vermengt.

Dit stuk brengt de architectuur, actoren, levenscyclusverschillen en praktische implicaties voor reisconnectiviteit in kaart - zonder SGP.32 te behandelen als een directe upgrade voor consumentenroaming.

Waarom de industrie meer dan één eSIM 'standaard' nodig had #

eSIM is niet één protocol. Het is een familie van GSMA-specificaties die definiëren hoe operatorprofielen veilig worden voorbereid, geleverd, geïnstalleerd, ingeschakeld, uitgeschakeld en verwijderd op een eUICC (het ingebedde SIM-platform).

GSMA's openbare specificatie-index maakt de splitsing expliciet: consument RSP valt onder SGP.21 (architectuur) en SGP.22 (technisch); IoT RSP valt onder SGP.31 (architectuur en vereisten) en SGP.32 (technisch). Actieve consumentenreleases gaan door via SGP.22 v2.x en v3.x; IoT-releases gaan door via SGP.31/SGP.32 v1.x, inclusief nieuwere 2024-2026 revisies op GSMA's eSIM-specificatiepagina (GSMA eSIM Consumer and IoT Specifications).

Voor SGP.32 leefden IoT en M2M remote provisioning grotendeels in een eerder machine-to-machine model (SGP.02), met een dual-server splitsing van SM-DP (datavoorbereiding) en SM-SR (veilige routering). Dat model maakte remote profielbeheer mogelijk voor industriële en automotive toepassingen, maar bracht ook operationele wrijving met zich mee: SMS-georiënteerde triggers, nauwere SM-SR/SM-DP commerciële koppeling en een slechte pasvorm voor sterk beperkte LPWAN-apparaten. Operator- en IoT-platformuitleggers noemen die beperkingen consequent als de reden waarom GSMA een toegewijde IoT-architectuur bouwde in plaats van consument RSP op elk modem te forceren (Eseye over SGP.31/32; 1oT over SGP.02 vs SGP.22 vs SGP.32).

Korte versie: één fysieke vormfactor (eSIM/eUICC), meerdere provisioning-filosofieën.

SGP.22 in eenvoudige termen: consument RSP voor apparaten met een mens in de lus #

SGP.22 is GSMA's technische beschrijving van Remote SIM Provisioning voor consumentenapparaten. Het doel is ondubbelzinnig: een technische oplossing voor remote provisioning en beheer van de eUICC in consumentenapparaten, gericht op interoperabiliteit tussen operatorimplementaties - inclusief SM-DP+ platforms en eUICC-leveranciers.

Kernspelers in het consumentenmodel #

Rollen van actoren #

• eUICC: Veilig platform dat profielen opslaat (operatorreferenties en gerelateerde componenten)
• LPA (Local Profile Assistant): Op-apparaat (of gedeeltelijk op-eUICC) assistent die download, lokaal in-/uitschakelen/verwijderen en gebruikersgerichte profielbeheer aanstuurt
• SM-DP+: Subscription Manager - Data Preparation +: bereidt voor, beschermt en levert Bound Profile Packages
• SM-DS: Subscription Manager - Discovery Service: optioneel ontdekkingspad wanneer het apparaat de juiste SM-DP+ moet vinden zonder een QR/activatiecode
• Operator / profieluitgever: Bezit het commerciële abonnement achter het profiel

In de stroom die reizigers herkennen:

1. Koop een reisplan en ontvang een activatiecode (vaak als een QR).
2. Het apparaat LPA neemt contact op met de SM-DP+.
3. Het versleutelde profielpakket wordt gedownload en geïnstalleerd op de eUICC.
4. De gebruiker activeert het profiel (en kan het later uitschakelen of verwijderen).

Dit is een gebruikersgestuurd / pull-georiënteerd model. Er is een persoon aanwezig, het apparaat heeft een gebruikersinterface, en toestemming is een expliciete installactie. Daarom passen reis-eSIM-checkout, samenwerkingen met luchtvaartmaatschappijen/fintech en app-gebaseerde activering allemaal bij SGP.22-klasse consument RSP - niet bij IoT-vlootorkestratie.

HTTPS/TLS-transport past bij smartphones. Het is zwaarder dan veel IoT-dienstcycli kunnen dragen, maar redelijk voor een handset die al IP-connectiviteit en een volledige beveiligingsstack onderhoudt.

SGP.32 in eenvoudige termen: IoT RSP voor apparaten die niet kunnen tikken op “eSIM toevoegen” #

SGP.32 is de technische specificatie voor GSMA’s eSIM IoT architectuur gedefinieerd in SGP.31. GSMA beschrijft het als het dekt de externe provisioning en het beheer van de eUICC in IoT-apparaten die netwerkbeperkingen en/of gebruikersinterfacebeperkingen, plus de eUICC-architectuur, interfaces en beveiligingsfuncties voor dat model.

Kernspelers in het IoT-model #

Rol van de actoren #

• eUICC: IoT-capabele eUICC die profielen opslaat en IoT-remote-managementassociaties ondersteunt
• IPA (IoT Profile Assistant): Assistent aan de apparaat- of eUICC-zijde die provisioning/managementwerk uitvoert zonder een consumenteninterface; kan IPAd (op apparaat) of IPAe (op eUICC) zijn
• eIM (eSIM IoT Remote Manager): Cloud/orchestratie-entiteit die profiellevenscyclusoperaties uitvoert voor een apparaat of een vloot
• SM-DP+: Hergebruikt uit het consumenteneecosysteem voor profielvoorbereiding en beveiligde levering
• SM-DS: Ontdekkingsrol behouden waar relevant
• Operator: Profielbron, zoals in consument RSP

De architecturale intentie is consistent in GSMA-materialen en industriële walkthroughs: behoud wat al werkte in consument RSP (met name SM-DP+), en vervang de menselijke/LPA-aanname door een remote manager plus een IoT-native assistent (Velocity IoT-standaarden uitlegger; 1oT vergelijking).

Waarom IoT een ander model nodig had #

Consument RSP gaat uit van:

• een scherm of begeleidende gebruikerservaring,
• een persoon die de download kan starten,
• relatief stabiele IP-connectiviteit voor TLS-sessies,
• per apparaat, door de gebruiker gedreven levenscyclusbeslissingen.

IoT-vloten gaan vaak uit van het tegenovergestelde:

• geen UI,
• intermitterende of lage bandbreedte connectiviteit (inclusief LPWAN-scenario's),
• asynchrone check-ins in plaats van altijd-aan sessies,
• beleidsgestuurd in-/uitschakelen/verwijderen van veel EIDs tegelijk.

SGP.31/32 introduceert daarom vlootgerichte profielstatusbeheer en een eIM die downloads kan activeren of proxyen. Industrieanalyses benadrukken ook lichte protocolopties (bijvoorbeeld CoAP/DTLS als een alternatief pad voor beperkte apparaten), het verwijderen van SMS als een harde afhankelijkheid voor moderne IoT RSP, en ondersteuning voor directe versus indirecte profiellevering, afhankelijk van of het apparaat zelf comfortabel met de SM-DP+ kan communiceren (Eseye; 1oT).

Cruciaal is dat SGP.32 niet een achterwaarts-compatibele "software-upgrade" is voor elke SGP.02 eUICC die al in het veld is. Eseye en andere IoT-specialisten merken op dat M2M-standaardimplementaties doorgaans op dat model blijven tot het einde van de levensduur; greenfield IoT is waar SGP.32 is ontworpen om de standaard te worden.

SGP.22 vs SGP.32: gestructureerde vergelijking #

Vergelijking per dimensie #

Primaire GSMA-paar

• SGP.22 (consumenten RSP): SGP.21 architectuur + SGP.22 technisch
• SGP.32 (IoT RSP): SGP.31 architectuur/vereisten + SGP.32 technisch

Ontworpen voor

• SGP.22 (consumenten RSP): Smartphones, tablets, wearables, consumentenelektronica met UI
• SGP.32 (IoT RSP): Hoofdloze / UI-beperkte / netwerk-beperkte IoT-apparaten en vloten

Mens in de lus?

• SGP.22 (consumenten RSP): Ja - gebruiker initieert of bevestigt installatie/overschakeling
• SGP.32 (IoT RSP): Nee - eIM/IPA orkestreren operaties op afstand

Lokale assistent

• SGP.22 (consumenten RSP): LPA
• SGP.32 (IoT RSP): IPA (IPAd of IPAe)

Afstandsorkestratie

• SGP.22 (consumenten RSP): Beperkt / niet het ontwerpcentrum
• SGP.32 (IoT RSP): eIM als eersteklas externe beheerder

Profielserver

• SGP.22 (consumenten RSP): SM-DP+
• SGP.32 (IoT RSP): SM-DP+ (hergebruikt)

Ontdekking

• SGP.22 (consumenten RSP): SM-DS (optioneel in veel processen)
• SGP.32 (IoT RSP): SM-DS behouden in de architectuur

Trigger model

• SGP.22 (consumenten RSP): Voornamelijk pull (QR / activatiecode / app)
• SGP.32 (IoT RSP): Push en/of pull via eIM en apparaat check-in patronen

Transporthouding

• SGP.22 (consumenten RSP): HTTPS/TLS-gecentreerde consumenten IP-stack
• SGP.32 (IoT RSP): IP-gebaseerd; opties voor beperkte apparaten benadrukt (bijv. CoAP/DTLS-paden in industriële samenvattingen van de specificatie)

Voorganger pijn die het aanpakt

• SGP.22 (consumenten RSP): Fysieke SIM-wisselingen en operator lock-in op consumentenharde apparatuur
• SGP.32 (IoT RSP): SGP.02 operationele lock-in, SMS-afhankelijkheid en slechte pasvorm voor beperkte apparaten

Relevantie van reis-eSIM

• SGP.22 (consumenten RSP): Direct - dit is de stack achter typische telefoon reis-eSIM-installaties
• SGP.32 (IoT RSP): Indirect - vormt aangrenzende IoT/reis-hardware ecosystemen, niet telefoon QR-processen

Profiel levenscyclus: dezelfde werkwoorden, andere grammatica #

Beide werelden praten over downloaden, installeren, inschakelen, uitschakelen en verwijderen. De grammatica verschilt:

• SGP.22 levenscyclus is lokaal en gebruikersgericht. Eenmaal geïnstalleerd, beslist de reiziger (of LPA UI) wanneer een profiel is ingeschakeld voor roamingdata, wanneer het wordt gepauzeerd en wanneer het wordt verwijderd.
• SGP.32 levenscyclus is op afstand en beleidsgericht. De eIM kan profielstatusbeheeroperaties uitvoeren over één EID of meerdere, en de IPA voert ze uit wanneer het apparaat bereikbaar is - belangrijk voor apparaten die het grootste deel van de dag slapen.

Daarom betekent 'profiel wisselen' verschillende commerciële dingen in elke wereld. In consumententravel is wisselen vaak een nieuwe aankoop of een tweede geïnstalleerd profiel dat de gebruiker selecteert. In IoT is wisselen een vastgoedoperatie: verander van connectiviteitsprovider, reageer op dekking, of roteer profielen zonder een vrachtwagenrit.

Waar eerdere IoT-specificaties passen: SGP.02 en SGP.31 #

Een helder mentaal model:

1. SGP.02 - originele M2M RSP met SM-DP + SM-SR. Fundamenteel, nog steeds aanwezig in langlevende omgevingen (met name in de auto-industrie en andere fabrieksgebonden implementaties), maar steeds meer beschouwd als verouderd voor nieuwe beperkte IoT-projecten (1oT).
2. SGP.22 - consument RSP die provisioning vereenvoudigde rond SM-DP+ en LPA; het massamarktpad voor telefoons en reis-eSIM.
3. SGP.31 / SGP.32 - IoT RSP die SM-DP+ hergebruikt en eIM + IPA toevoegt voor beheer van vloot zonder tussenkomst.

SGP.32 verscheen niet omdat consument eSIM 'mislukte'. Het verscheen omdat consument eSIM succesvol was voor mensen-en dat succes lost nog steeds geen sensor op die in een zeecontainer is vastgeschroefd.

Gevolgen voor reis-eSIM, consumentenroaming en MVNO-stacks #

Reisconnectiviteit blijft een consument RSP-verhaal #

Voor telefoons en de meeste reizigersapparaten blijft de operationele standaard SGP.22-klasse consument RSP. De productervaring waar reizigers om geven - kopen voor vertrek, installeren via QR of app, landen verbonden - komt overeen met LPA ↔ SM-DP+ stromen, niet met eIM vlootcommando's.

GSMA's eigen industriecommentaar voor 2026 kadert reisconnectiviteit als een structurele verschuiving in internationale roaming: app-gebaseerde eSIM-reisaanbiedingen zijn transparanter en flexibeler, en distributie komt dichter bij de eindgebruiker voordat de reis begint (GSMA: eSIM massamarktimplementatie verschuift van voorspelling naar feit). Die commerciële verschuiving berust op de volwassenheid van consument RSP en ondersteuning van handsets, niet op de uitrol van IoT eIM.

Wat SGP.32 *wel* verandert voor reisgerelateerde ecosystemen #

Zelfs als reizigers nooit SGP.32 aanraken, is de standaard van belang aan de randen van reizen:

• Verbonden bagagetrackers, vlootvoertuigen, logistieke sensoren en locatie-IoT hebben steeds meer behoefte aan extern profielbeheer zonder een QR-ceremonie.
• Reisrouters en sommige 'eSIM-hardware' kunnen zich in een rommelig midden bevinden: consumentachtige activatie voor een menselijke eigenaar, maar operationele behoeften die op grotere schaal vlootachtig lijken.
• Operators en MVNO's kunnen zowel consument SM-DP+ omgevingen als IoT eIM omgevingen beheren. Het delen van SM-DP+ DNA tussen SGP.22 en SGP.32 is opzettelijk; het betekent niet dat de twee apparaatklassen dezelfde UX of certificeringspad delen.

Multi-IMSI, MVNO-stacks en duidelijke grenzen #

Multi-IMSI (meerdere identiteiten selecteerbaar binnen of naast een connectiviteitsproduct) en eUICC-profieldownload worden vaak samen besproken, maar ze zijn niet hetzelfde mechanisme. Multi-IMSI kan het netwerkverbindingsgedrag binnen een commercieel aanbod verbeteren; eUICC RSP (SGP.22 of SGP.32) gaat over het veilig installeren en beheren van volledige operatorprofielen op de eUICC. Reismarken en MVNO's kunnen beide technieken commercieel combineren, maar architectuurhelderheid blijft belangrijk: consumentreizeninstallaties op telefoons worden beoordeeld op SGP.22-interoperabiliteit en activatie-UX; IoT-omgevingen worden beoordeeld op eIM/IPA-bedienbaarheid en veerkracht van beperkte netwerken.

Een nuttige waarschuwing vanuit de IoT-kant geldt ook commercieel: technische draagbaarheid in een specificatie betekent niet automatisch commerciële draagbaarheid in een contract. SGP.32 vermindert bepaalde architecturale lock-in patronen geassocieerd met SGP.02, maar commerciële voorwaarden van de provider bepalen nog steeds hoe vrij vloten eIM-associaties of externe SM-DP+ relaties kunnen verplaatsen (1oT). Consumentenreisinkopers staan voor een vergelijkbare les op kleinere schaal - interoperabele RSP garandeert op zichzelf geen identieke dekkingskwaliteit, fair-use beleid of ondersteuningservaring bij verschillende providers.

Markttiming en adoptiesignalen (publiek, 2025-2026) #

Openbare GSMA-materialen in 2026 beschrijven consument eSIM die operationele schaal bereikt in plaats van proof-of-concept. Volgens GSMA's samenvatting van mei 2026 van GSMA Intelligence-cijfers was de wereldwijde eSIM-smartphonepenetratie ongeveer 5% eind 2025, met een aangegeven pad naar ongeveer 10% tegen eind 2026, en verdere groei daarna; hetzelfde stuk noemt ongeveer drie op de vier / 73% van de mobiele netwerkoperators die commerciële smartphone eSIM aanbieden, terwijl het de resterende kloof tussen beschikbaarheid en actieve consumentenactivatie opmerkt (GSMA massamarkt eSIM artikel).

Aan de IoT-kant benadrukt hetzelfde GSMA-commentaar SGP.32 als een structurele enabler voor wereldwijde productvarianten en in-veld profielwisseling - taal die overeenkomt met hoe IoT-platforms de standaard positioneren. Specificatiematuriteit is ook zichtbaar in de openbare tabellen van GSMA: SGP.31/SGP.32 blijven vooruitgaan door actieve v1.2 en nieuwere v1.3 vermeldingen in 2024-2026, naast bijbehorende testspecificaties (GSMA specificatie-index).

Interpretatie zonder overdrijving: consumentenreis eSIM is al een geschaalde commerciële use case op SGP.22 rails; SGP.32 is de parallelle industrialisatie van IoT RSP. Ze versterken het bredere eSIM-verhaal zonder elkaar te vervangen.

Wat reizigers en merken moeten meenemen #

Voor reizigers #

Je hoeft niet te kiezen tussen SGP.22 en SGP.32 wanneer je een reisplan koopt. Als je een eSIM op een telefoon installeert via QR-code of app, bevind je je in de consumenten RSP wereld. Waar je op moet letten is praktisch: apparaatcompatibiliteit, installatiereliabiliteit voor vertrek, dekking op de bestemming, transparante eerlijke gebruiksvoorwaarden, en ondersteuning wanneer er iets misgaat bij de gate.

Providers zoals Roamify bevinden zich in die consumentenreislagen - bestemmingsplannen, digitale installatie, en online blijven in het buitenland - in plaats van in industriële eIM-vlootbeheer. Het standaardverhaal achter de QR is nog steeds SGP.22-vormig.

Voor reismerken, OTA's, fintechs en consumenten MVNO's #

• Behandel SGP.22 interoperabiliteit en activatie UX als de productbasis.
• Markeer “SGP.32” niet als een upgrade voor reizigers tenzij je daadwerkelijke hardware/vlootarchitectuur IoT RSP gebruikt.
• Als je connectiviteit verkoopt of white-labelt voor trackers, routers, of B2B-reishardware, evalueer dan afzonderlijk of de apparaatklasse consumenten LPA-stromen, IoT eIM-stromen, of een gefaseerde hybride nodig heeft.
• Investeer in educatie: GSMA's eigen marktcommentaar wijst nog steeds op een kloof tussen eSIM-beschikbaarheid en consumentenbegrip/activatie. Duidelijke installatie-instructies blijven een concurrerend onderscheidend kenmerk.

Voor operators en connectiviteitsplatforms #

Het naast elkaar draaien van consumenten- en IoT RSP wordt steeds normaler. Gedeelde SM-DP+ erfenis helpt, maar certificering, veiligheidsaccreditatie, apparaatagenten (LPA vs IPA), en commerciële bedrijfsmodellen blijven verschillend. Het mengen van de woordenschat in openbare berichten creëert valse verwachtingen voor zowel reizigers als zakelijke kopers.

Conclusie: twee standaarden, één eSIM-verhaal - houd de lijnen duidelijk #

SGP.22 en SGP.32 zijn geen rivalen op een enkel scorebord. Ze zijn antwoorden op twee apparaatrealiteiten:

• SGP.22 gaat ervan uit dat er een persoon aanwezig is en een profiel op een consumentapparaat kan trekken. Dat is de architectuur achter moderne reis eSIM op telefoons.
• SGP.32 gaat ervan uit dat het apparaat alleen is - of slaapt - en behoefte heeft aan remote, vloot-capabel beheer via eIM en IPA, terwijl het nog steeds SM-DP+ profiellevering hergebruikt. Dat is de architectuur die GSMA bouwde voor beperkte IoT nadat de grenzen van SGP.02 duidelijk werden.

Voor reisconnectiviteit is de strategische les precisie. Het consumenten RSP-pad is al aan het herdefiniëren hoe mensen roaming kopen. Het IoT RSP-pad is aan het herdefiniëren hoe machines jarenlang verbonden blijven. Merken die die lijnen duidelijk houden, zullen eSIM geloofwaardiger uitleggen - en producten bouwen die overeenkomen met de standaard die ze daadwerkelijk leveren.

Zachte merknoot: Roamify is een reis eSIM-provider die plannen aanbiedt voor veel bestemmingen met digitale activatie voor compatibele telefoons. Dit artikel is standaardeneducatie, niet een bewering dat Roamify IoT SGP.32 vlootbeheer implementeert.