SGP.22 vs SGP.32 - o que a mudança no padrão eSIM significa para a conectividade em viagens

Objetivo: Oferecer aos compradores de eSIM de viagem e operadores de viagem/MVNO um mapa conhecedor dos padrões de Provisionamento Remoto de SIM de consumidor vs IoT - para que a conversa da indústria sobre “o próximo padrão eSIM” não confunda dois caminhos diferentes.

Público: Profissionais que enviam ou compram conectividade de viagem para consumidores (e qualquer pessoa avaliando hardware adjacente de IoT/viagem), não membros do comitê GSMA.

Se você compra um eSIM de viagem, escaneia um código QR e desembarca com dados, você já está dentro de uma arquitetura de Provisionamento Remoto de SIM (RSP) da GSMA - mesmo que nunca veja os números das especificações. Esses números importam.SGP.22 é o padrão técnico de RSP de consumidor por trás dos fluxos de eSIM de smartphone e viagem.SGP.32 é o padrão técnico de RSP de IoT para dispositivos sem interface, restritos e em escala de frota. Eles compartilham alguns blocos de construção. Eles resolvem problemas diferentes.

Essa distinção é fácil de confundir em apresentações de marketing. Também é a diferença entre um viajante instalando um perfil temporário em um telefone e uma empresa orquestrando conectividade em milhares de sensores que nunca verão uma tela. Para marcas de viagem, MVNOs e qualquer pessoa construindo em pilhas de eSIM de consumidor, saber onde SGP.22 termina e SGP.32 começa é essencial - não porque os viajantes precisem de PDFs da GSMA, mas porque a conversa da indústria frequentemente mistura os caminhos de consumidor e IoT.

Este artigo mapeia arquitetura, atores, diferenças de ciclo de vida e implicações práticas para conectividade de viagem - sem tratar SGP.32 como uma atualização automática para roaming de consumidor.

Por que a indústria precisava de mais de um “padrão” de eSIM #

eSIM não é um único protocolo. É uma família de especificações da GSMA que definem como os perfis de operadora são preparados, entregues, instalados, habilitados, desabilitados e excluídos com segurança em um eUICC (a plataforma SIM embutida).

O índice de especificações públicas da GSMA torna a divisão explícita: o RSP do consumidor está sob SGP.21 (arquitetura) e SGP.22 (técnico); o RSP de IoT está sob SGP.31 (arquitetura e requisitos) e SGP.32 (técnico). As versões ativas para consumidores continuam através do SGP.22 v2.x e v3.x; as versões de IoT continuam através do SGP.31/SGP.32 v1.x, incluindo revisões mais recentes de 2024-2026 na página de especificações de eSIM da GSMA (Especificações de eSIM para Consumidor e IoT da GSMA).

Antes do SGP.32, o provisionamento remoto de IoT e M2M vivia amplamente em um modelo anterior de máquina a máquina (SGP.02), com uma divisão de servidor duplo de SM-DP (preparação de dados) e SM-SR (roteamento seguro). Esse modelo permitiu o gerenciamento remoto de perfis para casos de uso industrial e automotivo, mas também trouxe atritos operacionais: gatilhos orientados por SMS, acoplamento comercial mais rígido entre SM-SR/SM-DP e uma má adaptação para dispositivos LPWAN altamente restritos. Explicadores de operadoras e plataformas de IoT citam consistentemente essas restrições como a razão pela qual a GSMA construiu uma arquitetura dedicada para IoT em vez de forçar o RSP do consumidor em todos os modems (Eseye sobre SGP.31/32; 1oT sobre SGP.02 vs SGP.22 vs SGP.32).

Versão curta: uma forma física (eSIM/eUICC), múltiplas filosofias de provisionamento.

SGP.22 em termos simples: RSP do consumidor para dispositivos com um humano no loop #

SGP.22 é a descrição técnica da GSMA para o Provisionamento Remoto de SIM para dispositivos de consumo. Seu propósito é inequívoco: uma solução técnica para o provisionamento remoto e gerenciamento do eUICC em dispositivos de consumo, visando a interoperabilidade entre implantações de operadoras - incluindo plataformas SM-DP+ e fornecedores de eUICC.

Atores principais no modelo de consumo #

Papéis dos atores #

