SGP.22 vs SGP.32 - hva skiftet i eSIM-standard betyr for reisetilkobling

Mål: Gi kjøpere av reise-eSIM og reise-/MVNO-operatører et standardkunnig kart over forbruker vs IoT Remote SIM Provisioning - slik at bransjeprat om "den neste eSIM-standarden" ikke blander to forskjellige veier.

Målgruppe: Praktikere som sender eller kjøper forbruker-reisetilkobling (og alle som vurderer tilstøtende IoT-/reiseutstyr), ikke GSMA-komitémedlemmer.

Hvis du kjøper en reise-eSIM, skanner en QR-kode og lander med data, er du allerede inne i en GSMA Remote SIM Provisioning (RSP)-arkitektur - selv om du aldri ser spesifikasjonsnumrene. De numrene betyr noe.SGP.22 er den tekniske standarden for forbruker-RSP bak smarttelefon- og reise-eSIM-strømmer.SGP.32 er den tekniske standarden for IoT-RSP for hodeløse, begrensede og flåteskala enheter. De deler noen byggeklosser. De løser forskjellige problemer.

Den forskjellen er lett å blande i markedsføringspresentasjoner. Det er også forskjellen mellom en reisende som installerer en midlertidig profil på en telefon og en bedrift som orkestrerer tilkobling på tvers av tusenvis av sensorer som aldri vil se en skjerm. For reise-merker, MVNOer og alle som bygger på forbruker-eSIM-stabler, er det viktig å vite hvor SGP.22 slutter og SGP.32 begynner - ikke fordi reisende trenger GSMA-PDF-er, men fordi bransjesamtalen ofte blander forbruker- og IoT-veier.

Denne artikkelen kartlegger arkitektur, aktører, livssyklusforskjeller og praktiske implikasjoner for reisetilkobling - uten å behandle SGP.32 som en enkel oppgradering for forbruker-roaming.

Hvorfor bransjen trengte mer enn én eSIM "standard" #

eSIM er ikke ett enkelt protokoll. Det er en familie av GSMA-spesifikasjoner som definerer hvordan operatørprofiler sikkert forberedes, leveres, installeres, aktiveres, deaktiveres og slettes på en eUICC (den innebygde SIM-plattformen).

GSMAs offentlige spesifikasjonsindeks gjør splittelsen tydelig: forbruker RSP ligger under SGP.21 (arkitektur) og SGP.22 (teknisk); IoT RSP ligger under SGP.31 (arkitektur og krav) og SGP.32 (teknisk). Aktive forbrukerutgivelser fortsetter gjennom SGP.22 v2.x og v3.x; IoT-utgivelser fortsetter gjennom SGP.31/SGP.32 v1.x, inkludert nyere 2024-2026-revisjoner på GSMAs eSIM-spesifikasjonsside (GSMA eSIM Consumer and IoT Specifications).

Før SGP.32 levde IoT og M2M fjernprovisjonering stort sett i en tidligere maskin-til-maskin-modell (SGP.02), med en delt serverstruktur av SM-DP (datapreparasjon) og SM-SR (sikker ruting). Den modellen muliggjorde fjernstyring av profiler for industrielle og bilbrukstilfeller, men den førte også til operasjonell friksjon: SMS-orienterte triggere, tettere kommersiell kobling mellom SM-SR/SM-DP, og en dårlig tilpasning for svært begrensede LPWAN-enheter. Operatør- og IoT-plattformforklarere nevner konsekvent disse begrensningene som grunnen til at GSMA bygde en dedikert IoT-arkitektur i stedet for å tvinge forbruker RSP på alle modem (Eseye om SGP.31/32; 1oT om SGP.02 vs SGP.22 vs SGP.32).

Kortversjon: én fysisk formfaktor (eSIM/eUICC), flere provisjoneringsfilosofier.

SGP.22 i enkle termer: forbruker RSP for enheter med et menneske i loopen #

SGP.22 er GSMAs tekniske beskrivelse av Remote SIM Provisioning for forbrukerenheter. Hensikten er entydig: en teknisk løsning for fjernprovisjonering og administrasjon av eUICC i forbrukerenheter, rettet mot interoperabilitet på tvers av operatørdistribusjoner - inkludert SM-DP+ plattformer og eUICC-leverandører.

Kjerneaktører i forbrukermodellen #

Aktørroller #

