SGP.22 vs SGP.32 - vad skiftet i eSIM-standard betyder för reseanslutning

Mål: Ge köpare av rese-eSIM och rese-/MVNO-operatörer en standardkunnig karta över konsument- vs IoT-fjärr-SIM-provisionering - så att branschsnacket om "nästa eSIM-standard" inte suddar ut två olika vägar.

Målgrupp: Praktiker som levererar eller köper konsumentreseanslutning (och alla som utvärderar närliggande IoT-/resehårdvara), inte GSMA-kommittémedlemmar.

Om du köper en rese-eSIM, skannar en QR-kod och landar med data, är du redan inne i en GSMA Remote SIM Provisioning (RSP)-arkitektur - även om du aldrig ser specifikationsnumren. De numren spelar roll.SGP.22 är den tekniska standarden för konsument-RSP bakom smartphone- och rese-eSIM-flöden.SGP.32 är den tekniska standarden för IoT-RSP för huvudlösa, begränsade och flotteskaliga enheter. De delar vissa byggstenar. De löser olika problem.

Den distinktionen är lätt att sudda ut i marknadsföringsmaterial. Det är också skillnaden mellan en resenär som installerar en tillfällig profil på en telefon och ett företag som orkestrerar anslutning över tusentals sensorer som aldrig kommer att se en skärm. För resevarumärken, MVNO:er och alla som bygger på konsument-eSIM-staplar, är det grundläggande att veta var SGP.22 slutar och SGP.32 börjar - inte för att resenärer behöver GSMA-PDF:er, utan för att branschkonversationen ofta blandar konsument- och IoT-vägar.

Denna artikel kartlägger arkitektur, aktörer, livscykelskillnader och praktiska konsekvenser för reseanslutning - utan att behandla SGP.32 som en direkt uppgradering för konsumentroaming.

Varför branschen behövde mer än en eSIM-"standard" #

eSIM är inte ett enda protokoll. Det är en familj av GSMA-specifikationer som definierar hur operatörsprofiler säkert förbereds, levereras, installeras, aktiveras, inaktiveras och raderas på en eUICC (den inbäddade SIM-plattformen).

GSMAs offentliga specifikationsindex gör uppdelningen tydlig: konsument-RSP ligger under SGP.21 (arkitektur) och SGP.22 (teknisk); IoT-RSP ligger under SGP.31 (arkitektur och krav) och SGP.32 (teknisk). Aktiva konsumentutgåvor fortsätter genom SGP.22 v2.x och v3.x; IoT-utgåvor fortsätter genom SGP.31/SGP.32 v1.x, inklusive nyare 2024-2026-revisioner på GSMAs eSIM-specifikationssida (GSMA eSIM Consumer and IoT Specifications).

Före SGP.32 levde IoT och M2M-fjärrprovisionering till stor del i en tidigare maskin-till-maskin-modell (SGP.02), med en dubbel-serveruppdelning av SM-DP (databeräkning) och SM-SR (säker routing). Den modellen möjliggjorde fjärrhantering av profiler för industriella och fordonsanvändningsfall, men den medförde också operativa friktioner: SMS-orienterade triggers, stramare SM-SR/SM-DP kommersiell koppling och en dålig passform för mycket begränsade LPWAN-enheter. Operatörs- och IoT-plattformsförklarare nämner konsekvent dessa begränsningar som anledningen till att GSMA byggde en dedikerad IoT-arkitektur istället för att tvinga konsument-RSP på varje modem (Eseye on SGP.31/32; 1oT on SGP.02 vs SGP.22 vs SGP.32).

Kort version: en fysisk formfaktor (eSIM/eUICC), flera provisioneringsfilosofier.

SGP.22 i enkla termer: konsument-RSP för enheter med en människa i loopen #

SGP.22 är GSMAs tekniska beskrivning av Remote SIM Provisioning för konsumentenheter. Dess syfte är entydigt: en teknisk lösning för fjärrprovisionering och hantering av eUICC i konsumentenheter, inriktad på interoperabilitet över operatörsutbyggnader - inklusive SM-DP+ plattformar och eUICC-leverantörer.

Centrala aktörer i konsumentmodellen #

Aktörsroller #