• eUICC: Plataforma segura que armazena perfis (credenciais de operadora e componentes relacionados)
• LPA (Assistente de Perfil Local): Assistente no dispositivo (ou parcialmente no eUICC) que conduz o download, habilitação/desabilitação/exclusão local e gerenciamento de perfil voltado para o usuário
• SM-DP+: Gerente de Assinatura - Preparação de Dados +: prepara, protege e entrega Pacotes de Perfil Vinculados
• SM-DS: Gerente de Assinatura - Serviço de Descoberta: caminho de descoberta opcional quando o dispositivo precisa encontrar o SM-DP+ correto sem um código QR/ativação
• Operadora / emissor do perfil: Possui a assinatura comercial por trás do perfil

No fluxo que os viajantes reconhecem:

1. Compre um plano de viagem e receba um código de ativação (geralmente como um QR).
2. O dispositivo LPA contata o SM-DP+.
3. O pacote de perfil criptografado é baixado e instalado no eUICC.
4. O usuário ativa o perfil (e pode desativá-lo ou excluí-lo posteriormente).

Este é um modelo iniciado pelo usuário / orientado por pull. Uma pessoa está presente, o dispositivo tem uma interface de usuário, e o consentimento é uma ação explícita de instalação. É por isso que a finalização de compra de eSIM de viagem, parcerias com companhias aéreas/fintechs e ativação baseada em aplicativos se encaixam no RSP de consumidor da classe SGP.22 - não na orquestração de frotas IoT.

O transporte HTTPS/TLS é adequado para smartphones. É mais pesado do que muitos ciclos de trabalho de IoT podem suportar, mas razoável para um aparelho que já mantém conectividade IP e uma pilha de segurança completa.

SGP.32 em termos simples: RSP IoT para dispositivos que não podem acessar “Adicionar eSIM” #

SGP.32 é a especificação técnica para a arquitetura eSIM IoT da GSMA definida no SGP.31. A GSMA descreve como abrangendo o provisionamento remoto e a gestão do eUICC em dispositivos IoT que são restritos por rede e/ou por interface de usuário, além da arquitetura eUICC, interfaces e funções de segurança para esse modelo.

Atores principais no modelo IoT #

Papéis dos atores #

• eUICC: eUICC compatível com IoT que armazena perfis e suporta associações de gerenciamento remoto IoT
• IPA (Assistente de Perfil IoT): Assistente no dispositivo ou no lado do eUICC que executa o trabalho de provisionamento/gestão sem uma interface de usuário para o consumidor; pode ser IPAd (no dispositivo) ou IPAe (no eUICC)
• eIM (Gerente Remoto de eSIM IoT): Entidade de nuvem/orquestração que emite operações de ciclo de vida de perfil para um dispositivo ou uma frota
• SM-DP+: Reutilizado do ecossistema de consumidor para preparação de perfil e entrega protegida
• SM-DS: Papel de descoberta mantido onde relevante
• Operador: Fonte do perfil, como no RSP de consumidor

A intenção arquitetônica é consistente em materiais da GSMA e apresentações da indústria: manter o que já funcionava no RSP de consumidor (notavelmente o SM-DP+), e substituir a suposição de humano/LPA por um gerente remoto mais um assistente nativo de IoT (Explicador de padrões Velocity IoT; Comparação 1oT).

Por que o IoT precisava de um modelo diferente #

O RSP de consumidor assume:

• uma tela ou UX de companheiro,
• uma pessoa que pode iniciar o download,
• conectividade IP relativamente estável para sessões TLS,
• decisões de ciclo de vida por dispositivo, orientadas pelo usuário.

Frotas de IoT muitas vezes assumem o contrário:

• sem interface de usuário,
• conectividade intermitente ou de baixa largura de banda (incluindo cenários LPWAN),
• check-ins assíncronos em vez de sessões sempre ativas,
• habilitar/desabilitar/excluir orientado por políticas em muitos EIDs de uma vez.

SGP.31/32, portanto, introduz gerenciamento de estado de perfil orientado para frotas e um eIM que pode acionar ou intermediar downloads. Análises da indústria também enfatizam opções de protocolo leves (por exemplo, CoAP/DTLS como um caminho alternativo para dispositivos com restrições), remoção do SMS como uma dependência rígida para RSP IoT moderno, e suporte para entrega de perfil direta vs. indireta dependendo se o dispositivo pode se comunicar confortavelmente com o SM-DP+ em si (Eseye; 1oT).

