SGP.22 vs SGP.32 - cosa significa il cambiamento dello standard eSIM per la connettività in viaggio

Obiettivo: Fornire agli acquirenti di eSIM per viaggi e agli operatori di viaggi/MVNO una mappa informata sugli standard di fornitura remota di SIM per consumatori vs IoT - in modo che il discorso sull'“il prossimo standard eSIM” non confonda due strade diverse.

Pubblico: Professionisti che spediscono o acquistano connettività per viaggiatori (e chiunque valuti hardware IoT/viaggi correlato), non membri del comitato GSMA.

Se acquisti un'eSIM per viaggi, scansiona un codice QR e atterri con dati, sei già all'interno di un'architettura di Fornitura Remota di SIM (RSP) GSMA - anche se non vedi mai i numeri delle specifiche. Quei numeri contano.SGP.22 è lo standard tecnico RSP per consumatori dietro i flussi di eSIM per smartphone e viaggi.SGP.32 è lo standard tecnico RSP per IoT per dispositivi senza schermo, vincolati e su scala flotta. Condividono alcuni elementi costitutivi. Risolvono problemi diversi.

Questa distinzione è facile da confondere nelle presentazioni di marketing. È anche la differenza tra un viaggiatore che installa un profilo temporaneo su un telefono e un'azienda che orchestra la connettività su migliaia di sensori che non vedranno mai uno schermo. Per i marchi di viaggio, gli MVNO e chiunque costruisca su stack eSIM per consumatori, sapere dove finisce SGP.22 e inizia SGP.32 è fondamentale - non perché i viaggiatori abbiano bisogno di PDF GSMA, ma perché la conversazione nel settore spesso mescola le strade dei consumatori e dell'IoT.

Questo articolo mappa architettura, attori, differenze di ciclo di vita e implicazioni pratiche per la connettività in viaggio - senza trattare SGP.32 come un aggiornamento immediato per il roaming dei consumatori.

Perché l'industria aveva bisogno di più di uno "standard" eSIM #

L'eSIM non è un unico protocollo. È una famiglia di specifiche GSMA che definiscono come i profili degli operatori vengono preparati, consegnati, installati, abilitati, disabilitati e cancellati in modo sicuro su un eUICC (la piattaforma SIM integrata).

L'indice delle specifiche pubbliche di GSMA rende esplicita la divisione: l'RSP per i consumatori si trova sotto SGP.21 (architettura) e SGP.22 (tecnico); l'RSP per l'IoT si trova sotto SGP.31 (architettura e requisiti) e SGP.32 (tecnico). Le versioni attive per i consumatori continuano attraverso SGP.22 v2.x e v3.x; le versioni per l'IoT continuano attraverso SGP.31/SGP.32 v1.x, incluse le revisioni più recenti 2024-2026 sulla pagina delle specifiche eSIM di GSMA (GSMA eSIM Consumer and IoT Specifications).

Prima di SGP.32, il provisioning remoto per IoT e M2M era in gran parte basato su un modello precedente macchina-a-macchina (SGP.02), con una divisione a doppio server di SM-DP (preparazione dei dati) e SM-SR (instradamento sicuro). Quel modello consentiva la gestione remota dei profili per casi d'uso industriali e automobilistici, ma portava anche a frizioni operative: trigger orientati agli SMS, accoppiamento commerciale più stretto SM-SR/SM-DP e una scarsa adattabilità per dispositivi LPWAN altamente vincolati. Gli operatori e gli spiegatori delle piattaforme IoT citano costantemente questi vincoli come la ragione per cui GSMA ha costruito un'architettura IoT dedicata piuttosto che forzare l'RSP per i consumatori su ogni modem (Eseye su SGP.31/32; 1oT su SGP.02 vs SGP.22 vs SGP.32).

Versione breve: un unico fattore di forma fisico (eSIM/eUICC), molteplici filosofie di provisioning.

SGP.22 in termini semplici: RSP per i consumatori per dispositivi con un umano nel loop #

SGP.22 è la descrizione tecnica di GSMA del Remote SIM Provisioning per i dispositivi dei consumatori. Il suo scopo è inequivocabile: una soluzione tecnica per il provisioning remoto e la gestione dell'eUICC nei dispositivi dei consumatori, mirata all'interoperabilità tra le implementazioni degli operatori - inclusi le piattaforme SM-DP+ e i fornitori di eUICC.

Attori principali nel modello per i consumatori #

Ruoli degli attori #

