SGP.22 vs SGP.32 - hvad skiftet i eSIM-standard betyder for rejseforbindelse

Mål: Give købere af rejse-eSIM og rejse/MVNO-operatører et standardkendskabskort over forbruger vs IoT Remote SIM Provisioning - så branchesnak om 'den næste eSIM-standard' ikke slører to forskellige veje.

Målgruppe: Praktikere, der sender eller køber forbrugerrejseforbindelse (og alle, der evaluerer tilstødende IoT/rejsehardware), ikke GSMA-komitémedlemmer.

Hvis du køber en rejse-eSIM, scanner en QR-kode og lander med data, er du allerede inde i en GSMA Remote SIM Provisioning (RSP) arkitektur - selvom du aldrig ser specifikationsnumrene. De numre betyder noget.SGP.22 er den tekniske standard for forbruger-RSP bag smartphone- og rejse-eSIM-flows.SGP.32 er den tekniske standard for IoT-RSP til hovedløse, begrænsede og flådeskala enheder. De deler nogle byggesten. De løser forskellige problemer.

Den forskel er let at sløre i markedsføringsmateriale. Det er også forskellen mellem en rejsende, der installerer en midlertidig profil på en telefon, og en virksomhed, der orkestrerer forbindelse på tværs af tusindvis af sensorer, der aldrig vil se en skærm. For rejsemærker, MVNO'er og alle, der bygger på forbruger-eSIM-stakke, er det afgørende at vide, hvor SGP.22 slutter, og SGP.32 begynder - ikke fordi rejsende har brug for GSMA-PDF'er, men fordi branchesamtalen ofte blander forbruger- og IoT-veje.

Denne artikel kortlægger arkitektur, aktører, livscyklusforskelle og praktiske implikationer for rejseforbindelse - uden at behandle SGP.32 som en direkte opgradering for forbruger-roaming.

Hvorfor industrien havde brug for mere end én eSIM "standard" #

eSIM er ikke ét protokol. Det er en familie af GSMA-specifikationer, der definerer, hvordan operatørprofiler sikkert forberedes, leveres, installeres, aktiveres, deaktiveres og slettes på en eUICC (den indlejrede SIM-platform).

GSMA's offentlige specifikationsindeks gør opdelingen eksplicit: forbruger RSP ligger under SGP.21 (arkitektur) og SGP.22 (teknisk); IoT RSP ligger under SGP.31 (arkitektur og krav) og SGP.32 (teknisk). Aktive forbrugerudgivelser fortsætter gennem SGP.22 v2.x og v3.x; IoT-udgivelser fortsætter gennem SGP.31/SGP.32 v1.x, inklusive nyere 2024-2026 revisioner på GSMA's eSIM-specifikationsside (GSMA eSIM Consumer and IoT Specifications).

Før SGP.32 levede IoT og M2M fjernprovisionering stort set i en tidligere maskine-til-maskine model (SGP.02), med en dobbelt-server opdeling af SM-DP (dataklargøring) og SM-SR (sikker routing). Denne model muliggjorde fjernstyring af profiler til industrielle og bilindustrielle anvendelser, men den medførte også operationel friktion: SMS-orienterede triggere, strammere SM-SR/SM-DP kommerciel kobling og en dårlig pasform til stærkt begrænsede LPWAN-enheder. Operatør- og IoT-platforms forklaringer nævner konsekvent disse begrænsninger som årsagen til, at GSMA byggede en dedikeret IoT-arkitektur i stedet for at tvinge forbruger RSP på hver modem (Eseye on SGP.31/32; 1oT on SGP.02 vs SGP.22 vs SGP.32).

Kort version: én fysisk formfaktor (eSIM/eUICC), flere provisioneringsfilosofier.

SGP.22 i enkle termer: forbruger RSP til enheder med et menneske i loopet #

SGP.22 er GSMA's tekniske beskrivelse af Remote SIM Provisioning for forbrugerenheder. Dens formål er utvetydigt: en teknisk løsning til fjernprovisionering og styring af eUICC i forbrugerenheder, rettet mod interoperabilitet på tværs af operatørudrulninger - inklusive SM-DP+ platforme og eUICC-leverandører.

Kerneaktører i forbrugermodellen #

Aktørroller #