Criticamente, SGP.32 não é uma “atualização de software” compatível com versões anteriores para cada eUICC SGP.02 já em campo. A Eseye e outros especialistas em IoT observam que implantações padrão M2M tipicamente permanecem nesse modelo até o fim da vida útil; IoT de campo verde é onde o SGP.32 foi projetado para se tornar o padrão.

SGP.22 vs SGP.32: comparação estruturada #

Comparação dimensão por dimensão #

Par principal GSMA

• SGP.22 (RSP consumidor): arquitetura SGP.21 + técnico SGP.22
• SGP.32 (RSP IoT): arquitetura/requisitos SGP.31 + técnico SGP.32

Projetado para

• SGP.22 (RSP consumidor): Smartphones, tablets, wearables, dispositivos de consumo com interface de usuário
• SGP.32 (RSP IoT): Dispositivos e frotas IoT sem interface / com restrição de interface / com restrição de rede

Humano no loop?

• SGP.22 (RSP consumidor): Sim - usuário inicia ou confirma instalação/troca
• SGP.32 (RSP IoT): Não - eIM/IPA orquestram operações remotamente

Assistente local

• SGP.22 (RSP consumidor): LPA
• SGP.32 (RSP IoT): IPA (IPAd ou IPAe)

Orquestração remota

• SGP.22 (RSP consumidor): Limitado / não é o centro de design
• SGP.32 (IoT RSP): eIM como gestor remoto de primeira classe

Servidor de perfil

• SGP.22 (RSP de consumidor): SM-DP+
• SGP.32 (IoT RSP): SM-DP+ (reutilizado)

Descoberta

• SGP.22 (RSP de consumidor): SM-DS (opcional em muitos fluxos)
• SGP.32 (IoT RSP): SM-DS mantido na arquitetura

Modelo de acionamento

• SGP.22 (RSP de consumidor): Predominantemente pull (QR / código de ativação / app)
• SGP.32 (IoT RSP): Push e/ou pull via eIM e padrões de check-in do dispositivo

Postura de transporte

• SGP.22 (RSP de consumidor): Pilha IP centrada em HTTPS/TLS para consumidores
• SGP.32 (IoT RSP): Baseado em IP; opções para dispositivos restritos enfatizadas (por exemplo, caminhos CoAP/DTLS em resumos da indústria da especificação)

Dor do antecessor que aborda

• SGP.22 (RSP de consumidor): Trocas físicas de SIM e bloqueio de operadora em hardware de consumidor
• SGP.32 (IoT RSP): Bloqueio operacional do SGP.02, dependência de SMS e má adaptação para dispositivos restritos

Relevância do eSIM para viagens

• SGP.22 (RSP de consumidor): Direta - esta é a pilha por trás das instalações típicas de eSIM de viagem em telefones
• SGP.32 (IoT RSP): Indireta - molda ecossistemas adjacentes de IoT/hardware de viagem, não fluxos de QR de telefone

Ciclo de vida do perfil: mesmos verbos, gramática diferente #

Ambos os mundos falam sobre baixar, instalar, habilitar, desabilitar e deletar. A gramática difere:

• Ciclo de vida SGP.22 é local e centrado no usuário. Uma vez instalado, o viajante (ou UI do LPA) decide quando um perfil é habilitado para dados de roaming, quando é pausado e quando é removido.
• Ciclo de vida SGP.32 é remoto e centrado em políticas. O eIM pode emitir operações de gerenciamento de estado de perfil em um EID ou muitos, e o IPA as executa quando o dispositivo está acessível - importante para dispositivos que ficam inativos a maior parte do dia.

É por isso que “troca de perfil” significa coisas comerciais diferentes em cada mundo. No consumo de viagens, a troca é muitas vezes uma nova compra ou um segundo perfil instalado que o usuário seleciona. No IoT, a troca é uma operação de patrimônio: mudar o provedor de conectividade, responder à cobertura ou rotacionar perfis sem uma visita técnica.

Onde as especificações anteriores de IoT se encaixam: SGP.02 e SGP.31 #

Um modelo mental claro:

1. SGP.02 - RSP M2M original com SM-DP + SM-SR. Fundamental, ainda presente em propriedades de ciclo de vida longo (notavelmente automotivo e outras implantações em fábricas), mas cada vez mais tratado como legado para novos projetos de IoT restritos (1oT).
2. SGP.22 - RSP de consumidor que simplificou o provisionamento em torno de SM-DP+ e LPA; o caminho de mercado de massa para telefones e eSIM de viagem.
3. SGP.31 / SGP.32 - RSP de IoT que reutiliza SM-DP+ enquanto adiciona eIM + IPA para gerenciamento de frotas sem intervenção.