• eUICC: Piattaforma sicura che memorizza i profili (credenziali degli operatori e componenti correlati)
• LPA (Local Profile Assistant): Assistente sul dispositivo (o parzialmente su eUICC) che gestisce il download, l'abilitazione/disabilitazione/cancellazione locale e la gestione dei profili per l'utente
• SM-DP+: Subscription Manager - Data Preparation +: prepara, protegge e consegna i pacchetti di profili vincolati
• SM-DS: Subscription Manager - Discovery Service: percorso di scoperta opzionale quando il dispositivo deve trovare il giusto SM-DP+ senza un codice QR/di attivazione
• Operatore / emittente del profilo: Possiede l'abbonamento commerciale dietro il profilo

Nel flusso che i viaggiatori riconoscono:

1. Acquista un piano di viaggio e ricevi un codice di attivazione (spesso come un QR).
2. Il dispositivo LPA contatta l'SM-DP+.
3. Il pacchetto profilo criptato viene scaricato e installato sull'eUICC.
4. L'utente abilita il profilo (e può successivamente disabilitarlo o eliminarlo).

Questo è un modello avviato dall'utente / orientato al pull. Una persona è presente, il dispositivo ha un'interfaccia utente e il consenso è un'azione di installazione esplicita. Ecco perché il checkout delle eSIM per viaggi, le partnership con compagnie aeree/fintech e l'attivazione tramite app si collegano tutte al RSP di classe SGP.22 per i consumatori - non all'orchestrazione di flotte IoT.

Il trasporto HTTPS/TLS si adatta agli smartphone. È più pesante di quanto molti cicli di lavoro IoT possano permettersi, ma ragionevole per un telefono che già mantiene la connettività IP e un'intera pila di sicurezza.

SGP.32 in termini semplici: RSP IoT per dispositivi che non possono selezionare “Aggiungi eSIM” #

SGP.32 è la specifica tecnica per l'architettura eSIM IoT di GSMA definita in SGP.31. GSMA la descrive come coprente la fornitura e la gestione remota dell'eUICC nei dispositivi IoT che sono limitati dalla rete e/o dall'interfaccia utente, oltre all'architettura eUICC, alle interfacce e alle funzioni di sicurezza per quel modello.

Attori principali nel modello IoT #

Ruoli degli attori #

• eUICC: eUICC compatibile con IoT che memorizza i profili e supporta le associazioni di gestione remota IoT
• IPA (Assistente Profilo IoT): Assistente lato dispositivo o eUICC che esegue il lavoro di fornitura/gestione senza un'interfaccia utente per il consumatore; può essere IPAd (sul dispositivo) o IPAe (su eUICC)
• eIM (Gestore Remoto eSIM IoT): Entità cloud/orchestrazione che emette operazioni sul ciclo di vita del profilo per un dispositivo o una flotta
• SM-DP+: Riutilizzato dall'ecosistema consumer per la preparazione del profilo e la consegna protetta
• SM-DS: Ruolo di scoperta mantenuto dove rilevante
• Operatore: Fonte del profilo, come nel RSP consumer

L'intento architettonico è coerente nei materiali GSMA e nelle spiegazioni del settore: mantenere ciò che già funzionava nel RSP consumer (in particolare SM-DP+), e sostituire l'assunzione umana/LPA con un gestore remoto più un assistente nativo IoT (Spiegazione degli standard Velocity IoT; confronto 1oT).

Perché l'IoT aveva bisogno di un modello diverso #

Il RSP consumer presuppone:

• uno schermo o un'esperienza utente complementare,
• una persona che può avviare il download,
• connettività IP relativamente stabile per sessioni TLS,
• decisioni sul ciclo di vita guidate dall'utente per dispositivo.

le flotte IoT spesso assumono il contrario:

• nessuna interfaccia utente,
• connettività intermittente o a bassa larghezza di banda (inclusi scenari LPWAN),
• check-in asincroni piuttosto che sessioni sempre attive,
• abilitazione/disabilitazione/eliminazione guidata da policy su molti EID contemporaneamente.

SGP.31/32 introduce quindi la gestione dello stato del profilo orientata alla flotta e un eIM che può attivare o fare da proxy per i download. Le analisi del settore sottolineano anche le opzioni di protocollo leggero (ad esempio CoAP/DTLS come percorso alternativo per dispositivi con vincoli), la rimozione di SMS come dipendenza rigida per l'RSP IoT moderno e il supporto per la consegna diretta vs. indiretta del profilo a seconda che il dispositivo possa comunicare comodamente con l'SM-DP+ stesso (Eseye; 1oT).

