SGP.22 vs SGP.32 - lo que el cambio de estándar eSIM significa para la conectividad de viajes

Objetivo: Dar a los compradores de eSIM de viaje y a los operadores de viaje/MVNO un mapa con conocimiento de estándares de la Provisión Remota de SIM de consumidor vs IoT, para que la conversación de la industria sobre “el próximo estándar eSIM” no confunda dos caminos diferentes.

Audiencia: Profesionales que envían o compran conectividad de viaje para el consumidor (y cualquiera que evalúe hardware adyacente de IoT/viaje), no miembros del comité GSMA.

Si compras una eSIM de viaje, escaneas un código QR y aterrizas con datos, ya estás dentro de una arquitectura de Provisión Remota de SIM (RSP) de GSMA, incluso si nunca ves los números de especificación. Esos números importan.SGP.22 es el estándar técnico de RSP de consumidor detrás de los flujos de eSIM de smartphone y de viaje.SGP.32 es el estándar técnico de RSP de IoT para dispositivos sin pantalla, restringidos y a escala de flota. Comparten algunos bloques de construcción. Resuelven diferentes problemas.

Esa distinción es fácil de confundir en presentaciones de marketing. También es la diferencia entre un viajero instalando un perfil temporal en un teléfono y una empresa orquestando la conectividad a través de miles de sensores que nunca verán una pantalla. Para las marcas de viaje, los MVNO y cualquiera que construya sobre pilas de eSIM de consumidor, saber dónde termina SGP.22 y comienza SGP.32 es fundamental, no porque los viajeros necesiten PDFs de GSMA, sino porque la conversación de la industria a menudo mezcla los caminos de consumidor y IoT.

Este artículo mapea la arquitectura, los actores, las diferencias de ciclo de vida y las implicaciones prácticas para la conectividad de viaje, sin tratar a SGP.32 como una actualización directa para el roaming de consumidor.

Por qué la industria necesitaba más de un “estándar” de eSIM #

eSIM no es un único protocolo. Es una familia de especificaciones de GSMA que definen cómo los perfiles de operador se preparan, entregan, instalan, habilitan, deshabilitan y eliminan de manera segura en un eUICC (la plataforma SIM integrada).

El índice de especificaciones públicas de GSMA hace explícita la división: RSP de consumidor se encuentra bajo SGP.21 (arquitectura) y SGP.22 (técnico); RSP de IoT se encuentra bajo SGP.31 (arquitectura y requisitos) y SGP.32 (técnico). Las versiones activas para consumidores continúan a través de SGP.22 v2.x y v3.x; las versiones de IoT continúan a través de SGP.31/SGP.32 v1.x, incluyendo revisiones más recientes de 2024-2026 en la página de especificaciones de eSIM de GSMA (Especificaciones de eSIM para Consumidores e IoT de GSMA).

Antes de SGP.32, la provisión remota de IoT y M2M vivía en gran medida en un modelo anterior de máquina a máquina (SGP.02), con una división de doble servidor de SM-DP (preparación de datos) y SM-SR (enrutamiento seguro). Ese modelo permitió la gestión remota de perfiles para casos de uso industrial y automotriz, pero también trajo fricciones operativas: disparadores orientados a SMS, un acoplamiento comercial más estrecho de SM-SR/SM-DP, y una mala adaptación para dispositivos LPWAN altamente restringidos. Los explicadores de operadores y plataformas IoT citan consistentemente esas limitaciones como la razón por la que GSMA construyó una arquitectura IoT dedicada en lugar de forzar RSP de consumidor en cada módem (Eseye sobre SGP.31/32; 1oT sobre SGP.02 vs SGP.22 vs SGP.32).

Versión corta: una forma física (eSIM/eUICC), múltiples filosofías de provisión.

SGP.22 en términos sencillos: RSP de consumidor para dispositivos con un humano en el proceso #

SGP.22 es la descripción técnica de GSMA de la Provisión Remota de SIM para dispositivos de consumo. Su propósito es inequívoco: una solución técnica para la provisión y gestión remota del eUICC en dispositivos de consumo, dirigida a la interoperabilidad en los despliegues de operadores, incluyendo plataformas SM-DP+ y proveedores de eUICC.

Actores principales en el modelo de consumidor #

Roles de los actores #