• eUICC: Sikker platform, der gemmer profiler (operatørlegitimationsoplysninger og relaterede komponenter)
• LPA (Local Profile Assistant): På-enhed (eller delvist på-eUICC) assistent, der driver download, lokal aktivering/deaktivering/sletning og brugerrettet profilhåndtering
• SM-DP+: Subscription Manager - Data Preparation +: forbereder, beskytter og leverer Bound Profile Packages
• SM-DS: Subscription Manager - Discovery Service: valgfri opdagelsesvej, når enheden skal finde den rigtige SM-DP+ uden en QR/aktiveringskode
• Operatør / profiludsteder: Ejer det kommercielle abonnement bag profilen

I det flow rejsende genkender:

1. Køb en rejseplan og modtag en aktiveringskode (ofte som en QR).
2. Enhedens LPA kontakter SM-DP+.
3. Den krypterede profilpakke downloades og installeres på eUICC.
4. Brugeren aktiverer profilen (og kan senere deaktivere eller slette den).

Dette er en brugerinitieret / pull-orienteret model. En person er til stede, enheden har en brugergrænseflade, og samtykke er en eksplicit installationshandling. Derfor passer rejse-eSIM-køb, partnerskaber mellem flyselskaber/fintech og app-baseret aktivering alle til SGP.22-klasse forbruger RSP - ikke IoT-flådeorkestrering.

HTTPS/TLS-transport passer til smartphones. Det er tungere end mange IoT-arbejdscyklusser kan bære, men rimeligt for en håndsæt, der allerede opretholder IP-forbindelse og en fuld sikkerhedsstak.

SGP.32 i enkle termer: IoT RSP for enheder, der ikke kan trykke på “Tilføj eSIM” #

SGP.32 er den tekniske specifikation for GSMA's eSIM IoT arkitektur defineret i SGP.31. GSMA beskriver det som dækkende fjernforsyning og styring af eUICC i IoT-enheder, der er netværksbegrænsede og/eller brugergrænsefladebegrænsede, plus eUICC-arkitekturen, grænsefladerne og sikkerhedsfunktionerne for den model.

Kerneaktører i IoT-modellen #

Aktørroller #

• eUICC: IoT-kompatibel eUICC, der gemmer profiler og understøtter IoT-fjernstyringsforbindelser
• IPA (IoT Profile Assistant): Enheds- eller eUICC-sideassistent, der udfører forsynings-/styringsarbejde uden en forbrugerbrugergrænseflade; kan være IPAd (på enhed) eller IPAe (på eUICC)
• eIM (eSIM IoT Remote Manager): Cloud-/orkestreringsenhed, der udsteder profil-livscyklusoperationer for en enhed eller en flåde
• SM-DP+: Genbrugt fra forbrugerøkosystemet til profilforberedelse og beskyttet levering
• SM-DS: Opdagelsesrolle bevaret, hvor det er relevant
• Operatør: Profilkilde, som i forbruger RSP

Den arkitektoniske hensigt er konsistent på tværs af GSMA-materialer og branchegennemgange: behold det, der allerede fungerede i forbruger RSP (især SM-DP+), og erstat antagelsen om menneske/LPA med en fjernstyringsenhed plus en IoT-native assistent (Velocity IoT-standardforklaring; 1oT-sammenligning).

Hvorfor IoT havde brug for en anden model #

Forbruger RSP antager:

• en skærm eller ledsagende UX,
• en person, der kan starte downloadet,
• relativt stabil IP-forbindelse til TLS-sessioner,
• livscyklusbeslutninger pr. enhed, drevet af brugeren.

IoT-flåder antager ofte det modsatte:

• ingen brugergrænseflade,
• intermitterende eller lavbåndsforbindelse (inklusive LPWAN-scenarier),
• asynkrone check-ins frem for altid-tændte sessioner,
• politisk styret aktivering/deaktivering/sletning på tværs af mange EIDs på én gang.

SGP.31/32 introducerer derfor flådeorienteret profiltilstandsadministration og en eIM, der kan udløse eller proxy-downloads. Brancheanalyser understreger også letvægtsprotokolmuligheder (for eksempel CoAP/DTLS som en alternativ vej for begrænsede enheder), fjernelse af SMS som en hård afhængighed for moderne IoT RSP, og støtte til direkte vs. indirekte profillevering afhængigt af om enheden kan kommunikere komfortabelt med SM-DP+ selv (Eseye; 1oT).

