Norma SGP.32: a realidade arquitetônica por trás do hype do setor

Atualmente, o setor de IoT está focado em uma sigla: SGP.32. Embora a promessa de troca de perfis sem interrupções seja atraente do ponto de vista de marketing, a realidade técnica é muito mais complexa.

Na 1NCE, entendemos que o SGP.32 não é um produto pronto para uso, mas uma mudança arquitetônica significativa. Trata-se de um passo importante rumo a um ecossistema de SIM definido por software, mas sua implementação em produção envolve diversas dependências técnicas.

Os padrões anteriores de eSIM já resolveram problemas importantes 

Para entender por que o SGP.32 está desafiando o status quo, é importante analisar a evolução técnica que veio antes dele. Antes do SGP.32, duas normas da GSMA estabeleceram as bases para o provisionamento remoto de SIM:

• SGP.02 (M2M): padrão tradicional da indústria, baseado em um modelo de “push”. A operadora móvel (MNO) controla a troca de perfis por meio do sistema SM-SR. É uma abordagem robusta, mas rígida, que frequentemente exige migrações complexas entre operadoras.

• SGP.22 (Consumidor): padrão presente em smartphones modernos. Utiliza um modelo de “pull”, no qual o usuário inicia o download de um perfil, geralmente escaneando um QR code por meio de um LPA (Local Profile Assistant). Como depende de interação humana, não é adequado para dispositivos IoT autônomos.

Ambas as normas funcionam bem nos contextos para os quais foram criadas. No entanto, as implantações de IoT geralmente ficam em um ponto intermediário:
dispositivos sem interface, operando por anos sem supervisão e gerenciados em escala, não individualmente.

É justamente para esse cenário que o SGP.32 foi desenvolvido:

• O "Pull" é automatizado: Em vez de uma pessoa escanear um código, um componente de software no dispositivo (o IPA, ou Assistente de Perfil de IoT) pode buscar um perfil automaticamente com base em regras predefinidas.

• A gestão abrange toda a frota: Um gerenciador em nuvem (o eIM, ou eSIM IoT Remote Manager) pode enviar instruções para milhares de dispositivos ao mesmo tempo, permitindo que eles baixem um novo perfil automaticamente.

SGP.02 vs. SGP.22 vs. SGP.32 (Troca de perfil) 

Novos componentes da arquitetura SGP.32 

A SGP.32 introduz uma arquitetura diferente para o gerenciamento de perfis de conectividade. Em vez de depender principalmente da infraestrutura das operadoras, a nova especificação adiciona componentes que permitem que plataformas de dispositivos e sistemas de IoT assumam um papel mais ativo.

SGP.32 x SGP.22

A norma apresenta os seguintes componentes que redefinem o gerenciamento da conectividade:

• Assistente de Perfil de IoT (IPA): No contexto de consumo, o LPA é um aplicativo no smartphone. No SGP.32, ele é substituído pelo IPA, que roda diretamente no dispositivo IoT. O IPA pode ser implementado de duas formas: IPAd (no software do dispositivo) ou IPAe (no próprio chip eSIM). Ele atua como o principal intermediário entre o eSIM e o gerenciador remoto.

• Gerenciador Remoto de eSIM para IoT (eIM): Este é o “cérebro” da operação. O eIM permite que fabricantes de dispositivos IoT (OEMs) ativem, desativem ou excluam perfis remotamente em toda a frota, a partir de uma plataforma centralizada na nuvem.

• SM-DP+: O Subscription Manager Data Preparation+ substitui a infraestrutura anterior (SM-DP/SM-SR), simplificando a entrega de perfis de operadoras de forma segura e criptografada.

É importante entender que a transição para o SGP.32 não se trata apenas de uma atualização de software, mas de uma reformulação completa da arquitetura de comunicação entre o dispositivo e a nuvem.

Desafios à implementação da SGP.32 