• eUICC: Plataforma segura que almacena perfiles (credenciales de operador y componentes relacionados)
• LPA (Asistente de Perfil Local): Asistente en el dispositivo (o parcialmente en eUICC) que impulsa la descarga, habilitación/deshabilitación/eliminación local, y la gestión de perfiles orientada al usuario
• SM-DP+: Gestor de Suscripciones - Preparación de Datos +: prepara, protege y entrega Paquetes de Perfiles Vinculados
• SM-DS: Gestor de Suscripciones - Servicio de Descubrimiento: ruta de descubrimiento opcional cuando el dispositivo necesita encontrar el SM-DP+ correcto sin un código QR/de activación
• Operador / emisor de perfil: Posee la suscripción comercial detrás del perfil

En el flujo que los viajeros reconocen:

1. Compra un plan de viaje y recibe un código de activación (a menudo como un QR).
2. El dispositivo LPA contacta al SM-DP+.
3. El paquete de perfil cifrado se descarga e instala en el eUICC.
4. El usuario habilita el perfil (y luego puede deshabilitarlo o eliminarlo).

Este es un modelo iniciado por el usuario / orientado a la extracción. Una persona está presente, el dispositivo tiene una interfaz de usuario y el consentimiento es una acción de instalación explícita. Por eso, la compra de eSIM de viaje, las asociaciones con aerolíneas/fintech y la activación basada en aplicaciones se corresponden con el RSP de clase SGP.22 para consumidores, no con la orquestación de flotas IoT.

El transporte HTTPS/TLS se adapta a los teléfonos inteligentes. Es más pesado de lo que muchos ciclos de trabajo de IoT pueden permitirse, pero razonable para un dispositivo que ya mantiene conectividad IP y una pila de seguridad completa.

SGP.32 en términos sencillos: RSP IoT para dispositivos que no pueden tocar “Agregar eSIM” #

SGP.32 es la especificación técnica para la arquitectura eSIM IoT de GSMA definida en SGP.31. GSMA lo describe como cubriendo la provisión y gestión remota del eUICC en dispositivos IoT que están limitados por la red y/o por la interfaz de usuario, además de la arquitectura eUICC, interfaces y funciones de seguridad para ese modelo.

Actores principales en el modelo IoT #

Roles de los actores #

• eUICC: eUICC capaz de IoT que almacena perfiles y soporta asociaciones de gestión remota de IoT
• IPA (Asistente de Perfil IoT): Asistente del lado del dispositivo o eUICC que ejecuta el trabajo de provisión/gestión sin una interfaz de usuario para el consumidor; puede ser IPAd (en el dispositivo) o IPAe (en el eUICC)
• eIM (Gestor Remoto de eSIM IoT): Entidad de nube/orquestación que emite operaciones del ciclo de vida del perfil para un dispositivo o una flota
• SM-DP+: Reutilizado del ecosistema de consumidores para la preparación del perfil y entrega protegida
• SM-DS: Rol de descubrimiento retenido donde sea relevante
• Operador: Fuente del perfil, como en el RSP de consumidores

La intención arquitectónica es consistente en los materiales de GSMA y recorridos de la industria: mantener lo que ya funcionaba en el RSP de consumidores (notablemente SM-DP+), y reemplazar la suposición humana/LPA con un gestor remoto más un asistente nativo de IoT (Explicador de estándares IoT de Velocity; comparación de 1oT).

Por qué IoT necesitaba un modelo diferente #

El RSP de consumidores asume:

• una pantalla o UX complementaria,
• una persona que puede iniciar la descarga,
• conectividad IP relativamente estable para sesiones TLS,
• decisiones de ciclo de vida impulsadas por el usuario y por dispositivo.

Las flotas de IoT a menudo asumen lo contrario:

• sin interfaz de usuario,
• conectividad intermitente o de bajo ancho de banda (incluyendo escenarios LPWAN),
• registros asincrónicos en lugar de sesiones siempre activas,
• habilitación/deshabilitación/eliminación impulsada por políticas a través de muchos EIDs a la vez.

Por lo tanto, SGP.31/32 introduce la gestión de estado de perfil orientada a flotas y un eIM que puede activar o intermediar descargas. Los análisis de la industria también enfatizan opciones de protocolo ligeras (por ejemplo, CoAP/DTLS como un camino alternativo para dispositivos restringidos), la eliminación de SMS como una dependencia estricta para el RSP IoT moderno, y el soporte para la entrega de perfiles directa vs. indirecta dependiendo de si el dispositivo puede comunicarse cómodamente con el SM-DP+ por sí mismo (Eseye; 1oT).

