SGP.22 vs SGP.32: quem ativa

A pessoa junto ao dispositivo decide a especificação

A diferença entre SGP.22 e SGP.32 não está no rádio nem no formato do SIM. Está em quem está presente quando um perfil é ativado. SGP.22 pressupõe um usuário com tela que consegue ler um código, ver um aviso e confirmar um download. SGP.32 pressupõe um gestor de frota em um backend que ativa um dispositivo sem tela e sem ninguém ao lado.

Essa premissa decide a arquitetura, o caminho de falha e a equipe que opera. Um dispositivo de consumo precisa de um fluxo de ativação que uma pessoa consiga concluir. Uma frota sem equipe no local precisa de um sistema de gestão que selecione, baixe, habilite, suspenda e retire perfis sem mandar ninguém ao local.

SGP.22 em um minuto

Uma operadora ou provedor de perfis prepara um perfil em um SM-DP+, e um servidor de descoberta, o SM-DS, pode avisar o dispositivo de que há um perfil disponível. Um assistente de perfil local no dispositivo baixa o perfil, instala e habilita depois do consentimento do usuário. O gatilho costuma ser um QR code, um código de ativação ou um aplicativo. O fluxo pressupõe uma loja de aplicativos, um menu de ajustes e um usuário que consegue resolver um download com falha.

SGP.32 em um minuto

Um gerenciador IoT de eSIM, o eIM, fica no backend da empresa ou do provedor e orquestra downloads, trocas e exclusões de perfis em uma frota, em conjunto com um SM-DP+ que prepara o perfil e um SM-DS opcional. Um assistente de perfil IoT, o IPA, roda no dispositivo ou na eUICC e executa os comandos. O dispositivo precisa de alguma conectividade para o primeiro perfil: um perfil de bootstrap, uma rede local ou outro caminho temporário. O modelo é feito para escala, para hardware já instalado e para mudanças que não podem esperar uma visita.

O que mudou desde o SGP.02

SGP.02 foi a especificação de provisionamento remoto M2M. Usava um gerenciador de assinaturas com papel de roteamento seguro entre o provedor de perfis e o dispositivo, antes de o ecossistema de eSIM de consumo amadurecer. SGP.32 separa a orquestração da operadora: o eIM seleciona e gere perfis, o IPA executa no dispositivo e o download usa conectividade IP padrão. O resultado são menos peças específicas de operadora e um modelo de gestão que serve a uma frota empresarial.

Instalações SGP.02 costumavam ser construídas em torno de plataformas específicas de operadora. SGP.32 coloca a orquestração na empresa ou no provedor de conectividade, o que facilita frotas multioperadora, mas torna mais importante a escolha do eIM e do dono dos perfis. Pergunte quem opera o eIM, quem mantém o inventário de perfis e como funciona a transição no fim do contrato.

A migração é um plano de hardware

Dispositivos SGP.02 já instalados não migram com um interruptor de software. A eUICC, o módulo e a plataforma de gestão precisam suportar SGP.32, então a mudança acontece quando o hardware é substituído. Divida a frota em dois grupos: dispositivos que vão terminar a vida em SGP.02 e dispositivos cuja substituição pode levar o fluxo novo.

Para o segundo grupo, teste o fluxo novo antes de enviar a primeira substituição. Confirme o caminho de bootstrap, a transição para o eIM e o inventário de perfis. Mantenha a plataforma antiga capaz de ler a base instalada até o último dispositivo sair, porque uma frota mista precisa de dois registros que batam.

O perfil tem uma vida

Um perfil é pedido, baixado, instalado, habilitado, usado, suspenso, trocado e excluído. Cada passo precisa de um responsável e de um registro. O pedido liga o perfil a um EID e a um ICCID. O download precisa de conectividade e de um gatilho. A habilitação ativa o perfil e desabilita o anterior. A troca repete download e habilitação para um perfil novo. A exclusão remove o perfil da eUICC e libera o espaço.

Registre o EID, o ICCID e o IMSI em cada passo. O EID identifica o chip, o ICCID identifica o perfil e o IMSI identifica a assinatura que a rede autentica. Sem esse registro, uma troca vira um chute sobre qual perfil está em qual dispositivo. Teste o ciclo completo, incluindo um download com falha e um rollback, antes de escalar.