• eUICC: Sikker plattform som lagrer profiler (operatørlegitimasjon og relaterte komponenter)
• LPA (Local Profile Assistant): På-enhet (eller delvis på-eUICC) assistent som driver nedlasting, lokal aktivering/deaktivering/sletting, og brukerrettet profiladministrasjon
• SM-DP+: Abonnementsadministrator - Datapreparasjon +: forbereder, beskytter og leverer Bound Profile Packages
• SM-DS: Abonnementsadministrator - Oppdagelsestjeneste: valgfri oppdagelsesvei når enheten trenger å finne riktig SM-DP+ uten en QR/aktiveringskode
• Operatør / profilutsteder: Eier det kommersielle abonnementet bak profilen

I flyten reisende kjenner igjen:

1. Kjøp en reiseplan og motta en aktiveringskode (ofte som en QR).
2. Enheten LPA kontakter SM-DP+.
3. Den krypterte profilpakken lastes ned og installeres på eUICC.
4. Brukeren aktiverer profilen (og kan senere deaktivere eller slette den).

Dette er en brukerinitiert / pull-orientert modell. En person er til stede, enheten har et brukergrensesnitt, og samtykke er en eksplisitt installasjonshandling. Det er derfor reise-eSIM-kjøp, partnerskap mellom flyselskaper/fintech og app-basert aktivering alle passer til SGP.22-klassen for forbruker-RSP - ikke IoT-flåteorkestrering.

HTTPS/TLS-transport passer for smarttelefoner. Det er tyngre enn mange IoT-arbeidssykluser kan håndtere, men rimelig for en håndsett som allerede opprettholder IP-tilkobling og en full sikkerhetsstabel.

SGP.32 i enkle termer: IoT RSP for enheter som ikke kan trykke på “Legg til eSIM” #

SGP.32 er den tekniske spesifikasjonen for GSMAs eSIM IoT-arkitektur definert i SGP.31. GSMA beskriver det som å dekke fjernprovisjonering og administrasjon av eUICC i IoT-enheter som er nettverksbegrensede og/eller brukergrensesnittbegrensede, pluss eUICC-arkitekturen, grensesnittene og sikkerhetsfunksjonene for den modellen.

Kjerneaktører i IoT-modellen #

Aktørroller #

• eUICC: IoT-kompatibel eUICC som lagrer profiler og støtter IoT-fjernadministrasjonsforbindelser
• IPA (IoT Profile Assistant): Enhets- eller eUICC-sideassistent som utfører provisjonering/administrasjonsarbeid uten et forbrukergrensesnitt; kan være IPAd (på enhet) eller IPAe (på eUICC)
• eIM (eSIM IoT Remote Manager): Sky-/orkestreringsenhet som utsteder profilens livssyklusoperasjoner for en enhet eller en flåte
• SM-DP+: Gjenbrukt fra forbrukerøkosystemet for profilforberedelse og beskyttet levering
• SM-DS: Oppdagelsesrolle beholdt der det er relevant
• Operatør: Profilkilde, som i forbruker-RSP

Den arkitektoniske hensikten er konsistent på tvers av GSMA-materialer og bransjegjennomganger: behold det som allerede fungerte i forbruker-RSP (særlig SM-DP+), og erstatt antagelsen om menneske/LPA med en fjernstyrt manager pluss en IoT-innfødt assistent (Velocity IoT-standardforklaring; 1oT-sammenligning).

Hvorfor IoT trengte en annen modell #

Forbruker-RSP antar:

• en skjerm eller følgesvenn-UX,
• en person som kan starte nedlastingen,
• relativt stabil IP-tilkobling for TLS-økter,
• per-enhet, brukerbaserte livssyklusbeslutninger.

IoT-flåter antar ofte det motsatte:

• ingen brukergrensesnitt,
• intermitterende eller lavbånds-tilkobling (inkludert LPWAN-scenarier),
• asynkrone innsjekkinger i stedet for alltid-på-økter,
• policybasert aktivering/deaktivering/sletting på tvers av mange EID-er samtidig.

SGP.31/32 introduserer derfor flåteorientert profiltilstandsadministrasjon og en eIM som kan utløse eller proxy nedlastinger. Bransjeanalyser understreker også lette protokollalternativer (for eksempel CoAP/DTLS som en alternativ vei for begrensede enheter), fjerning av SMS som en hard avhengighet for moderne IoT RSP, og støtte for direkte vs. indirekte profillevering avhengig av om enheten kan kommunisere komfortabelt med SM-DP+ selv (Eseye; 1oT).

