Estándar SGP.32: la realidad arquitectónica más allá del hype del sector

El sector del IoT se centra actualmente en una única sigla: SGP.32. Aunque la promesa de una conmutación fluida resulta muy atractiva desde el punto de vista comercial, la realidad técnica es bastante más compleja de lo que parece. En 1NCE somos conscientes de que SGP.32 no es algo que simplemente se compra y se pone en marcha, sino que implica un cambio arquitectónico profundo que hay que implementar. Si bien supone un paso importante hacia un ecosistema de SIM definido por software, el camino hacia una implementación efectiva está lleno de dependencias técnicas que deben alinearse para que todo funcione correctamente.

Las normas anteriores sobre eSIM ya habían resuelto problemas importantes

Para entender por qué SGP.32 está cambiando las reglas del juego, es importante mirar la evolución técnica que lo ha llevado hasta aquí. Antes de su aparición, dos estándares de la GSMA sentaron las bases del aprovisionamiento remoto de SIM:

• SGP.02 (M2M): Este estándar, más tradicional, se basa en un modelo “push”. Es el operador móvil (MNO) quien controla el cambio de perfiles a través de un sistema de gestión de suscripciones (SM-SR). Es una solución robusta, sí, pero también bastante rígida a nivel técnico y, en muchos casos, implica migraciones complejas y costosas entre plataformas de operadores.

• SGP.22 (Consumidores): Es el estándar de eSIM que usamos hoy en smartphones. Funciona con un modelo “pull”, donde el usuario descarga el perfil manualmente, normalmente escaneando un código QR mediante un asistente (LPA). El problema es que depende de la intervención humana, lo que lo hace poco práctico para dispositivos IoT que funcionan de forma autónoma.

Ambos estándares cumplen bien su función en los entornos para los que fueron diseñados. Pero el IoT suele quedarse en medio: dispositivos sin pantalla, sin interfaz de usuario, funcionando durante años sin supervisión y gestionados en grandes volúmenes, no uno a uno. Y justo para ese contexto nace SGP.32:

• El «Pull» está automatizado: ya no hace falta que una persona intervenga. Un componente software del dispositivo (el IPA, IoT Profile Assistant) puede descargar perfiles automáticamente según reglas definidas.

• La gestión se escala a toda la flota: desde la nube, un gestor (eIM, eSIM IoT Remote Manager) puede enviar instrucciones a miles de dispositivos al mismo tiempo para que descarguen nuevos perfiles.

SGP.02 frente a SGP.22 frente a SGP.32 (cambio de perfil) 

Nuevos componentes de la arquitectura SGP.32

La especificación SGP.32 introduce una arquitectura algo diferente para la gestión de perfiles de conectividad. En lugar de depender principalmente de una infraestructura controlada por los operadores, este nuevo enfoque incorpora componentes que permiten a las plataformas de dispositivos y a los sistemas IoT tener un papel mucho más activo.

SGP.32 frente a SGP.22

La norma introduce los siguientes elementos, que cambian bastante la forma en la que se gestiona la conectividad:

• Asistente de perfiles de IoT (IPA): En el mundo de consumo, el LPA es una aplicación que va instalada en el smartphone. En SGP.32, este rol lo asume el IPA, que vive directamente en el dispositivo IoT. Puede implementarse de dos formas: IPAd (en el software del dispositivo) o IPAe (dentro del propio chip eSIM). Su función es actuar como intermediario clave entre la eSIM y el gestor remoto.

• Gestor remoto de eSIM para IoT (eIM): Es, básicamente, el cerebro de todo el sistema. Permite a los fabricantes (OEM) gestionar perfiles de forma remota (activarlos, desactivarlos o eliminarlos) en toda una flota de dispositivos desde una única plataforma en la nube.

SM-DP+: El Subscription Manager Data Preparation+ sustituye a la antigua infraestructura basada en SM-DP y SM-SR, haciendo más eficiente la entrega de perfiles de operador de forma segura y cifrada.

Es importante tener en cuenta que pasar a SGP.32 no es simplemente una actualización de software. En la práctica, implica replantear por completo cómo se comunican el dispositivo y la nube.