• eUICC: Säker plattform som lagrar profiler (operatörsautentiseringar och relaterade komponenter)
• LPA (Local Profile Assistant): På-enhet (eller delvis på-eUICC) assistent som driver nedladdning, lokal aktivering/inaktivering/radering och användarvänlig profilhantering
• SM-DP+: Subscription Manager - Data Preparation +: förbereder, skyddar och levererar Bound Profile Packages
• SM-DS: Subscription Manager - Discovery Service: valfri upptäcktsväg när enheten behöver hitta rätt SM-DP+ utan en QR/aktiveringskod
• Operatör / profilutfärdare: Äger det kommersiella abonnemanget bakom profilen

I flödet resenärer känner igen:

1. Köp en reseplan och få en aktiveringskod (ofta som en QR).
2. Enhetens LPA kontaktar SM-DP+.
3. Det krypterade profilpaketet laddas ner och installeras på eUICC.
4. Användaren aktiverar profilen (och kan senare inaktivera eller ta bort den).

Detta är en användarinitierad / pull-orienterad modell. En person är närvarande, enheten har ett användargränssnitt, och samtycke är en uttrycklig installationsåtgärd. Det är därför som rese-eSIM-utcheckning, flygbolags-/fintech-partnerskap och app-baserad aktivering alla motsvarar SGP.22-klassens konsument-RSP - inte IoT-flottans orkestrering.

HTTPS/TLS-transport passar smartphones. Det är tyngre än många IoT-arbetscykler har råd med, men rimligt för en telefon som redan upprätthåller IP-anslutning och en fullständig säkerhetsstack.

SGP.32 i enkla termer: IoT RSP för enheter som inte kan trycka på “Lägg till eSIM” #

SGP.32 är den tekniska specifikationen för GSMAs eSIM IoT-arkitektur definierad i SGP.31. GSMA beskriver det som att täcka fjärrprovisionering och hantering av eUICC i IoT-enheter som är nätverksbegränsade och/eller användargränssnittbegränsade, plus eUICC-arkitektur, gränssnitt och säkerhetsfunktioner för den modellen.

Centrala aktörer i IoT-modellen #

Aktörsroller #

• eUICC: IoT-kapabel eUICC som lagrar profiler och stöder IoT-fjärrhanteringsassociationer
• IPA (IoT Profile Assistant): Enhets- eller eUICC-sidassistent som utför provisionerings-/hanteringsarbete utan ett konsumentgränssnitt; kan vara IPAd (på enhet) eller IPAe (på eUICC)
• eIM (eSIM IoT Remote Manager): Moln-/orkestreringsenhet som utfärdar profilens livscykeloperationer för en enhet eller en flotta
• SM-DP+: Återanvänds från konsumentekosystemet för profilförberedelse och skyddad leverans
• SM-DS: Upptäcktsroll behållen där relevant
• Operatör: Profilleverantör, som i konsument-RSP

Den arkitektoniska avsikten är konsekvent i GSMAs material och branschgenomgångar: behåll det som redan fungerade i konsument-RSP (särskilt SM-DP+), och ersätt antagandet om människa/LPA med en fjärrhanterare plus en IoT-inbyggd assistent (Velocity IoT-standarder förklarare; 1oT-jämförelse).

Varför IoT behövde en annan modell #

Konsument-RSP förutsätter:

• en skärm eller följeslagar-UX,
• en person som kan starta nedladdningen,
• relativt stabil IP-anslutning för TLS-sessioner,
• livscykelbeslut per enhet, styrda av användaren.

IoT-flottor antar ofta motsatsen:

• ingen användargränssnitt,
• intermittent eller låg bandbredds-anslutning (inklusive LPWAN-scenarier),
• asynkrona incheckningar istället för alltid-aktiva sessioner,
• policy-styrd aktivering/inaktivering/radering över många EID samtidigt.

SGP.31/32 introducerar därför flottorienterad profilstatushantering och en eIM som kan trigga eller proxy-nedladdningar. Branschanalyser betonar också lättviktsprotokollalternativ (till exempel CoAP/DTLS som en alternativ väg för begränsade enheter), borttagning av SMS som ett hårt beroende för modern IoT RSP, och stöd för direkt vs. indirekt profilleverans beroende på om enheten kan kommunicera bekvämt med SM-DP+ själv (Eseye; 1oT).