Kritisk sett er SGP.32 ikke en bakoverkompatibel “programvareoppgradering” for hver SGP.02 eUICC allerede i feltet. Eseye og andre IoT-spesialister bemerker at M2M-standard distribusjoner vanligvis forblir på den modellen gjennom hele levetiden; grønnfelt-IoT er der SGP.32 er designet for å bli standarden.

SGP.22 vs SGP.32: strukturert sammenligning #

Dimensjon-for-dimensjon sammenligning #

Primært GSMA-par

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

Designet for

• SGP.22 (forbruker RSP): Smarttelefoner, nettbrett, wearables, forbrukerenheter med brukergrensesnitt
• SGP.32 (IoT RSP): Hodeløse / UI-begrensede / nettverksbegrensede IoT-enheter og flåter

Menneske i loopen?

• SGP.22 (forbruker RSP): Ja - bruker initierer eller bekrefter installasjon/bytte
• SGP.32 (IoT RSP): Nei - eIM/IPA orkestrerer operasjoner eksternt

Lokal assistent

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

Fjernorkestrering

• SGP.22 (forbruker RSP): Begrenset / ikke design sentrum
• SGP.32 (IoT RSP): eIM som førsteklasses fjernstyring

Profilserver

• SGP.22 (forbruker RSP): SM-DP+
• SGP.32 (IoT RSP): SM-DP+ (gjenbrukt)

Oppdagelse

• SGP.22 (forbruker RSP): SM-DS (valgfritt i mange flyter)
• SGP.32 (IoT RSP): SM-DS beholdt i arkitekturen

Utløsermodell

• SGP.22 (forbruker RSP): Overveiende pull (QR / aktiveringskode / app)
• SGP.32 (IoT RSP): Push og/eller pull via eIM og enhetsinnsjekkingsmønstre

Transportholdning

• SGP.22 (forbruker RSP): HTTPS/TLS-sentrisk forbruker IP-stakk
• SGP.32 (IoT RSP): IP-basert; alternativer for begrensede enheter vektlagt (f.eks., CoAP/DTLS-stier i industrisammendrag av spesifikasjonen)

Forløperproblemer det adresserer

• SGP.22 (forbruker RSP): Fysiske SIM-bytter og operatørlås på forbrukerutstyr
• SGP.32 (IoT RSP): SGP.02 operasjonell låsing, SMS-avhengighet, og dårlig tilpasning for begrensede enheter

Relevans for reise-eSIM

• SGP.22 (forbruker RSP): Direkte - dette er stakken bak typiske telefonreise-eSIM-installasjoner
• SGP.32 (IoT RSP): Indirekte - former tilstøtende IoT/reise-maskinvareøkosystemer, ikke telefon-QR-flyter

Profilens livssyklus: samme verb, forskjellig grammatikk #

Begge verdener snakker om nedlasting, installasjon, aktivering, deaktivering og sletting. Grammatikken er forskjellig:

• SGP.22 livssyklus er lokal og brukersentrert. Når den er installert, bestemmer reisende (eller LPA UI) når en profil er aktivert for roamingdata, når den er satt på pause, og når den fjernes.
• SGP.32 livssyklus er fjernstyrt og policy-sentrert. eIM kan utstede profiltilstandsoperasjoner over én EID eller mange, og IPA utfører dem når enheten er tilgjengelig - viktig for enheter som sover mesteparten av dagen.

Det er derfor “profilbytte” betyr forskjellige kommersielle ting i hver verden. I forbrukerreiser er bytte ofte et nytt kjøp eller en annen installert profil brukeren velger. I IoT er bytte en eiendomsoperasjon: endre tilkoblingsleverandør, svare på dekning, eller rotere profiler uten en fysisk oppmøte.

Hvor tidligere IoT-spesifikasjoner passer inn: SGP.02 og SGP.31 #

En klar mental modell:

1. SGP.02 - original M2M RSP med SM-DP + SM-SR. Grunnleggende, fortsatt til stede i eiendommer med lang livssyklus (særlig bilindustri og andre fabrikkbundne distribusjoner), men i økende grad behandlet som arv for nye begrensede IoT-prosjekter (1oT).
2. SGP.22 - forbruker-RSP som forenklet provisjonering rundt SM-DP+ og LPA; massemarkedets vei for telefoner og reise-eSIM.
3. SGP.31 / SGP.32 - IoT RSP som gjenbruker SM-DP+ mens den legger til eIM + IPA for flåtestyring uten hode.