Criticamente, SGP.32 non è un “aggiornamento software” retrocompatibile per ogni eUICC SGP.02 già sul campo. Eseye e altri specialisti IoT notano che le implementazioni standard M2M tipicamente rimangono su quel modello fino alla fine del ciclo di vita; il greenfield IoT è dove SGP.32 è progettato per diventare il predefinito.

SGP.22 vs SGP.32: confronto strutturato #

Confronto dimensione per dimensione #

Coppia GSMA primaria

• SGP.22 (RSP consumer): architettura SGP.21 + tecnico SGP.22
• SGP.32 (IoT RSP): architettura/requisiti SGP.31 + tecnico SGP.32

Progettato per

• SGP.22 (consumer RSP): Smartphone, tablet, dispositivi indossabili, dispositivi consumer con UI
• SGP.32 (IoT RSP): Dispositivi IoT senza interfaccia / con interfaccia limitata / con rete limitata e flotte

Intervento umano?

• SGP.22 (consumer RSP): Sì - l'utente avvia o conferma l'installazione/cambio
• SGP.32 (IoT RSP): No - eIM/IPA orchestrano le operazioni da remoto

Assistente locale

• SGP.22 (consumer RSP): LPA
• SGP.32 (IoT RSP): IPA (IPAd o IPAe)

Orchestrazione remota

• SGP.22 (consumer RSP): Limitato / non il centro di design
• SGP.32 (IoT RSP): eIM come gestore remoto di prima classe

Server dei profili

• SGP.22 (RSP consumer): SM-DP+
• SGP.32 (IoT RSP): SM-DP+ (riutilizzato)

Scoperta

• SGP.22 (RSP consumer): SM-DS (opzionale in molti flussi)
• SGP.32 (IoT RSP): SM-DS mantenuto nell'architettura

Modello di attivazione

• SGP.22 (RSP consumer): Predominantemente pull (QR / codice di attivazione / app)
• SGP.32 (IoT RSP): Push e/o pull tramite eIM e modelli di check-in del dispositivo

Postura di trasporto

• SGP.22 (RSP consumer): Stack IP consumer centrato su HTTPS/TLS
• SGP.32 (IoT RSP): Basato su IP; opzioni per dispositivi con vincoli enfatizzate (ad es., percorsi CoAP/DTLS nei riassunti industriali della specifica)

Dolore del predecessore che affronta

• SGP.22 (RSP consumer): Sostituzioni fisiche di SIM e blocco dell'operatore sull'hardware consumer
• SGP.32 (IoT RSP): Blocco operativo SGP.02, dipendenza da SMS e scarsa adattabilità ai dispositivi con vincoli

Rilevanza delle eSIM per i viaggi

• SGP.22 (RSP consumer): Diretta - questo è lo stack dietro le tipiche installazioni di eSIM per viaggi su telefoni
• SGP.32 (IoT RSP): Indiretta - modella ecosistemi hardware IoT/viaggi adiacenti, non flussi QR per telefoni

Ciclo di vita del profilo: stessi verbi, grammatica diversa #

Entrambi i mondi parlano di scaricare, installare, abilitare, disabilitare e cancellare. La grammatica differisce:

• Ciclo di vita SGP.22 è locale e centrato sull'utente. Una volta installato, il viaggiatore (o l'interfaccia LPA) decide quando un profilo è abilitato per i dati in roaming, quando è messo in pausa e quando viene rimosso.
• Ciclo di vita SGP.32 è remoto e centrato sulle politiche. L'eIM può emettere operazioni di gestione dello stato del profilo su uno o molti EID, e l'IPA le esegue quando il dispositivo è raggiungibile - importante per i dispositivi che dormono la maggior parte della giornata.

Ecco perché “cambio di profilo” significa cose commerciali diverse in ciascun mondo. Nei viaggi consumer, il cambio è spesso un nuovo acquisto o un secondo profilo installato che l'utente seleziona. Nell'IoT, il cambio è un'operazione di gestione: cambiare fornitore di connettività, rispondere alla copertura o ruotare i profili senza un intervento fisico.

Dove si inseriscono le specifiche IoT precedenti: SGP.02 e SGP.31 #

Un modello mentale chiaro:

1. SGP.02 - RSP M2M originale con SM-DP + SM-SR. Fondamentale, ancora presente in contesti a lungo ciclo di vita (in particolare nel settore automobilistico e in altre implementazioni industriali), ma sempre più considerato come eredità per nuovi progetti IoT vincolati (1oT).
2. SGP.22 - RSP consumer che ha semplificato il provisioning attorno a SM-DP+ e LPA; il percorso di massa per telefoni e eSIM da viaggio.
3. SGP.31 / SGP.32 - RSP IoT che riutilizza SM-DP+ aggiungendo eIM + IPA per la gestione delle flotte senza testa.