Kritiskt är att SGP.32 inte är en bakåtkompatibel “mjukvaruuppgradering” för varje SGP.02 eUICC som redan finns i fältet. Eseye och andra IoT-specialister noterar att M2M-standardutplaceringar vanligtvis förblir på den modellen till slutet av livscykeln; grönfält IoT är där SGP.32 är designad att bli standard.

SGP.22 vs SGP.32: strukturerad jämförelse #

Jämförelse dimension för dimension #

Primärt GSMA-par

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

Designad för

• SGP.22 (konsument RSP): Smartphones, surfplattor, wearables, konsumentenheter med användargränssnitt
• SGP.32 (IoT RSP): Huvudlösa / UI-begränsade / nätverksbegränsade IoT-enheter och flottor

Människa i loopen?

• SGP.22 (konsument RSP): Ja - användaren initierar eller bekräftar installation/byte
• SGP.32 (IoT RSP): Nej - eIM/IPA orkestrerar operationer på distans

Lokal assistent

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

Fjärrorkestrering

• SGP.22 (konsument RSP): Begränsad / inte designcentrum
• SGP.32 (IoT RSP): eIM som förstklassig fjärrhanterare

Profilserver

• SGP.22 (konsument RSP): SM-DP+
• SGP.32 (IoT RSP): SM-DP+ (återanvänds)

Upptäckt

• SGP.22 (konsument RSP): SM-DS (valfritt i många flöden)
• SGP.32 (IoT RSP): SM-DS bibehålls i arkitekturen

Trigger-modell

• SGP.22 (konsument RSP): Övervägande pull (QR / aktiveringskod / app)
• SGP.32 (IoT RSP): Push och/eller pull via eIM och enhetsincheckningsmönster

Transportläge

• SGP.22 (konsument RSP): HTTPS/TLS-centrerad konsument-IP-stack
• SGP.32 (IoT RSP): IP-baserad; alternativ för begränsade enheter betonas (t.ex. CoAP/DTLS-vägar i branschsammanfattningar av specifikationen)

Föregående problem det adresserar

• SGP.22 (konsument RSP): Fysiska SIM-bytningar och operatörslåsning på konsumenthårdvara
• SGP.32 (IoT RSP): SGP.02 operativ låsning, SMS-beroende och dålig passform för begränsade enheter

Rese-eSIM-relevans

• SGP.22 (konsument RSP): Direkt - detta är stacken bakom typiska telefonrese-eSIM-installationer
• SGP.32 (IoT RSP): Indirekt - formar angränsande IoT/rese-hårdvaruekosystem, inte telefon-QR-flöden

Profilens livscykel: samma verb, olika grammatik #

Båda världarna pratar om nedladdning, installation, aktivering, inaktivering och borttagning. Grammatiken skiljer sig:

• SGP.22 livscykel är lokal och användarcentrerad. När den är installerad bestämmer resenären (eller LPA UI) när en profil aktiveras för roamingdata, när den pausas och när den tas bort.
• SGP.32 livscykel är fjärrstyrd och policycentrerad. eIM kan utfärda profilstatushanteringsoperationer över en EID eller flera, och IPA utför dem när enheten är nåbar - viktigt för enheter som sover större delen av dagen.

Det är därför “profilväxling” betyder olika kommersiella saker i varje värld. Inom konsumentresor är växling ofta ett nytt köp eller en andra installerad profil som användaren väljer. Inom IoT är växling en fastighetsoperation: byta anslutningsleverantör, svara på täckning eller rotera profiler utan en lastbilsutryckning.

Var tidigare IoT-specifikationer passar in: SGP.02 och SGP.31 #

En tydlig mental modell:

1. SGP.02 - ursprunglig M2M RSP med SM-DP + SM-SR. Grundläggande, fortfarande närvarande i långlivade tillgångar (särskilt inom bilindustrin och andra fabriksbundna installationer), men behandlas alltmer som arv för nya begränsade IoT-projekt (1oT).
2. SGP.22 - konsument-RSP som förenklade provisionering kring SM-DP+ och LPA; massmarknadsvägen för telefoner och rese-eSIM.
3. SGP.31 / SGP.32 - IoT RSP som återanvänder SM-DP+ samtidigt som den lägger till eIM + IPA för huvudlös flottahantering.