SGP.32 dukket ikke opp fordi forbruker-eSIM "mislyktes." Den dukket opp fordi forbruker-eSIM lyktes for mennesker-og den suksessen løser fortsatt ikke en sensor boltet inne i en fraktcontainer.

Implikasjoner for reise-eSIM, forbruker-roaming og MVNO-stabler #

Reisetilkobling forblir en forbruker-RSP-historie #

For telefoner og de fleste reisende enheter, forblir den operative standarden SGP.22-klasse forbruker-RSP. Produktopplevelsen reisende bryr seg om - kjøp før avreise, installer via QR eller app, land tilkoblet - kartlegges til LPA ↔ SM-DP+ flyter, ikke eIM flåtekommandoer.

GSMAs egen bransjekommentar for 2026 rammer inn reisetilkobling som et strukturelt skifte i internasjonal roaming: app-baserte eSIM-reisetilbud er mer transparente og fleksible, og distribusjonen beveger seg nærmere sluttbrukeren før turen starter (GSMA: eSIM massemarkedsutrulling går fra prognose til fakta). Det kommersielle skiftet bygger på forbruker-RSP-modning og håndsettstøtte, ikke på IoT eIM utrulling.

Hva SGP.32 *gjør* endrer for reise-tilstøtende økosystemer #

Selv om reisende aldri berører SGP.32, er standarden viktig i kantene av reise:

• Tilkoblede bagasjesporere, flåtekjøretøy, logistikksensorer og sted-IoT trenger i økende grad fjernprofilhåndtering uten en QR-seremoni.
• Reiserutere og noe "eSIM-maskinvare" kan sitte i en rotete midtposisjon: forbrukeraktivering for en menneskelig eier, men operasjonelle behov som ser mer flåtelignende ut i skala.
• Operatører og MVNOer kan kjøre både forbruker SM-DP+ eiendommer og IoT eIM eiendommer. Deling av SM-DP+ DNA mellom SGP.22 og SGP.32 er med hensikt; det betyr ikke at de to enhetsklassene deler samme UX eller sertifiseringsvei.

Multi-IMSI, MVNO-stabler og sannferdige grenser #

Multi-IMSI (flere identiteter som kan velges innenfor eller ved siden av et tilkoblingsprodukt) og eUICC-profilnedlasting diskuteres ofte sammen, men de er ikke samme mekanisme. Multi-IMSI kan forbedre nettverkstilkoblingsatferd innenfor et kommersielt tilbud; eUICC RSP (SGP.22 eller SGP.32) handler om å sikkert installere og administrere fullstendige operatørprofiler på eUICC. Reise-merker og MVNOer kan kombinere begge teknikker kommersielt, men arkitekturklarhet er fortsatt viktig: forbrukerreiseinstallasjoner på telefoner vurderes etter SGP.22-interoperabilitet og aktiverings-UX; IoT-eiendommer vurderes etter eIM/IPA-operabilitet og begrenset-nettverksmotstand.

En nyttig advarsel fra IoT-siden gjelder også kommersielt: teknisk portabilitet i en spesifikasjon tilsvarer ikke automatisk kommersiell portabilitet i en kontrakt. SGP.32 reduserer visse arkitektoniske låsemønstre assosiert med SGP.02, men leverandørens kommersielle vilkår bestemmer fortsatt hvor fritt flåter kan flytte eIM-assosiasjoner eller eksterne SM-DP+ forhold (1oT). Forbrukerreise-kjøpere står overfor en tilsvarende lærdom i mindre skala - interoperabel RSP garanterer ikke i seg selv identisk dekvalitet, rettferdig brukspolitikk eller støtteopplevelse på tvers av leverandører.

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

Offentlige GSMA-materialer i 2026 beskriver forbruker-eSIM som går inn i operasjonell skala i stedet for bevis på konsept. Ifølge GSMAs mai 2026-sammendrag av GSMA Intelligence-tall, var global eSIM-smarttelefonpenetrasjon omtrent 5% ved utgangen av 2025, med en uttalt vei til omtrent 10 % innen utgangen av 2026, og videre vekst deretter; den samme artikkelen nevner omtrent tre av fire / 73 % av mobilnettoperatører som tilbyr kommersiell smarttelefon eSIM, samtidig som den påpeker det gjenværende gapet mellom tilgjengelighet og aktiv forbrukeraktivering (GSMA massemarked eSIM-artikkel).