Críticamente, SGP.32 no es una “actualización de software” compatible hacia atrás para cada eUICC SGP.02 ya en el campo. Eseye y otros especialistas en IoT señalan que las implementaciones estándar M2M típicamente permanecen en ese modelo hasta el final de su vida útil; el IoT de campo verde es donde SGP.32 está diseñado para convertirse en el estándar por defecto.

SGP.22 vs SGP.32: comparación estructurada #

Comparación por dimensión #

Par principal de GSMA

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

Diseñado para

• SGP.22 (RSP de consumidor): Smartphones, tablets, dispositivos portátiles, dispositivos de consumo con interfaz de usuario
• SGP.32 (RSP IoT): Dispositivos IoT sin interfaz / con restricciones de interfaz / con restricciones de red y flotas

¿Humano en el proceso?

• SGP.22 (RSP de consumidor): Sí - el usuario inicia o confirma la instalación/cambio
• SGP.32 (RSP IoT): No - eIM/IPA orquestan operaciones de forma remota

Asistente local

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

Orquestación remota

• SGP.22 (RSP de consumidor): Limitado / no el centro de diseño
• SGP.32 (IoT RSP): eIM como gestor remoto de primera clase

Servidor de perfiles

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

Descubrimiento

• SGP.22 (RSP de consumidor): SM-DS (opcional en muchos flujos)
• SGP.32 (IoT RSP): SM-DS retenido en la arquitectura

Modelo de activación

• SGP.22 (RSP de consumidor): Predominantemente pull (QR / código de activación / app)
• SGP.32 (IoT RSP): Push y/o pull a través de eIM y patrones de registro del dispositivo

Postura de transporte

• SGP.22 (RSP de consumidor): Pila IP centrada en HTTPS/TLS para consumidores
• SGP.32 (IoT RSP): Basado en IP; se enfatizan opciones para dispositivos con restricciones (por ejemplo, rutas CoAP/DTLS en resúmenes de la industria de la especificación)

Dolor del predecesor que aborda

• SGP.22 (RSP de consumidor): Cambios físicos de SIM y bloqueo del operador en hardware de consumidor
• SGP.32 (IoT RSP): Bloqueo operativo de SGP.02, dependencia de SMS y mala adaptación a dispositivos con restricciones

Relevancia de eSIM para viajes

• SGP.22 (RSP de consumidor): Directa - esta es la pila detrás de las instalaciones típicas de eSIM de viaje en teléfonos
• SGP.32 (IoT RSP): Indirecta - da forma a ecosistemas adyacentes de IoT/hardware de viaje, no a flujos QR de teléfonos

Ciclo de vida del perfil: mismos verbos, diferente gramática #

Ambos mundos hablan de descargar, instalar, habilitar, deshabilitar y eliminar. La gramática difiere:

• Ciclo de vida SGP.22 es local y centrado en el usuario. Una vez instalado, el viajero (o la interfaz de usuario de LPA) decide cuándo un perfil está habilitado para datos en roaming, cuándo se pausa y cuándo se elimina.
• Ciclo de vida SGP.32 es remoto y centrado en políticas. El eIM puede emitir operaciones de gestión de estado de perfil a través de un EID o muchos, y el IPA las ejecuta cuando el dispositivo es accesible - importante para dispositivos que duermen la mayor parte del día.

Por eso, “cambio de perfil” significa cosas comerciales diferentes en cada mundo. En el viaje del consumidor, cambiar a menudo es una nueva compra o un segundo perfil instalado que el usuario selecciona. En IoT, cambiar es una operación de patrimonio: cambiar de proveedor de conectividad, responder a la cobertura o rotar perfiles sin una visita técnica.

Dónde encajan las especificaciones anteriores de IoT: SGP.02 y SGP.31 #

Un modelo mental claro:

1. SGP.02 - RSP M2M original con SM-DP + SM-SR. Fundamental, todavía presente en propiedades de ciclo de vida largo (notablemente en automoción y otros despliegues en fábricas), pero cada vez más tratado como legado para nuevos proyectos de IoT restringidos (1oT).
2. SGP.22 - RSP para consumidores que simplificó la provisión alrededor de SM-DP+ y LPA; el camino masivo para teléfonos y eSIM de viaje.
3. SGP.31 / SGP.32 - RSP para IoT que reutiliza SM-DP+ mientras añade eIM + IPA para la gestión de flotas sin intervención.