Kritisk set er SGP.32 ikke en bagudkompatibel “softwareopgradering” for hver SGP.02 eUICC allerede i marken. Eseye og andre IoT-specialister bemærker, at M2M-standardimplementeringer typisk forbliver på den model gennem hele levetiden; grøn mark IoT er, hvor SGP.32 er designet til at blive standarden.

SGP.22 vs SGP.32: struktureret sammenligning #

Dimension-for-dimension sammenligning #

Primært GSMA-par

• SGP.22 (forbruger RSP): SGP.21 arkitektur + SGP.22 teknisk
• SGP.32 (IoT RSP): SGP.31 arkitektur/krav + SGP.32 teknisk

Designet til

• SGP.22 (forbruger RSP): Smartphones, tablets, wearables, forbrugerenheder med brugergrænseflade
• SGP.32 (IoT RSP): Hovedløse / UI-begrænsede / netværksbegrænsede IoT-enheder og flåder

Menneske i loopet?

• SGP.22 (forbruger RSP): Ja - brugeren initierer eller bekræfter installation/skift
• SGP.32 (IoT RSP): Nej - eIM/IPA orkestrerer operationer eksternt

Lokal assistent

• SGP.22 (forbruger RSP): LPA
• SGP.32 (IoT RSP): IPA (IPAd eller IPAe)

Fjernorkestrering

• SGP.22 (forbruger RSP): Begrænset / ikke designcenter
• SGP.32 (IoT RSP): eIM som førsteklasses fjernstyring

Profilserver

• SGP.22 (forbruger RSP): SM-DP+
• SGP.32 (IoT RSP): SM-DP+ (genbrugt)

Opdagelse

• SGP.22 (forbruger RSP): SM-DS (valgfri i mange forløb)
• SGP.32 (IoT RSP): SM-DS bevaret i arkitekturen

Trigger-model

• SGP.22 (forbruger RSP): Overvejende pull (QR / aktiveringskode / app)
• SGP.32 (IoT RSP): Push og/eller pull via eIM og enhedstjek-ind mønstre

Transportholdning

• SGP.22 (forbruger RSP): HTTPS/TLS-centreret forbruger IP-stak
• SGP.32 (IoT RSP): IP-baseret; muligheder for begrænsede enheder fremhævet (f.eks. CoAP/DTLS stier i industrisammenfatninger af specifikationen)

Forgængerens problemer det adresserer

• SGP.22 (forbruger RSP): Fysiske SIM-udskiftninger og operatørlås på forbrugerenheder
• SGP.32 (IoT RSP): SGP.02 operationel lås, SMS-afhængighed og dårlig pasform til begrænsede enheder

Relevans for rejse-eSIM

• SGP.22 (forbruger RSP): Direkte - dette er stakken bag typiske telefonrejse-eSIM-installationer
• SGP.32 (IoT RSP): Indirekte - former tilstødende IoT/rejse-hardware økosystemer, ikke telefon QR-forløb

Profilens livscyklus: samme verber, forskellig grammatik #

Begge verdener taler om download, installation, aktivering, deaktivering og sletning. Grammatikken er forskellig:

• SGP.22 livscyklus er lokal og brugercentreret. Når den er installeret, beslutter rejsende (eller LPA UI), hvornår en profil er aktiveret til roamingdata, hvornår den er sat på pause, og hvornår den fjernes.
• SGP.32 livscyklus er fjernstyret og politikcentreret. eIM kan udstede profiltilstandsadministrationsoperationer på tværs af en eller mange EID'er, og IPA udfører dem, når enheden er tilgængelig - vigtigt for enheder, der sover det meste af dagen.

Derfor betyder “profilswitching” forskellige kommercielle ting i hver verden. I forbrugerrejser er switching ofte et nyt køb eller en anden installeret profil, brugeren vælger. I IoT er switching en ejendomsoperation: skift forbindelsesudbyder, reager på dækning, eller roter profiler uden en teknikerudrykning.

Hvor tidligere IoT-specifikationer passer ind: SGP.02 og SGP.31 #

En klar mental model:

1. SGP.02 - original M2M RSP med SM-DP + SM-SR. Grundlæggende, stadig til stede i langvarige livscyklusområder (især bilindustrien og andre fabriksbundne implementeringer), men i stigende grad betragtet som arv for nye begrænsede IoT-projekter (1oT).
2. SGP.22 - forbruger RSP der forenklede provisionering omkring SM-DP+ og LPA; massemarkedets vej for telefoner og rejse-eSIM.
3. SGP.31 / SGP.32 - IoT RSP der genbruger SM-DP+ mens den tilføjer eIM + IPA til hovedløs flådestyring.

SGP.32 dukkede ikke op fordi forbruger-eSIM “fejlede.” Den dukkede op fordi forbruger-eSIM lykkedes for mennesker-og den succes løser stadig ikke en sensor boltet inde i en skibscontainer.

Implikationer for rejse-eSIM, forbruger-roaming og MVNO-stakke #

Rejseforbindelse forbliver en forbruger RSP-historie #

For telefoner og de fleste rejsende enheder forbliver den operative standard SGP.22-klasse forbruger RSP. Den produktopplevelse rejsende bekymrer sig om - køb før afrejse, installer via QR eller app, land forbundet - kortlægges til LPA ↔ SM-DP+ flows, ikke eIM flådekommandoer.

GSMA's egen 2026 industrikommentar rammer rejseforbindelse som et strukturelt skift i international roaming: app-baserede eSIM-rejsetilbud er mere gennemsigtige og fleksible, og distributionen bevæger sig tættere på slutbrugeren før rejsen starter (GSMA: eSIM massemarked implementering bevæger sig fra prognose til fakta). Det kommercielle skift kører på forbruger RSP modenhed og håndsætstøtte, ikke på IoT eIM udrulning.

Hvad SGP.32 *ændrer* for rejse-relaterede økosystemer #

Selvom rejsende aldrig rører SGP.32, betyder standarden noget i rejsekanterne:

• Forbundne bagagesporere, flådekøretøjer, logistik sensorer og venue IoT har i stigende grad brug for fjernprofilstyring uden en QR-ceremoni.
• Rejseroutere og noget “eSIM-hardware” kan sidde i et rodet midterområde: forbruger-stil aktivering for en menneskelig ejer, men operationelle behov der ser mere flåde-lignende ud i skala.
• Operatører og MVNO'er kan køre både forbruger SM-DP+ områder og IoT eIM områder. Deling af SM-DP+ DNA mellem SGP.22 og SGP.32 er intentionelt; det betyder ikke, at de to enhedsklasser deler samme UX eller certificeringsvej.

Multi-IMSI, MVNO-stakke og sandfærdige grænser #

Multi-IMSI (flere identiteter der kan vælges inden for eller ved siden af et forbindelsesprodukt) og eUICC profil download diskuteres ofte sammen, men de er ikke den samme mekanisme. Multi-IMSI kan forbedre netværksvedhæftningsadfærd inden for et kommercielt tilbud; eUICC RSP (SGP.22 eller SGP.32) handler om sikkert at installere og administrere fulde operatørprofiler på eUICC. Rejsemærker og MVNO'er kan kombinere begge teknikker kommercielt, men arkitektur klarhed er stadig vigtig: forbrugerrejseinstallationer på telefoner bedømmes af SGP.22 interoperabilitet og aktiverings UX; IoT områder bedømmes af eIM/IPA operabilitet og begrænset-netværks robusthed.

En nyttig advarsel fra IoT-siden gælder også kommercielt: teknisk portabilitet i en specifikation er ikke automatisk lig med kommerciel portabilitet i en kontrakt. SGP.32 reducerer visse arkitektoniske lock-in mønstre forbundet med SGP.02, men leverandørens kommercielle vilkår bestemmer stadig, hvor frit flåder kan flytte eIM-foreninger eller eksterne SM-DP+ relationer (1oT). Forbrugerrejsekøbere står over for en tilsvarende lektion i mindre skala - interoperabel RSP garanterer ikke i sig selv identisk dækning kvalitet, fair-use politik eller supportoplevelse på tværs af leverandører.

Markeds timing og adoptionssignaler (offentlig, 2025-2026) #

Offentlige GSMA-materialer i 2026 beskriver forbruger-eSIM der går ind i operationel skala snarere end proof-of-concept. Ifølge GSMA's maj 2026 oversigt over GSMA Intelligence tal, var global eSIM smartphone penetration omkring 5% ved udgangen af 2025, med en angivet vej til omkring 10% ved udgangen af 2026, og yderligere vækst derefter; samme artikel nævner cirka tre ud af fire / 73% af mobilnetværksoperatører tilbyder kommerciel smartphone eSIM, mens de bemærker det resterende hul mellem tilgængelighed og aktiv forbrugeraktivering (GSMA massemarked eSIM artikel).