SGP.32 dök inte upp för att konsument-eSIM "misslyckades." Den dök upp för att konsument-eSIM lyckades för människor-och den framgången löser fortfarande inte en sensor bultad inuti en fraktcontainer.

Implikationer för rese-eSIM, konsumentroaming och MVNO-staplar #

Reseanslutning förblir en konsument-RSP-historia #

För telefoner och de flesta resenärsenheter förblir den operativa standarden SGP.22-klass konsument-RSP. Produktupplevelsen resenärer bryr sig om - köp före avresa, installera via QR eller app, landa ansluten - kartlägger till LPA ↔ SM-DP+ flöden, inte eIM flottkommandon.

GSMAs egen branschkommentar för 2026 ramar in reseanslutning som ett strukturellt skifte i internationell roaming: app-baserade eSIM-reseerbjudanden är mer transparenta och flexibla, och distributionen flyttar närmare slutanvändaren innan resan börjar (GSMA: eSIM massmarknadsutbyggnad går från prognos till fakta). Det kommersiella skiftet bygger på konsument-RSP-mognad och stöd för handenheter, inte på IoT eIM-utbyggnad.

Vad SGP.32 *ändrar* för rese-nära ekosystem #

Även om resenärer aldrig rör SGP.32, är standarden viktig i resekanterna:

• Anslutna bagagespårningsenheter, fordonsflottor, logistiksensorer och plats-IoT behöver i allt högre grad fjärrprofilhantering utan en QR-ceremoni.
• Reseroutrar och viss "eSIM-hårdvara" kan sitta i en rörig mitt: konsumentaktivering för en mänsklig ägare, men operativa behov som ser mer ut som flottor i stor skala.
• Operatörer och MVNOs kan driva både konsument-SM-DP+ tillgångar och IoT eIM tillgångar. Att dela SM-DP+ DNA mellan SGP.22 och SGP.32 är avsiktligt; det betyder inte att de två enhetsklasserna delar samma UX eller certifieringsväg.

Multi-IMSI, MVNO-staplar och sanna gränser #

Multi-IMSI (flera identiteter valbara inom eller bredvid en anslutningsprodukt) och eUICC-profildownload diskuteras ofta tillsammans, men de är inte samma mekanism. Multi-IMSI kan förbättra nätverksanslutningsbeteendet inom ett kommersiellt erbjudande; eUICC RSP (SGP.22 eller SGP.32) handlar om att säkert installera och hantera fullständiga operatörsprofiler på eUICC. Resemärken och MVNOs kan kombinera båda teknikerna kommersiellt, men arkitekturens tydlighet är fortfarande viktig: konsumentresor installerade på telefoner bedöms av SGP.22-interoperabilitet och aktiverings-UX; IoT-tillgångar bedöms av eIM/IPA-operabilitet och motståndskraft i begränsade nätverk.

En användbar varning från IoT-sidan gäller också kommersiellt: teknisk portabilitet i en specifikation är inte automatiskt lika med kommersiell portabilitet i ett kontrakt. SGP.32 minskar vissa arkitektoniska inlåsningar associerade med SGP.02, men leverantörens kommersiella villkor bestämmer fortfarande hur fritt flottor kan flytta eIM-associationer eller externa SM-DP+ relationer (1oT). Konsumentresenärer står inför en liknande läxa i mindre skala - interoperabel RSP garanterar inte i sig själv identisk täckningskvalitet, rättvis användningspolicy eller supportupplevelse över leverantörer.

Marknadstiming och antagandesignaler (offentlig, 2025-2026) #

Offentliga GSMA-material 2026 beskriver konsument-eSIM som går in i operativ skala snarare än bevis på koncept. Enligt GSMAs sammanfattning från maj 2026 av GSMA Intelligence-siffror var den globala eSIM-smarttelefonpenetrationen cirka 5% i slutet av 2025, med en angiven väg till cirka 10 % till slutet av 2026, och ytterligare tillväxt därefter; samma artikel nämner ungefär tre av fyra / 73 % av mobilnätsoperatörerna som erbjuder kommersiell smartphone eSIM, samtidigt som den noterar det kvarstående gapet mellan tillgänglighet och aktiv konsumentaktivering (GSMA massmarknads eSIM-artikel).