SGP.32 no apareció porque la eSIM para consumidores “fracasó”. Apareció porque la eSIM para consumidores tuvo éxito para los humanos-y ese éxito aún no resuelve un sensor atornillado dentro de un contenedor de envío.

Implicaciones para eSIM de viaje, roaming de consumidores y pilas de MVNO #

La conectividad de viaje sigue siendo una historia de RSP para consumidores #

Para teléfonos y la mayoría de dispositivos de viajeros, el estándar operativo sigue siendo RSP para consumidores de clase SGP.22. La experiencia del producto que importa a los viajeros -comprar antes de partir, instalar vía QR o app, llegar conectado- se mapea a los flujos LPA ↔ SM-DP+, no a los comandos de flota eIM.

El propio comentario de la industria de GSMA para 2026 enmarca la conectividad de viaje como un cambio estructural en el roaming internacional: las ofertas de eSIM de viaje basadas en apps son más transparentes y flexibles, y la distribución se acerca más al usuario final antes de que comience el viaje (GSMA: el despliegue masivo de eSIM pasa de previsión a hecho). Ese cambio comercial se basa en la madurez del RSP para consumidores y el soporte de dispositivos, no en el despliegue de eIM para IoT.

Lo que SGP.32 *cambia* para los ecosistemas adyacentes al viaje #

Incluso si los viajeros nunca tocan SGP.32, el estándar importa en los márgenes del viaje:

• Rastreadores de equipaje conectados, vehículos de flota, sensores logísticos y IoT en lugares cada vez más necesitan gestión remota de perfiles sin una ceremonia QR.
• Enrutadores de viaje y algunos “hardware de eSIM” pueden situarse en un punto intermedio desordenado: activación al estilo consumidor para un propietario humano, pero necesidades operativas que parecen más de flota a gran escala.
• Operadores y MVNOs pueden gestionar ambos propiedades de SM-DP+ para consumidores y propiedades de eIM para IoT. Compartir el ADN de SM-DP+ entre SGP.22 y SGP.32 es intencional; no significa que las dos clases de dispositivos compartan la misma UX o camino de certificación.

Multi-IMSI, pilas de MVNO y límites veraces #

Multi-IMSI (múltiples identidades seleccionables dentro o junto a un producto de conectividad) y la descarga de perfiles eUICC a menudo se discuten juntos, pero no son el mismo mecanismo. Multi-IMSI puede mejorar el comportamiento de conexión a la red dentro de una oferta comercial; eUICC RSP (SGP.22 o SGP.32) se trata de instalar y gestionar de manera segura perfiles completos de operadores en el eUICC. Las marcas de viaje y los MVNOs pueden combinar ambas técnicas comercialmente, pero la claridad arquitectónica sigue siendo importante: las instalaciones de viaje para consumidores en teléfonos se juzgan por la interoperabilidad y UX de activación de SGP.22; las propiedades de IoT se juzgan por la operabilidad eIM/IPA y la resiliencia de redes restringidas.

Una advertencia útil del lado de IoT también se aplica comercialmente: la portabilidad técnica en una especificación no equivale automáticamente a portabilidad comercial en un contrato. SGP.32 reduce ciertos patrones de bloqueo arquitectónico asociados con SGP.02, pero los términos comerciales del proveedor aún determinan cuán libremente las flotas pueden mover asociaciones eIM o relaciones externas de SM-DP+ (1oT). Los compradores de viajes para consumidores enfrentan una lección análoga a menor escala: un RSP interoperable no garantiza, por sí solo, una calidad de cobertura idéntica, política de uso justo o experiencia de soporte entre proveedores.

Tiempos de mercado y señales de adopción (público, 2025-2026) #

Los materiales públicos de GSMA en 2026 describen la eSIM para consumidores entrando en escala operativa en lugar de prueba de concepto. Según el resumen de mayo de 2026 de GSMA sobre las cifras de GSMA Intelligence, la penetración global de smartphones con eSIM fue de aproximadamente 5% a finales de 2025, con un camino declarado hacia aproximadamente 10% para finales de 2026, y un mayor crecimiento a partir de entonces; el mismo artículo cita aproximadamente tres de cada cuatro / 73% de los operadores de redes móviles ofreciendo eSIM comercial para smartphones, mientras señala la brecha restante entre la disponibilidad y la activación activa por parte del consumidor (artículo de eSIM para el mercado masivo de GSMA).