SGP.32 não apareceu porque o eSIM de consumidor “falhou.” Ele apareceu porque o eSIM de consumidor teve sucesso para humanos- e esse sucesso ainda não resolve um sensor preso dentro de um contêiner de transporte.

Implicações para eSIM de viagem, roaming de consumidor e pilhas de MVNO #

A conectividade de viagem continua sendo uma história de RSP de consumidor #

Para telefones e a maioria dos dispositivos de viajantes, o padrão operacional continua sendo RSP de consumidor classe SGP.22. A experiência do produto que os viajantes valorizam - comprar antes da partida, instalar via QR ou app, chegar conectado - mapeia para fluxos LPA ↔ SM-DP+, não comandos de frota eIM.

O próprio comentário da GSMA sobre a indústria em 2026 enquadra a conectividade de viagem como uma mudança estrutural no roaming internacional: ofertas de eSIM de viagem baseadas em aplicativos são mais transparentes e flexíveis, e a distribuição se aproxima mais do usuário final antes do início da viagem (GSMA: implantação de mercado de massa de eSIM passa de previsão para fato). Essa mudança comercial se baseia na maturidade do RSP de consumidor e no suporte de dispositivos, não no lançamento de eIM de IoT.

O que SGP.32 *muda* para ecossistemas adjacentes a viagens #

Mesmo que os viajantes nunca toquem no SGP.32, o padrão importa nas margens das viagens:

• Rastreadores de bagagem conectados, veículos de frota, sensores de logística e IoT de locais precisam cada vez mais de gerenciamento remoto de perfis sem uma cerimônia de QR.
• Roteadores de viagem e algum “hardware de eSIM” podem ficar em um meio termo bagunçado: ativação ao estilo de consumidor para um proprietário humano, mas necessidades operacionais que parecem mais com frotas em escala.
• Operadoras e MVNOs podem operar ambos patrimônios de SM-DP+ de consumidor e patrimônios de eIM de IoT. Compartilhar o DNA de SM-DP+ entre SGP.22 e SGP.32 é intencional; isso não significa que as duas classes de dispositivos compartilham a mesma UX ou caminho de certificação.

Multi-IMSI, pilhas de MVNO e limites verdadeiros #

Multi-IMSI (múltiplas identidades selecionáveis dentro ou ao lado de um produto de conectividade) e download de perfil eUICC são frequentemente discutidos juntos, mas não são o mesmo mecanismo. Multi-IMSI pode melhorar o comportamento de conexão de rede dentro de uma oferta comercial; eUICC RSP (SGP.22 ou SGP.32) trata de instalar e gerenciar com segurança perfis completos de operadora no eUICC. Marcas de viagem e MVNOs podem combinar ambas as técnicas comercialmente, mas a clareza da arquitetura ainda importa: instalações de viagem de consumidor em telefones são julgadas pela interoperabilidade SGP.22 e UX de ativação; patrimônios de IoT são julgados pela operabilidade eIM/IPA e resiliência de rede restrita.

Um aviso útil do lado do IoT também se aplica comercialmente: portabilidade técnica em uma especificação não equivale automaticamente a portabilidade comercial em um contrato. SGP.32 reduz certos padrões de bloqueio arquitetônico associados ao SGP.02, mas os termos comerciais do provedor ainda determinam quão livremente as frotas podem mover associações de eIM ou relações externas de SM-DP+ (1oT). Compradores de viagem de consumidor enfrentam uma lição análoga em menor escala - RSP interoperável não garante, por si só, qualidade de cobertura idêntica, política de uso justo ou experiência de suporte entre provedores.

Tempo de mercado e sinais de adoção (público, 2025-2026) #

Materiais públicos da GSMA em 2026 descrevem o eSIM de consumidor entrando em escala operacional em vez de prova de conceito. De acordo com o resumo de maio de 2026 da GSMA sobre os números da GSMA Intelligence, a penetração global de smartphones com eSIM era de cerca de 5% no final de 2025, com um caminho declarado para cerca de 10% até o final de 2026, e crescimento adicional posteriormente; o mesmo artigo cita aproximadamente três em cada quatro / 73% dos operadores de rede móvel oferecendo eSIM comercial para smartphones, enquanto observa a lacuna restante entre disponibilidade e ativação ativa pelo consumidor (artigo de eSIM para o mercado de massa da GSMA).