På IoT-sidan lyfter samma GSMA-kommentar fram SGP.32 som en strukturell möjliggörare för globala produktvarianter och profilväxling i fält - språk som matchar hur IoT-plattformar positionerar standarden. Specifikationsmognad är också synlig i GSMAs offentliga tabeller: SGP.31/SGP.32 fortsätter att avancera genom aktiva v1.2 och nyare v1.3-listningar under 2024-2026, tillsammans med tillhörande testspecifikationer (GSMA specifikationsindex).

Tolkning utan överdrifter: konsumentresor eSIM är redan ett skalat kommersiellt användningsfall på SGP.22-spår; SGP.32 är den parallella industrialiseringen av IoT RSP. De förstärker den bredare eSIM-berättelsen utan att ersätta varandra.

Vad resenärer och varumärken bör ta med sig #

För resenärer #

Du behöver inte välja mellan SGP.22 och SGP.32 när du köper en reseplan. Om du installerar en eSIM på en telefon via QR-kod eller app, befinner du dig i konsument RSP-världen. Det du bör bry dig om är praktiskt: enhetens kompatibilitet, installationspålitlighet före avresa, täckning på destinationen, transparenta rättvisa användarvillkor och support när något går fel vid gaten.

Leverantörer som Roamify befinner sig i det konsumentreselaget - destinationsplaner, digital installation och hålla sig online utomlands - snarare än i industriell eIM-flottahantering. Standardberättelsen bakom QR är fortfarande SGP.22-formad.

För resevarumärken, OTAs, fintechs och konsument-MVNOs #

• Behandla SGP.22-interoperabilitet och aktiverings-UX som produktens grund.
• Marknadsför inte “SGP.32” som en resenärsinriktad uppgradering om inte din faktiska hårdvara/flottarkitektur använder IoT RSP.
• Om du säljer eller vitmärker anslutning för spårare, routrar eller B2B-reseutrustning, utvärdera separat om enhetsklassen behöver konsument-LPA-flöden, IoT eIM-flöden eller ett stegvis hybrid.
• Investera i utbildning: GSMAs egen marknadskommentar pekar fortfarande på ett gap mellan eSIM-tillgänglighet och konsumentförståelse/aktivering. Tydlig installationsvägledning förblir en konkurrensfördel.

För operatörer och anslutningsplattformar #

Att köra konsument- och IoT RSP sida vid sida blir allt vanligare. Delad SM-DP+-arv hjälper, men certifiering, säkerhetsackreditering, enhetsagenter (LPA vs IPA) och kommersiella operativa modeller förblir distinkta. Att blanda vokabulärerna i offentlig kommunikation skapar falska förväntningar för både resenärer och företagsköpare.

Slutsats: två standarder, en eSIM-berättelse - håll banorna tydliga #

SGP.22 och SGP.32 är inte rivaler på en enda topplista. De är svar på två enhetsrealiteter:

• SGP.22 antar att en person är närvarande och kan dra en profil till en konsumentenhet. Det är arkitekturen bakom moderna rese-eSIM på telefoner.
• SGP.32 antar att enheten är ensam - eller sover - och behöver fjärrstyrd, flottkapabel hantering genom eIM och IPA, samtidigt som SM-DP+-profilleverans återanvänds. Det är arkitekturen GSMA byggde för begränsad IoT efter att SGP.02:s begränsningar blev uppenbara.

För reseanslutning är den strategiska lärdomen precision. Konsument-RSP-vägen omformar redan hur människor köper roaming. IoT RSP-vägen omformar hur maskiner förblir anslutna i åratal. Varumärken som håller dessa banor tydliga kommer att förklara eSIM mer trovärdigt - och bygga produkter som matchar standarden de faktiskt levererar.

Mjuk varumärkesnotering: Roamify är en rese-eSIM-leverantör som erbjuder planer över många destinationer med digital aktivering för kompatibla telefoner. Denna artikel är standardutbildning, inte ett påstående att Roamify implementerar IoT SGP.32 flottahantering.