En el lado del IoT, el mismo comentario de GSMA destaca SGP.32 como un habilitador estructural para variantes de productos globales y el cambio de perfil en el campo - lenguaje que coincide con cómo las plataformas IoT posicionan el estándar. La madurez de la especificación también es visible en las tablas públicas de GSMA: SGP.31/SGP.32 continúan avanzando a través de listados activos v1.2 y nuevos v1.3 en 2024-2026, junto con especificaciones de prueba asociadas (índice de especificaciones de GSMA).

Interpretación sin exagerar: la eSIM de viaje para consumidores ya es un caso de uso comercial a gran escala en los rieles de SGP.22; SGP.32 es la industrialización paralela del IoT RSP. Refuerzan la historia más amplia de la eSIM sin sustituirse entre sí.

Lo que los viajeros y las marcas deben tener en cuenta #

Para los viajeros #

No necesitas elegir entre SGP.22 y SGP.32 cuando compras un plan de viaje. Si estás instalando una eSIM en un teléfono a través de un código QR o una aplicación, estás en el mundo de RSP para consumidores. Lo que te debe importar es lo práctico: compatibilidad del dispositivo, confiabilidad de la instalación antes de la salida, cobertura del destino, términos de uso justo transparentes y soporte cuando algo falla en la puerta de embarque.

Proveedores como Roamify se sitúan en esa capa de viaje para consumidores - planes de destino, instalación digital y utilidad para mantenerse en línea en el extranjero - en lugar de en la gestión de flotas industriales eIM. La historia de los estándares detrás del QR sigue teniendo forma de SGP.22.

Para marcas de viajes, OTAs, fintechs y MVNOs de consumo #

• Trata la interoperabilidad de SGP.22 y la experiencia de activación UX como la base del producto.
• No comercialices “SGP.32” como una mejora orientada al viajero a menos que tu arquitectura real de hardware/flota use IoT RSP.
• Si vendes o etiquetas en blanco conectividad para rastreadores, enrutadores o hardware de viaje B2B, evalúa por separado si la clase de dispositivo necesita flujos LPA para consumidores, flujos eIM para IoT, o un híbrido escalonado.
• Invierte en educación: el propio comentario de mercado de GSMA aún señala una brecha entre la disponibilidad de eSIM y la comprensión/activación del consumidor. Una guía clara de instalación sigue siendo un diferenciador competitivo.

Para operadores y plataformas de conectividad #

Ejecutar RSP para consumidores y IoT lado a lado es cada vez más normal. La herencia compartida de SM-DP+ ayuda, pero la certificación, la acreditación de seguridad, los agentes de dispositivos (LPA vs IPA) y los modelos operativos comerciales siguen siendo distintos. Mezclar los vocabularios en los mensajes públicos crea falsas expectativas tanto para los viajeros como para los compradores empresariales.

Conclusión: dos estándares, una narrativa de eSIM - mantén los carriles claros #

SGP.22 y SGP.32 no son rivales en un solo tablero de clasificación. Son respuestas a dos realidades de dispositivos:

• SGP.22 asume que una persona está presente y puede cargar un perfil en un dispositivo de consumo. Esa es la arquitectura detrás de la eSIM de viaje moderna en teléfonos.
• SGP.32 asume que el dispositivo está solo - o dormido - y necesita gestión remota, capaz de flotas a través de eIM e IPA, mientras sigue reutilizando la entrega de perfiles SM-DP+. Esa es la arquitectura que GSMA construyó para IoT restringido después de que los límites de SGP.02 se hicieron evidentes.

Para la conectividad de viajes, la lección estratégica es la precisión. El camino de RSP para consumidores ya está remodelando cómo las personas compran roaming. El camino de RSP para IoT está remodelando cómo las máquinas se mantienen conectadas durante años. Las marcas que mantienen esos carriles claros explicarán la eSIM de manera más creíble - y construirán productos que coincidan con el estándar que realmente están enviando.

Nota de marca suave: Roamify es un proveedor de eSIM de viaje que ofrece planes en muchos destinos con activación digital para teléfonos compatibles. Este artículo es educación sobre estándares, no una afirmación de que Roamify implemente la gestión de flotas IoT SGP.32.