SGP.32 non è apparso perché l'eSIM consumer ha "fallito". È apparso perché l'eSIM consumer ha avuto successo per gli esseri umani- e quel successo non risolve ancora un sensore fissato all'interno di un container di spedizione.

Implicazioni per eSIM da viaggio, roaming consumer e stack MVNO #

La connettività da viaggio rimane una storia di RSP consumer #

Per telefoni e la maggior parte dei dispositivi dei viaggiatori, lo standard operativo rimane RSP consumer di classe SGP.22. L'esperienza del prodotto a cui i viaggiatori tengono - acquistare prima della partenza, installare tramite QR o app, atterrare connessi - si mappa sui flussi LPA ↔ SM-DP+, non sui comandi di flotta eIM.

Il commento del settore GSMA del 2026 inquadra la connettività da viaggio come un cambiamento strutturale nel roaming internazionale: le offerte di eSIM da viaggio basate su app sono più trasparenti e flessibili, e la distribuzione si avvicina all'utente finale prima che il viaggio inizi (GSMA: il dispiegamento di massa delle eSIM passa dalla previsione al fatto). Quel cambiamento commerciale si basa sulla maturità del RSP consumer e sul supporto dei dispositivi, non sul lancio di eIM IoT.

Cosa cambia SGP.32 per gli ecosistemi adiacenti al viaggio #

Anche se i viaggiatori non toccano mai SGP.32, lo standard è importante ai margini del viaggio:

• Tracciatori di bagagli connessi, veicoli di flotta, sensori logistici e IoT di sede hanno sempre più bisogno di gestione remota dei profili senza una cerimonia QR.
• Router da viaggio e alcuni "hardware eSIM" possono trovarsi in un mezzo caotico: attivazione in stile consumer per un proprietario umano, ma esigenze operative che sembrano più simili a una flotta su larga scala.
• Operatori e MVNO possono gestire entrambi gli stati SM-DP+ consumer e gli stati eIM IoT. Condividere il DNA SM-DP+ tra SGP.22 e SGP.32 è intenzionale; non significa che le due classi di dispositivi condividano la stessa UX o percorso di certificazione.

Multi-IMSI, stack MVNO e confini veritieri #