No lado do IoT, o mesmo comentário da GSMA destaca o SGP.32 como um facilitador estrutural para variantes globais de produtos e troca de perfis em campo - linguagem que corresponde à forma como as plataformas de IoT posicionam o padrão. A maturidade da especificação também é visível nas tabelas públicas da GSMA: SGP.31/SGP.32 continuam a avançar através das listagens ativas v1.2 e mais recentes v1.3 em 2024-2026, juntamente com especificações de teste associadas (índice de especificações da GSMA).

Interpretação sem exageros: o eSIM para viagens de consumidores já é um caso de uso comercial em escala nos trilhos do SGP.22; SGP.32 é a industrialização paralela do IoT RSP. Eles reforçam a história mais ampla do eSIM sem substituir um ao outro.

O que os viajantes e as marcas devem levar em consideração #

Para viajantes #

Você não precisa escolher entre SGP.22 e SGP.32 ao comprar um plano de viagem. Se você está instalando um eSIM em um telefone via código QR ou aplicativo, você está no mundo do RSP do consumidor. O que você deve se preocupar é com o prático: compatibilidade do dispositivo, confiabilidade da instalação antes da partida, cobertura do destino, termos transparentes de uso justo e suporte quando algo falha no portão.

Provedores como Roamify estão nessa camada de viagens de consumidores - planos de destino, instalação digital e utilidade de permanecer online no exterior - em vez de na gestão de frotas industriais de eIM. A história dos padrões por trás do QR ainda é moldada pelo SGP.22.

Para marcas de viagens, OTAs, fintechs e MVNOs de consumidores #

• Trate a interoperabilidade e UX de ativação do SGP.22 como a base do produto.
• Não comercialize “SGP.32” como uma atualização voltada para viajantes, a menos que sua arquitetura real de hardware/frota use IoT RSP.
• Se você vende ou rotula conectividade para rastreadores, roteadores ou hardware de viagem B2B, avalie separadamente se a classe de dispositivo precisa de fluxos de LPA do consumidor, fluxos de eIM de IoT ou um híbrido em etapas.
• Invista em educação: o próprio comentário de mercado da GSMA ainda aponta para uma lacuna entre a disponibilidade de eSIM e a compreensão/ativação do consumidor. Orientação clara de instalação continua sendo um diferencial competitivo.

Para operadores e plataformas de conectividade #

Executar RSP de consumidor e IoT lado a lado está se tornando cada vez mais normal. A herança compartilhada do SM-DP+ ajuda, mas certificação, acreditação de segurança, agentes de dispositivos (LPA vs IPA) e modelos operacionais comerciais permanecem distintos. Misturar os vocabulários na comunicação pública cria falsas expectativas tanto para viajantes quanto para compradores empresariais.

Conclusão: dois padrões, uma narrativa de eSIM - mantenha as faixas claras #

SGP.22 e SGP.32 não são rivais em um único placar. Eles são respostas para duas realidades de dispositivos:

• SGP.22 assume que uma pessoa está presente e pode puxar um perfil para um dispositivo de consumidor. Essa é a arquitetura por trás do moderno eSIM de viagem em telefones.
• SGP.32 assume que o dispositivo está sozinho - ou adormecido - e precisa de gerenciamento remoto, capaz de frota, através de eIM e IPA, enquanto ainda reutiliza a entrega de perfil SM-DP+. Essa é a arquitetura que a GSMA construiu para IoT restrito após os limites do SGP.02 se tornarem óbvios.

Para conectividade de viagem, a lição estratégica é precisão. O caminho do RSP do consumidor já está reformulando como as pessoas compram roaming. O caminho do RSP de IoT está reformulando como as máquinas permanecem conectadas por anos. Marcas que mantêm essas faixas claras explicarão o eSIM de forma mais credível - e construirão produtos que correspondem ao padrão que estão realmente enviando.

Nota de marca suave: Roamify é um provedor de eSIM de viagem que oferece planos em muitos destinos com ativação digital para telefones compatíveis. Este artigo é educação sobre padrões, não uma afirmação de que a Roamify implementa gestão de frotas IoT SGP.32.