På IoT-siden fremhæver samme GSMA-kommentar SGP.32 som en strukturel muligør for globale produktvarianter og profilskift i marken - et sprog der matcher, hvordan IoT-platforme positionerer standarden. Specifikationsmodenhed er også synlig i GSMAs offentlige tabeller: SGP.31/SGP.32 fortsætter med at udvikle sig gennem aktive v1.2 og nyere v1.3 lister i 2024-2026, sammen med tilhørende testspecifikationer (GSMA specifikationsindeks).

Fortolkning uden at overdrive: forbrugerrejse eSIM er allerede en skaleret kommerciel brugssag på SGP.22 skinner; SGP.32 er den parallelle industrialisering af IoT RSP. De styrker den bredere eSIM-historie uden at erstatte hinanden.

Hvad rejsende og brands bør tage med sig #

For rejsende #

Du behøver ikke vælge mellem SGP.22 og SGP.32, når du køber en rejseplan. Hvis du installerer en eSIM på en telefon via QR-kode eller app, er du i forbruger RSP verdenen. Det, du bør bekymre dig om, er praktisk: enhedskompatibilitet, installationspålidelighed før afrejse, destinationsdækning, gennemsigtige fair-use vilkår og support, når noget går galt ved gaten.

Udbydere som Roamify befinder sig i det forbrugerrejse lag - destinationsplaner, digital installation og online-ophold i udlandet - snarere end i industriel eIM flådestyring. Standardhistorien bag QR er stadig SGP.22-formet.

For rejsebrands, OTAs, fintechs og forbruger MVNOs #

• Behandl SGP.22 interoperabilitet og aktiverings UX som produktets fundament.
• Markedsfør ikke “SGP.32” som en rejsende-venlig opgradering, medmindre din faktiske hardware/flådearkitektur bruger IoT RSP.
• Hvis du sælger eller white-labeler forbindelse til trackere, routere eller B2B rejsehardware, vurder separat om enhedsklassen har brug for forbruger LPA flows, IoT eIM flows eller en iscenesat hybrid.
• Invester i uddannelse: GSMAs egen markedskommentar peger stadig på et hul mellem eSIM tilgængelighed og forbrugerforståelse/aktivering. Klar installationsvejledning forbliver en konkurrencefordel.

For operatører og forbindelsesplatforme #

At køre forbruger- og IoT RSP side om side bliver stadig mere normalt. Delt SM-DP+ arv hjælper, men certificering, sikkerhedsakkreditering, enhedsagenter (LPA vs IPA) og kommercielle driftsmodeller forbliver forskellige. At blande vokabularerne i offentlig kommunikation skaber falske forventninger for både rejsende og virksomhedskøbere.

Konklusion: to standarder, én eSIM fortælling - hold banerne klare #

SGP.22 og SGP.32 er ikke rivaler på en enkelt rangliste. De er svar på to enhedsrealiteter:

• SGP.22 antager, at en person er til stede og kan trække en profil på en forbrugerenhed. Det er arkitekturen bag moderne rejse eSIM på telefoner.
• SGP.32 antager, at enheden er alene - eller sover - og har brug for fjernstyring, flådekapabel gennem eIM og IPA, mens den stadig genbruger SM-DP+ profillevering. Det er arkitekturen GSMA byggede til begrænset IoT efter SGP.02's begrænsninger blev tydelige.

For rejseforbindelse er den strategiske lektie præcision. Forbruger RSP-vejen omformer allerede, hvordan folk køber roaming. IoT RSP-vejen omformer, hvordan maskiner forbliver forbundet i årevis. Brands, der holder disse baner klare, vil forklare eSIM mere troværdigt - og bygge produkter, der matcher den standard, de faktisk leverer.

Blød brandnote: Roamify er en rejse eSIM-udbyder, der tilbyder planer på tværs af mange destinationer med digital aktivering til kompatible telefoner. Denne artikel er standarduddannelse, ikke en påstand om, at Roamify implementerer IoT SGP.32 flådestyring.