Existe uma quantidade significativa de desinformação no mercado. Para proteger nossos clientes de riscos arquitetônicos, é fundamental deixar claro o que o SGP.32 ainda não é capaz de fazer:

1. A dependência de hardware: Um dos mitos mais comuns é que o SGP.32 pode ser aplicado retroativamente aos SIMs existentes. Isso não é possível. O SGP.32 exige uma nova geração de SIMs compatíveis com eUICC, projetados especificamente para suportar novos conjuntos de comandos e módulos IPA.

2. Integração no lado do dispositivo: Como o IPA precisa estar presente no dispositivo, a implementação do SGP.32 geralmente exige alterações no hardware ou no firmware. Para muitas empresas com dispositivos já existentes, essa transição não é apenas uma atualização de software, mas um projeto de engenharia significativo.

3. Maturidade da cadeia de suprimentos: O ecossistema ainda está em evolução. Desde a disponibilidade de módulos compatíveis com SGP.32 até a preparação das operadoras para fornecer perfis adequados, a cadeia de suprimentos continua em transformação.

4. Complexidade arquitetônica: O SGP.32 transforma a conectividade em um projeto estruturado. Isso envolve definir quem controla o eSIM, como os perfis iniciais são gerenciados e como o dispositivo lida com trocas de perfil em áreas com baixa cobertura.

O SGP.32 representa uma evolução importante, mas seu sucesso depende diretamente da resolução dessas questões de hardware e integração, muito antes de qualquer dispositivo entrar em operação.

Em que situações faz sentido utilizar o SGP.32?

É importante lembrar que as implantações de IoT variam bastante. Alguns projetos se beneficiam de modelos simples de conectividade, nos quais os dispositivos se conectam globalmente por meio de acordos de roaming. Outros exigem estratégias mais flexíveis.

Provavelmente, não precisa do SGP.32 se: Seus principais objetivos são melhorar a cobertura, reduzir custos ou trabalhar com um único SKU para implantações internacionais.

Nesse caso, soluções como o SIM Global (GSIM) da 1NCE e os recursos de “Freedom to Switch”, baseados no SGP.02, já atendem bem a essas necessidades.

Deve considerar o SGP.32 se: estiver planejando uma implantação internacional em grande escala, em que o roaming não é suficiente devido a regulamentações locais (como no Brasil ou na Turquia), se estiver desenvolvendo uma nova geração de hardware e se sua equipe técnica estiver preparada para conduzir um projeto estruturado de integração.

A abordagem da 1NCE é baseada no pragmatismo, e não no hype

Na 1NCE, nossa posição é clara: adotamos uma abordagem pragmática em relação ao SGP.32. Vemos essa tecnologia como a próxima evolução da nossa proposta de “Freedom to Switch”. Para os clientes certos, ela abre caminho para um futuro em que os SIMs sejam verdadeiramente definidos por software. No entanto, devido aos requisitos técnicos atuais, oferecemos suporte ao SGP.32 por meio de projetos personalizados, liderados por nossos arquitetos de soluções.

A chegada do SGP.32 mostra que o setor de IoT está amadurecendo. A conectividade deixa de ser apenas um produto e passa a ser uma camada arquitetônica que precisa ser construída. Por isso, incentivamos nossos clientes a ir além das promessas de troca instantânea frequentemente associadas a essa tecnologia. Em vez disso, vale fazer as perguntas certas: seu hardware está preparado para suportar um IPA? Você tem a infraestrutura necessária para gerenciar um eIM? A complexidade adicional compensa o retorno sobre o investimento (ROI) em comparação com uma solução de roaming global bem estabelecida?

O SGP.32 representa um passo importante rumo a um futuro de conectividade mais flexível e definida por software. A 1NCE está ao seu lado para ajudar nessa transição, com credibilidade técnica e visão arquitetônica. O futuro é definido por software, mas a implementação precisa ser prática e bem planejada.