Retos para la aplicación de la resolución SGP.32

Ahora mismo hay bastante confusión en el mercado sobre lo que realmente permite hacer SGP.32. Para evitar malentendidos y proteger a nuestros clientes frente a posibles riesgos, es importante dejar claro qué es lo que esta especificación todavía no puede hacer:

1. La dependencia del hardware: Uno de los mitos más comunes es pensar que SGP.32 se puede aplicar a tarjetas SIM ya existentes. Pero no es así. Esta especificación necesita una nueva generación de SIM con eUICC, diseñadas específicamente para soportar los nuevos comandos y los módulos IPA.

2. Integración en el dispositivo: Como el IPA tiene que estar dentro del propio dispositivo, implementar SGP.32 suele implicar cambios en el hardware o en el firmware. Para muchas empresas con dispositivos ya desplegados, esto no es una simple actualización, sino un proyecto técnico bastante importante.

3. Madurez de la cadena de suministro: El ecosistema todavía está evolucionando. Desde la disponibilidad de módulos certificados SGP.32 hasta el soporte por parte de los operadores, hay muchas piezas que aún no están completamente maduras.

4. Complejidad arquitectónica: Con SGP.32, la conectividad deja de ser algo sencillo y pasa a ser un proyecto en sí mismo. Hay que definir quién controla la eSIM, cómo se gestionan los perfiles iniciales y qué pasa cuando un dispositivo necesita cambiar de perfil en condiciones de baja cobertura.

SGP.32 es, sin duda, un avance importante, pero su éxito depende de resolver todos estos aspectos, sobre todo a nivel de hardware e integración, mucho antes de que los dispositivos lleguen al mercado.

¿En qué casos resulta conveniente utilizar SGP.32?

Es importante tener en cuenta que no todos los proyectos IoT son iguales. Hay implementaciones que funcionan perfectamente con modelos de conectividad sencillos, por ejemplo, usando roaming global. Pero hay otros casos donde sí tiene sentido apostar por algo más flexible.

Probablemente no necesite SGP.32 si: sus prioridades son mejorar la cobertura, reducir costes o trabajar con un único SKU para despliegues internacionales. En 1NCE, estos retos ya los resolvemos con nuestra SIM global estándar (GSIM) y con funcionalidades como “Freedom to Switch”, basadas en SGP.02.

Debería considerar el SGP.32 si: está planificando un despliegue internacional a gran escala donde el roaming no es suficiente por temas regulatorios (como ocurre en países como Brasil o Turquía), ya contempla un rediseño del hardware y cuenta con un equipo técnico preparado para abordar un proyecto de integración más complejo y estructurado.

La perspectiva de 1NCE se basa en el pragmatismo por encima de la promoción

En 1NCE lo tenemos claro: apoyamos SGP.32, pero desde un enfoque práctico. Lo vemos como la evolución natural de nuestra capacidad “Freedom to Switch”. Para ciertos clientes, abre la puerta a un futuro donde las SIM están realmente definidas por software. Ahora bien, con los requisitos técnicos actuales, no es algo estándar todavía. Por eso ofrecemos compatibilidad con SGP.32 como un servicio a medida, enfocado a proyectos concretos y acompañado por nuestros arquitectos de soluciones.

La llegada de SGP.32 también refleja algo importante: el sector IoT está madurando. La conectividad ya no es solo un producto que se compra, sino una capa que hay que diseñar e integrar. Por eso, más allá de las promesas de “cambio instantáneo” que se suelen escuchar, merece la pena hacerse algunas preguntas clave: ¿Está su hardware preparado para integrar un IPA? ¿Cuenta con la infraestructura necesaria para gestionar un eIM? ¿Compensa realmente la complejidad añadida frente a una buena solución de roaming global?

SGP.32 es, sin duda, un paso relevante hacia ese futuro más flexible y definido por software. Y en 1NCE estamos aquí para acompañar esa transición con una base técnica sólida y una visión realista. Porque sí, el futuro será software, pero implementarlo bien sigue dependiendo de hacerlo con los pies en la tierra.