På IoT-siden fremhever den samme GSMA-kommentaren SGP.32 som en strukturell muliggjører for globale produktvarianter og profilbytte i feltet - språk som samsvarer med hvordan IoT-plattformer posisjonerer standarden. Spesifikasjonsmodenhet er også synlig i GSMAs offentlige tabeller: SGP.31/SGP.32 fortsetter å utvikle seg gjennom aktive v1.2 og nyere v1.3-lister i 2024-2026, sammen med tilhørende testspesifikasjoner (GSMA spesifikasjonsindeks).

Tolkning uten å overdrive: forbrukerreise eSIM er allerede en skalert kommersiell brukstilfelle på SGP.22-skinner; SGP.32 er den parallelle industrialiseringen av IoT RSP. De forsterker den bredere eSIM-historien uten å erstatte hverandre.

Hva reisende og merkevarer bør ta med seg #

For reisende #

Du trenger ikke velge mellom SGP.22 og SGP.32 når du kjøper en reiseplan. Hvis du installerer en eSIM på en telefon via QR-kode eller app, er du i forbruker RSP-verdenen. Det du bør bry deg om er praktisk: enhetskompatibilitet, installasjonspålitelighet før avreise, dekning på destinasjonen, transparente rettferdige bruksvilkår, og støtte når noe går galt ved gaten.

Tilbydere som Roamify befinner seg i det forbrukerreise-laget - destinasjonsplaner, digital installasjon, og holde-seg-online-i-utlandet-nytte - snarere enn i industriell eIM-flåtestyring. Standardhistorien bak QR er fortsatt SGP.22-formet.

For reise-merkevarer, OTAs, fintechs, og forbruker-MVNOer #

• Behandle SGP.22-interoperabilitet og aktiverings-UX som produktgrunnlaget.
• Ikke markedsfør “SGP.32” som en reisende-vennlig oppgradering med mindre din faktiske maskinvare/flåtearkitektur bruker IoT RSP.
• Hvis du selger eller hvitmerker tilkobling for trackere, rutere, eller B2B-reiseutstyr, vurder separat om enhetsklassen trenger forbruker LPA-strømmer, IoT eIM-strømmer, eller en iscenesatt hybrid.
• Invester i utdanning: GSMAs egen markeds-kommentar peker fortsatt på et gap mellom eSIM-tilgjengelighet og forbrukerforståelse/aktivering. Klar installasjonsveiledning forblir en konkurransefordel.

For operatører og tilkoblingsplattformer #

Å kjøre forbruker- og IoT RSP side om side blir stadig mer normalt. Delt SM-DP+ arv hjelper, men sertifisering, sikkerhetsakkreditering, enhetsagenter (LPA vs IPA), og kommersielle driftsmodeller forblir distinkte. Å blande vokabularet i offentlig kommunikasjon skaper falske forventninger for både reisende og bedriftskjøpere.

Konklusjon: to standarder, én eSIM-fortelling - hold linjene klare #

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

• SGP.22 antar at en person er til stede og kan trekke en profil på en forbrukerenhet. Det er arkitekturen bak moderne reise eSIM på telefoner.
• SGP.32 antar at enheten er alene - eller sover - og trenger fjernstyrt, flåtekapabel administrasjon gjennom eIM og IPA, samtidig som den fortsatt gjenbruker SM-DP+ profillevering. Det er arkitekturen GSMA bygde for begrenset IoT etter at SGP.02s begrensninger ble åpenbare.

For reisetilkobling er den strategiske lærdommen presisjon. Forbruker RSP-banen former allerede hvordan folk kjøper roaming. IoT RSP-banen former hvordan maskiner holder seg tilkoblet i årevis. Merker som holder disse linjene klare vil forklare eSIM mer troverdig - og bygge produkter som matcher standarden de faktisk leverer.

Myk merkevaremerknad: Roamify er en reise eSIM-leverandør som tilbyr planer på tvers av mange destinasjoner med digital aktivering for kompatible telefoner. Denne artikkelen er standardutdanning, ikke en påstand om at Roamify implementerer IoT SGP.32 flåtestyring.