Standard SGP.32: la realtà architetturale oltre l’hype del settore

L’industria dell’IoT è attualmente concentrata su un unico acronimo: SGP.32. Sebbene la promessa di un passaggio fluido tra profili sia un ottimo argomento di marketing, la realtà tecnica è molto più complessa. In 1NCE, riteniamo che SGP.32 non sia un semplice prodotto da acquistare, ma un cambiamento architetturale complesso da implementare. È un passo importante verso un ecosistema di SIM definito dal software, ma il passaggio a una distribuzione reale richiede numerose dipendenze tecniche.

Gli standard eSIM precedenti hanno già risolto problemi importanti

Per comprendere perché lo standard SGP.32 sta mettendo in discussione lo status quo, è necessario esaminare la storia tecnica che lo ha preceduto. Prima dell’introduzione dello standard SGP.32, due standard GSMA avevano gettato le basi per l’attivazione remota delle schede SIM:

• SGP.02 (M2M): Questo standard industriale tradizionale si basa su un modello "push". L'operatore di rete mobile (MNO) gestisce il cambio di profilo tramite un sistema SM-SR (Subscription Manager-Secure Routing). Pur essendo affidabile, tale sistema è tecnicamente rigido e richiede spesso migrazioni costose e complesse tra le piattaforme degli operatori.

• SGP.22 (Consumatori): Si tratta dello standard eSIM presente negli smartphone moderni. Utilizza un modello "pull", in cui è l'utente a dare il via al download del profilo, spesso tramite la scansione di un codice QR con l'ausilio di un Local Profile Assistant (LPA). Poiché richiede un intervento manuale, risulta in gran parte inadatto ai dispositivi IoT non presidiati.

Entrambi gli standard funzionano bene negli ambienti per cui sono stati concepiti, ma le implementazioni IoT spesso si collocano in una via di mezzo. I dispositivi potrebbero non disporre di schermi o interfacce utente, oppure funzionare in modo autonomo per anni, e vengono spesso gestiti come gruppi piuttosto che singolarmente. È proprio per questo scenario che è stato progettato lo standard SGP.32:

• Il processo di "prelievo" è automatizzato: Anziché che sia una persona a scansionare un codice, un componente software presente sul dispositivo (l'IPA, ovvero l'IoT Profile Assistant) può "recuperare" automaticamente un profilo in base a regole prestabilite.

• L'iniziativa riguarda l'intera flotta: Un gestore cloud (l'eIM o l'eSIM IoT Remote Manager) può "inviare" istruzioni a migliaia di dispositivi contemporaneamente affinché questi "scarichino" un nuovo profilo.

SGP.02 vs. SGP.22 vs. SGP.32 (Cambio di profilo) 

Nuovi componenti dell'architettura SGP.32 

La specifica SGP.32 introduce un'architettura leggermente diversa per la gestione dei profili di connettività. Anziché basarsi principalmente su infrastrutture controllate dagli operatori, la nuova specifica aggiunge componenti che consentono alle piattaforme dei dispositivi e ai sistemi IoT di assumere un ruolo più attivo.

SGP.32 contro SGP.22

Lo standard introduce i seguenti elementi che ridefiniscono le regole della gestione della connettività:

• Assistente per i profili IoT (IPA): Nel mondo consumer, l'LPA è un'app installata sul telefono. In SGP.32, questa viene sostituita dall'IPA, che risiede sul dispositivo IoT stesso. L'IPA può essere implementata in due modi: IPAd (sul software del dispositivo) o IPAe (sul chip eSIM stesso). Essa funge da proxy fondamentale tra l'eSIM e il gestore remoto.

• eSIM IoT Remote Manager (eIM): Questo è il "cervello" dell'operazione. L'eIM consente a un produttore OEM di dispositivi IoT di attivare, disattivare o eliminare da remoto i profili su un parco dispositivi tramite una piattaforma cloud centralizzata.

SM-DP+: Subscription Manager-Data Preparation+ sostituisce la precedente infrastruttura SM-DP/SM-SR, ottimizzando la distribuzione dei profili operatore crittografati.