Multi-IMSI (identità multiple selezionabili all'interno o accanto a un prodotto di connettività) e il download del profilo eUICC sono spesso discussi insieme, ma non sono lo stesso meccanismo. Multi-IMSI può migliorare il comportamento di attacco alla rete all'interno di un'offerta commerciale; eUICC RSP (SGP.22 o SGP.32) riguarda l'installazione e la gestione sicura dei profili completi dell'operatore su eUICC. I marchi di viaggio e gli MVNO possono combinare entrambe le tecniche commercialmente, ma la chiarezza dell'architettura è ancora importante: le installazioni di viaggio consumer sui telefoni sono giudicate dall'interoperabilità SGP.22 e dall'UX di attivazione; gli stati IoT sono giudicati dall'operabilità eIM/IPA e dalla resilienza della rete vincolata.

Un utile avvertimento dal lato IoT si applica anche commercialmente: la portabilità tecnica in una specifica non equivale automaticamente alla portabilità commerciale in un contratto. SGP.32 riduce alcuni schemi di lock-in architettonico associati a SGP.02, ma i termini commerciali del fornitore determinano ancora quanto liberamente le flotte possano spostare le associazioni eIM o le relazioni SM-DP+ esterne (1oT). Gli acquirenti di viaggi consumer affrontano una lezione analoga su scala più piccola: un RSP interoperabile non garantisce, di per sé, una qualità di copertura identica, una politica di uso corretto o un'esperienza di supporto uniforme tra i fornitori.

Tempistica di mercato e segnali di adozione (pubblico, 2025-2026) #

I materiali pubblici GSMA nel 2026 descrivono l'eSIM consumer che entra in scala operativa piuttosto che come prova di concetto. Secondo il riepilogo di maggio 2026 di GSMA Intelligence, la penetrazione globale degli smartphone eSIM era circa 5% alla fine del 2025, con un percorso dichiarato verso circa 10% entro la fine del 2026, e ulteriore crescita successivamente; lo stesso articolo cita circa tre su quattro / 73% degli operatori di rete mobile che offrono eSIM per smartphone commerciali, pur notando il divario rimanente tra disponibilità e attivazione attiva da parte dei consumatori (articolo GSMA sul mercato di massa delle eSIM).

Sul lato IoT, lo stesso commento GSMA evidenzia SGP.32 come un abilitatore strutturale per varianti di prodotto globali e cambio di profilo sul campo - un linguaggio che corrisponde a come le piattaforme IoT posizionano lo standard. La maturità delle specifiche è visibile anche nelle tabelle pubbliche di GSMA: SGP.31/SGP.32 continuano ad avanzare attraverso le attive v1.2 e le nuove v1.3 elencazioni nel 2024-2026, insieme alle specifiche di test associate (indice delle specifiche GSMA).

Interpretazione senza esagerare: le eSIM per viaggiatori sono già un caso d'uso commerciale su larga scala sui binari SGP.22; SGP.32 è l'industrializzazione parallela dell'IoT RSP. Rafforzano la storia più ampia delle eSIM senza sostituirsi a vicenda.

Cosa dovrebbero trarre viaggiatori e marchi #

Per i viaggiatori #

Non è necessario scegliere tra SGP.22 e SGP.32 quando acquisti un piano di viaggio. Se stai installando una eSIM su un telefono tramite codice QR o app, sei nel mondo consumer RSP. Ciò che dovrebbe interessarti è pratico: compatibilità del dispositivo, affidabilità dell'installazione prima della partenza, copertura della destinazione, termini di utilizzo equi e trasparenti, e supporto quando qualcosa va storto al gate.

Fornitori come Roamify si trovano in quel livello di viaggio per consumatori - piani di destinazione, installazione digitale e utilità per rimanere online all'estero - piuttosto che nella gestione della flotta industriale eIM. La storia degli standard dietro il QR è ancora modellata da SGP.22.

Per marchi di viaggio, OTA, fintech e MVNO per consumatori #

• Tratta l'interoperabilità SGP.22 e l'UX di attivazione come la base del prodotto.
• Non commercializzare “SGP.32” come un aggiornamento rivolto ai viaggiatori a meno che la tua architettura hardware/flotta effettiva non utilizzi IoT RSP.
• Se vendi o etichetti con marchio bianco la connettività per tracker, router o hardware di viaggio B2B, valuta separatamente se la classe del dispositivo necessita di flussi LPA per consumatori, flussi eIM per IoT, o un ibrido a tappe.
• Investi nell'educazione: il commento di mercato di GSMA stesso indica ancora un divario tra disponibilità delle eSIM e comprensione/attivazione da parte dei consumatori. Una guida chiara all'installazione rimane un differenziatore competitivo.

Per operatori e piattaforme di connettività #

Gestire RSP per consumatori e IoT fianco a fianco è sempre più normale. L'eredità condivisa SM-DP+ aiuta, ma la certificazione, l'accreditamento di sicurezza, gli agenti dei dispositivi (LPA vs IPA) e i modelli operativi commerciali rimangono distinti. Mescolare i vocabolari nei messaggi pubblici crea false aspettative sia per i viaggiatori che per gli acquirenti aziendali.

Conclusione: due standard, una narrativa eSIM - mantieni le corsie chiare #

SGP.22 e SGP.32 non sono rivali su una singola classifica. Sono risposte a due realtà dei dispositivi:

• SGP.22 presuppone che una persona sia presente e possa caricare un profilo su un dispositivo per consumatori. Questa è l'architettura dietro le moderne eSIM per viaggi su telefoni.
• SGP.32 presuppone che il dispositivo sia solo - o in standby - e necessiti di gestione remota, capace di flotta tramite eIM e IPA, pur riutilizzando la consegna del profilo SM-DP+. Questa è l'architettura che GSMA ha costruito per l'IoT vincolato dopo che i limiti di SGP.02 sono diventati evidenti.

Per la connettività di viaggio, la lezione strategica è la precisione. Il percorso RSP per consumatori sta già rimodellando il modo in cui le persone acquistano il roaming. Il percorso RSP per IoT sta rimodellando il modo in cui le macchine rimangono connesse per anni. I marchi che mantengono chiare queste corsie spiegheranno le eSIM in modo più credibile - e costruiranno prodotti che corrispondono allo standard che stanno effettivamente spedendo.

Nota di marchio morbida: Roamify è un fornitore di eSIM per viaggi che offre piani in molte destinazioni con attivazione digitale per telefoni compatibili. Questo articolo è un'educazione sugli standard, non un'affermazione che Roamify implementa la gestione della flotta IoT SGP.32.