Teniamo presente che il passaggio a SGP.32 non consiste in una semplice patch software, ma richiede una revisione completa dello stack dal dispositivo al cloud.

Sfide relative all'attuazione dell'SGP.32 

Sul mercato circolano numerose informazioni errate. Per proteggere i nostri clienti dai rischi legati all'architettura, dobbiamo chiarire cosa SGP.32 non è in grado di fare al momento:

1. La dipendenza dall'hardware: Uno dei miti più diffusi è che lo standard SGP.32 possa essere applicato retroattivamente alle SIM esistenti. Non è così. Lo standard SGP.32 richiede una nuova generazione di hardware SIM compatibile con eUICC, progettato specificamente per supportare i nuovi set di comandi e i moduli IPA.

2. Integrazione a livello di dispositivo: Poiché l'IPA deve risiedere sul dispositivo, l'implementazione dello standard SGP.32 richiede spesso una riprogettazione dell'hardware o del firmware. Per molte aziende che dispongono di hardware legacy, il passaggio allo standard SGP.32 non consiste in una semplice patch software, ma rappresenta un'impresa ingegneristica di notevole entità.

3. Maturità della catena di fornitura: L'ecosistema sta ancora recuperando terreno. Dalla disponibilità di moduli certificati SGP.32 alla capacità degli operatori di rete mobile di fornire profili compatibili, la catena di fornitura è in continua evoluzione.

4. Complessità architettonica: SGP.32 trasforma la connettività in un progetto. Richiede di definire chi è il titolare dell'eSIM, come vengono gestiti i profili di avvio e in che modo il dispositivo gestisce il cambio di profilo nelle aree con scarsa copertura.

SGP.32 rappresenta un'evoluzione significativa, ma il suo successo dipende interamente dalla risoluzione di tali dipendenze hardware e di integrazione con largo anticipo rispetto all'introduzione sul mercato del primo dispositivo.

In quali casi è opportuno utilizzare SGP.32? 

È importante ricordare che i deployment IoT sono molto diversi tra loro. Alcuni progetti traggono vantaggio da modelli di connettività semplici, in cui i dispositivi si connettono globalmente tramite roaming. Altri richiedono strategie più flessibili.

Probabilmente non hai bisogno di SGP.32 se: i tuoi obiettivi principali sono una migliore copertura, costi più bassi o un unico SKU per la distribuzione globale. In 1NCE, questi problemi sono già risolti con la nostra Global SIM (GSIM) e con la funzionalità “Freedom to Switch” basata su SGP.02.

Dovresti considerare SGP.32 se: stai pianificando un deployment internazionale su larga scala in cui il roaming non è sufficiente a causa di normative locali (come in Brasile o in Turchia), stai già prevedendo una riprogettazione hardware e il tuo team tecnico è pronto a gestire un progetto strutturato di integrazione aziendale.

La prospettiva di 1NCE: il pragmatismo prima della promozione 

In 1NCE, la nostra posizione è chiara: siamo sostenitori pragmatici di SGP.32. Lo consideriamo la fase successiva della nostra capacità “Freedom to Switch”. Per i clienti giusti, rappresenta un percorso verso un futuro realmente basato su SIM software-defined.

Tuttavia, a causa degli attuali requisiti tecnici, offriamo il supporto a SGP.32 come progetto personalizzato, guidato dai nostri Solution Architect.

L’arrivo di SGP.32 dimostra che il settore IoT sta maturando. La connettività non è più un semplice prodotto da acquistare, ma un livello architetturale da costruire. Invitiamo i nostri clienti ad andare oltre le promesse di switching immediato spesso diffuse nel settore. Ponetevi invece le domande giuste: il vostro hardware è pronto per un IPA? Avete l’infrastruttura per gestire un eIM? La maggiore complessità giustifica il ritorno sull’investimento rispetto a una soluzione di roaming globale di alta qualità?

SGP.32 è un passo importante verso un futuro senza soluzione di continuità per le SIM, e 1NCE è qui per accompagnarvi in questa transizione con credibilità tecnica e visione architetturale. Il futuro è software-defined, ma l’implementazione deve restare ancorata alla realtà.