La eSIM del smartphone de un viajero y la de un contador eléctrico instalado en una ubicación remota pueden almacenar perfiles descargables de operadores móviles. No necesariamente utilizan la misma arquitectura de aprovisionamiento ni el mismo modelo operativo.
La eSIM de consumo se diseñó para dispositivos con pantalla, sistema operativo, acceso a Internet y personas disponibles para aprobar la instalación. Los despliegues IoT pueden incluir miles de dispositivos desatendidos, con energía limitada, conectividad intermitente, sin cámara y sin una forma práctica de escanear un código QR.
Por ello, la GSMA ha desarrollado distintas arquitecturas de aprovisionamiento remoto de SIM para diferentes entornos:
- SGP.01 y SGP.02 definen la arquitectura M2M consolidada;
- SGP.21 y SGP.22 definen la arquitectura de consumo utilizada ampliamente por smartphones y otros dispositivos de consumo;
- SGP.31 y SGP.32 definen la arquitectura IoT más reciente para dispositivos con restricciones de red o de interfaz de usuario;
- SGP.41 define la arquitectura y los requisitos del aprovisionamiento de perfiles en fábrica, o IFPP.
Los números importan, pero no deben ser el punto de partida de una decisión comercial. La arquitectura correcta depende del dispositivo, del modelo de despliegue, de la conectividad disponible, de la participación del usuario, de la vida útil prevista y de quién gestiona los perfiles.
Ideas clave
- Las arquitecturas eSIM de consumo, M2M e IoT resuelven problemas operativos diferentes. No son simplemente nombres distintos para el mismo flujo.
- SGP.21 describe la arquitectura y los requisitos de la eSIM de consumo. SGP.22 proporciona la especificación técnica correspondiente.
- SGP.31 describe la arquitectura y los requisitos de la eSIM IoT más reciente. SGP.32 proporciona su especificación de implementación técnica.
- La eSIM de consumo suele utilizar un SM-DP+, un Local Profile Assistant y, opcionalmente, un SM-DS. El usuario o el dispositivo normalmente participa directamente en la descarga del perfil.
- La arquitectura IoT SGP.31/32 incorpora un IoT Profile Assistant y un eSIM IoT Remote Manager para admitir dispositivos sin una interfaz local adecuada y con conectividad limitada.
- La arquitectura IoT puede utilizar infraestructura SM-DP+, pero eso no significa que cualquier servicio eSIM de consumo sea automáticamente adecuado para flotas SGP.32.
- La arquitectura M2M consolidada utiliza componentes como SM-DP y SM-SR y está muy dirigida desde los servidores. Sigue siendo relevante en despliegues existentes de automoción e industria.
- SGP.32 no actualiza de forma remota todos los dispositivos M2M o de consumo desplegados. La compatibilidad debe existir en la eUICC, el software del dispositivo, la vía de conectividad y los sistemas de gestión.
- Una flota puede necesitar varias arquitecturas durante un periodo prolongado de migración.
- Una buena plataforma comercial separa el aprovisionamiento de perfiles, la conectividad de red y la gestión del ciclo de vida de la flota, en lugar de tratarlos como una única función llamada «eSIM».
¿Por qué necesita la eSIM más de una arquitectura?
El aprovisionamiento remoto de SIM debe adaptarse a las condiciones reales del dispositivo objetivo.
Un smartphone normalmente dispone de:
- una pantalla y un menú de ajustes;
- un usuario que puede dar su consentimiento;
- Wi-Fi u otra conexión a Internet;
- un sistema operativo con interfaz eSIM;
- energía y capacidad de procesamiento suficientes para una instalación interactiva;
- una cámara, aplicación o gestor de enlaces.
Un sensor conectado puede no tener ninguna de estas características. Puede estar bajo tierra, dentro de una máquina sellada o distribuido entre varios países. Puede activarse solo periódicamente, comunicarse mediante una tecnología radio limitada y tener que funcionar diez años sin intervención manual.
Un fabricante de automóviles tiene otras necesidades. Los vehículos pueden fabricarse en un país, enviarse a todo el mundo, asignarse a distintos proveedores de servicios y tener que admitir llamadas de emergencia, diagnóstico y servicios conectados durante un largo ciclo de vida.
Una sola arquitectura no puede optimizar por igual todas estas condiciones.
Las especificaciones GSMA de un vistazo
| Arquitectura | Principales documentos GSMA | Entorno habitual | Componentes principales de gestión | Modelo operativo general |
|---|---|---|---|---|
| eSIM M2M | SGP.01 y SGP.02 | Automoción, industria y flotas M2M gestionadas consolidadas | SM-DP, SM-SR y eUICC M2M | Gestión remota dirigida desde servidores |
| eSIM de consumo | SGP.21 y SGP.22 | Smartphones, tabletas, wearables y dispositivos manejados por usuarios | SM-DP+, LPA y SM-DS opcional | El usuario o dispositivo inicia la adquisición del perfil |
| eSIM IoT | SGP.31 y SGP.32 | Dispositivos IoT con restricciones de red o interfaz | SM-DP+, IPA y eIM | Gestión remota de flotas adaptada a dispositivos limitados |
| Aprovisionamiento de perfiles en fábrica | Arquitectura y requisitos SGP.41 | Fabricación de dispositivos y personalización en fábrica | Componentes del ecosistema de fábrica y aprovisionamiento | Aprovisionamiento del perfil durante la fabricación |
La tabla está simplificada deliberadamente. Cada especificación contiene funciones, interfaces, procedimientos de seguridad y operaciones del ciclo de vida detallados. Las empresas deben confirmar la versión e implementación aplicables con sus proveedores de eUICC, dispositivos, conectividad y plataforma.
¿Qué significan los números de los documentos GSMA?
Los estándares eSIM de la GSMA se dividen en documentos relacionados.
Documentos de arquitectura y requisitos
Describen funciones, casos de uso, principios y requisitos de una arquitectura.
- SGP.01 cubre la arquitectura y los requisitos M2M.
- SGP.21 cubre la arquitectura y los requisitos de consumo.
- SGP.31 cubre la arquitectura y los requisitos IoT.
- SGP.41 cubre la arquitectura y los requisitos del aprovisionamiento de perfiles en fábrica.
Especificaciones técnicas
Definen los procedimientos técnicos detallados, interfaces, mensajes y funciones de seguridad necesarios para implementaciones interoperables.
- SGP.02 es la especificación técnica de la arquitectura M2M.
- SGP.22 es la especificación técnica del aprovisionamiento remoto de SIM de consumo.
- SGP.32 es la especificación técnica de la arquitectura eSIM IoT.
Las expresiones «eSIM SGP.22» o «eSIM SGP.32» son prácticas, pero ninguno de esos números describe un formato físico de SIM distinto. Los documentos describen arquitecturas de aprovisionamiento remoto y comportamientos técnicos en torno a una eUICC y un ecosistema de perfiles compatibles.
Cómo funciona la arquitectura eSIM de consumo
La arquitectura de consumo es el modelo más familiar para los usuarios de smartphones. El cliente compra un plan y lo añade mediante los ajustes, un código QR, una aplicación del operador, una notificación, un enlace de activación o un proceso de transferencia admitido por el sistema operativo.
SGP.21 define la arquitectura y los requisitos. SGP.22 proporciona la especificación técnica.
Principales componentes de consumo
eUICC
La eUICC es el componente protegido que almacena y gestiona perfiles de operador. Puede almacenar varios perfiles, aunque el diseño del dispositivo determina cuántos pueden habilitarse simultáneamente.
Perfil eSIM
El perfil contiene la suscripción del operador y las credenciales protegidas necesarias para la autenticación en la red y la configuración del servicio.
SM-DP+
El Subscription Manager Data Preparation Plus prepara, protege y entrega perfiles a los dispositivos de consumo elegibles.
Local Profile Assistant
El Local Profile Assistant, o LPA, funciona del lado del dispositivo. Permite descargar y gestionar perfiles y media entre el SM-DP+ y la eUICC.
En un smartphone, el LPA normalmente está integrado en los ajustes móviles y las funciones eSIM seguras del sistema operativo. El usuario puede ver una aplicación o tienda de una marca, pero las operaciones protegidas de perfil siguen controladas por la plataforma del dispositivo.
SM-DS
El Subscription Manager Discovery Service opcional puede ayudar al dispositivo a descubrir que hay un perfil disponible. Permite recorridos que no dependen exclusivamente de introducir manualmente una dirección SM-DP+ o escanear un código QR convencional.
Un flujo típico de aprovisionamiento de consumo
- El cliente compra o solicita un plan móvil.
- El operador o proveedor prepara o asigna un perfil mediante el SM-DP+.
- El dispositivo recibe información de activación o descubre el perfil disponible.
- El usuario aprueba la instalación cuando es necesario.
- El LPA establece la interacción requerida con el SM-DP+.
- El perfil se descarga e instala de forma segura en la eUICC.
- El usuario o sistema habilita el perfil.
- El módem lo utiliza para registrarse en una red permitida.
La arquitectura de consumo funciona bien cuando un usuario puede responder a los avisos, confirmar el consentimiento, seleccionar la línea adecuada y proporcionar Internet para descargar el perfil.
Dónde encaja mejor la eSIM de consumo
- eSIM de viaje para smartphones;
- suscripciones móviles principales;
- tabletas y portátiles con una interfaz eSIM adecuada;
- relojes inteligentes vinculados a una cuenta de consumo;
- aplicaciones en las que el propietario elige activamente al proveedor;
- equipos de menor volumen con interfaz accesible y gestión individual posible.
Ventajas de la arquitectura de consumo
- compatibilidad consolidada en numerosos smartphones y sistemas operativos;
- recorridos conocidos de códigos QR y activación digital;
- elección y consentimiento del cliente integrados en el modelo operativo;
- ecosistema SM-DP+ común;
- distribución minorista directa y mediante aplicaciones;
- almacenamiento de varias suscripciones en dispositivos compatibles.
Limitaciones para flotas IoT
El modelo de consumo puede resultar difícil cuando los dispositivos están desatendidos o no tienen una interfaz de usuario adecuada.
El operador de una flota puede no ser capaz de:
- escanear un código QR por dispositivo;
- aprobar un aviso en cada pantalla;
- mantener todos los dispositivos conectados durante el aprovisionamiento;
- recuperar físicamente un dispositivo tras una descarga fallida;
- depender de la interfaz de un sistema operativo de consumo;
- coordinar manualmente miles de cambios de perfil.
Esto no significa que la arquitectura de consumo nunca pueda usarse en un dispositivo similar a IoT. Un router con pantalla, interfaz web y una flota de tamaño manejable puede utilizarla. La prueba operativa importa más que la etiqueta del producto.
Cómo funciona la arquitectura eSIM M2M consolidada
La arquitectura M2M se diseñó para dispositivos gestionados a distancia, especialmente en automoción e industria. Sus principales documentos GSMA son SGP.01 y SGP.02.
A diferencia del modelo de consumo, no presupone que un usuario final vaya a elegir un plan e interactuar con un LPA en el dispositivo.
Principales componentes M2M
SM-DP
La función Subscription Manager Data Preparation prepara y protege los perfiles de operador para su entrega.
SM-SR
La función Subscription Manager Secure Routing gestiona la comunicación segura con la eUICC y permite operaciones remotas del ciclo de vida del perfil.
eUICC M2M
La eUICC admite los procedimientos M2M de aprovisionamiento remoto pertinentes y recibe órdenes mediante esta arquitectura.
Modelo operativo general M2M
La arquitectura está muy dirigida desde los servidores. Los sistemas de gestión inician la descarga, habilitación, deshabilitación y eliminación de perfiles sin depender de un consumidor situado junto al dispositivo.
Esto encaja con equipos instalados en ubicaciones remotas y controlados mediante acuerdos empresariales. Ha sustentado importantes despliegues de vehículos conectados e industriales durante muchos años.
Ventajas de la arquitectura M2M
- diseñada para dispositivos controlados de forma centralizada;
- no requiere interfaz de usuario de consumo;
- consolidada en programas de automoción e industria de larga duración;
- admite gestión remota del ciclo de vida;
- encaja en cadenas de suministro empresariales con gobernanza estricta.
Retos operativos
El SM-SR desempeña un papel central en el modelo M2M. Las relaciones comerciales y técnicas alrededor de ese componente pueden complicar los cambios entre proveedores más de lo previsto inicialmente por los compradores.
Los retos pueden incluir:
- complejidad de integración entre varias partes;
- programas prolongados de incorporación y certificación;
- dependencia de la cadena de gestión de suscripciones seleccionada;
- acuerdos complejos de propiedad y migración;
- adecuación limitada a despliegues pequeños o más flexibles;
- fricciones comerciales al cambiar de proveedor de conectividad.
La arquitectura M2M consolidada sigue siendo válida para los despliegues diseñados para ella. No obstante, un nuevo proyecto IoT debe compararla con SGP.31/32 en lugar de suponer que «eSIM M2M» es la única opción gestionada a distancia.
Cómo funciona la arquitectura IoT SGP.31/32
La GSMA desarrolló la arquitectura IoT más reciente para eUICC en dispositivos IoT con restricciones de red y/o de interfaz de usuario.
SGP.31 define la arquitectura y los requisitos. SGP.32 proporciona la descripción técnica del aprovisionamiento y la gestión remotos, la arquitectura eUICC, las interfaces y las funciones de seguridad.
El diseño combina principios útiles de arquitecturas anteriores:
- gestión remota adecuada para flotas;
- posibilidad de utilizar infraestructura SM-DP+ del ecosistema de consumo;
- funciones del lado del dispositivo adaptadas a equipos IoT limitados;
- gestión sin necesidad de que una persona maneje una pantalla local.
Principales componentes IoT
SM-DP+
La arquitectura IoT utiliza un SM-DP+ para preparar y entregar perfiles. Esto puede reducir la necesidad de un ecosistema de preparación de perfiles completamente separado.
No significa que cualquier integración SM-DP+ proporcione automáticamente un servicio SGP.32 completo. El dispositivo IoT, la eUICC, las funciones de gestión, las interfaces y los procedimientos de seguridad deben admitir la arquitectura correspondiente.
IoT Profile Assistant
El IoT Profile Assistant, o IPA, proporciona asistencia del lado del dispositivo para las operaciones de perfil en la arquitectura IoT.
La función puede implementarse en distintos lugares:
- IPAd, cuando el IPA se implementa en el dispositivo IoT;
- IPAe, cuando el IPA se implementa en la eUICC.
La opción adecuada depende de los recursos del dispositivo, el control del software, la implementación de la eUICC y el diseño del despliegue.
eSIM IoT Remote Manager
El eSIM IoT Remote Manager, o eIM, permite interacciones de gestión remota con dispositivos IoT y sus IPA.
El eIM permite que un proceso autorizado de gestión de flotas active y coordine operaciones del ciclo de vida de los perfiles sin exigir que un usuario escanee un QR en cada dispositivo. Sus paquetes firmados pueden admitir desencadenantes de descarga, operaciones de gestión del estado del perfil, operaciones de configuración del eIM, solicitudes de datos del IPA o la eUICC y acuses de recibo.
El eIM no debe confundirse con un SM-DP+. El eIM ayuda a la orquestación y gestión remotas, mientras que el SM-DP+ prepara y entrega perfiles.
El eIM es central para las operaciones de flota orquestadas a distancia, pero no toda descarga SGP.32 debe comenzar con una instrucción del eIM. La especificación también admite procedimientos iniciados por el IPA, incluido el uso de información SM-DP+ configurada y mecanismos de descubrimiento cuando estén implementados.
eUICC IoT
La eUICC debe admitir la arquitectura IoT y los procedimientos técnicos aplicables. Un dispositivo con un elemento seguro integrado no es automáticamente compatible con SGP.32.
Un flujo SGP.32 simplificado gestionado a distancia
- Un proceso empresarial o de servicio IoT identifica un dispositivo que necesita una operación de perfil.
- El entorno de gestión autorizado utiliza un eIM para comunicar la acción requerida.
- El IPA del dispositivo participa en el procedimiento.
- El perfil se obtiene de un SM-DP+ mediante un procedimiento admitido de descarga directa o indirecta.
- El perfil se instala y gestiona en la eUICC IoT.
- El dispositivo utiliza el perfil seleccionado para conectarse bajo las políticas de red y servicio aplicables.
En una descarga directa, el IPA se comunica con el SM-DP+. En una descarga indirecta, el eIM participa en la obtención y transferencia del paquete de perfil protegido mediante las interfaces definidas. SGP.32 también incluye mecanismos de descubrimiento, reversión de perfil, perfil de respaldo y gestión de errores.
La secuencia exacta depende del caso de uso, la conectividad disponible, la implementación del IPA y la configuración técnica. El valor empresarial consiste en gestionar la operación a escala de flota sin una interfaz de consumo en cada dispositivo.
¿Qué significa «dispositivo IoT con restricciones»?
Las restricciones pueden ir más allá del tamaño físico.
Restricción de interfaz de usuario
El dispositivo puede tener:
- ausencia de pantalla;
- ausencia de teclado o pantalla táctil;
- ausencia de cámara para códigos QR;
- ausencia de operador local;
- una carcasa sellada o inaccesible.
Restricción de red
El dispositivo puede tener:
- conectividad intermitente;
- ancho de banda limitado;
- latencia elevada;
- protocolos restringidos;
- largos intervalos de suspensión;
- conectividad de área extensa y bajo consumo;
- cobertura solo en determinados momentos de su ciclo operativo.
Restricción de recursos
El dispositivo también puede tener limitaciones de:
- capacidad de procesamiento;
- memoria;
- presupuesto energético;
- complejidad de las aplicaciones;
- oportunidades de actualización del firmware.
No todos los dispositivos limitados tienen todas estas características. La arquitectura debe evaluarse frente al hardware y las condiciones operativas reales.
SGP.22 de consumo frente a SGP.32 IoT
| Área de decisión | Arquitectura de consumo SGP.21/22 | Arquitectura IoT SGP.31/32 |
|---|---|---|
| Objetivo principal | Dispositivos de consumo manejados por usuarios | Dispositivos IoT con restricciones de interfaz o red |
| Iniciador habitual | Usuario, dispositivo o flujo de consumo admitido por el operador | Proceso autorizado de gestión remota de flotas |
| Componente del dispositivo | LPA | IPA, implementado como IPAd o IPAe |
| Componente de gestión remota | SM-DP+ y SM-DS opcional | SM-DP+ y eIM que interactúa con el IPA |
| Consentimiento del usuario | Habitual y a menudo visible | Puede sustituirse por control empresarial autorizado y adecuado al dispositivo |
| Código QR | Método de entrega habitual | No es necesario como mecanismo normal de flota |
| Modelo de escala | Suscripciones y dispositivos individuales | Grandes flotas gestionadas y operaciones automatizadas |
| Supuestos de conectividad | Normalmente acceso interactivo a Internet durante la instalación | Diseñada para condiciones IoT limitadas o intermitentes |
| Dependencia del sistema operativo | A menudo estrechamente ligada a funciones de sistemas de consumo | Diseñada para implementaciones especializadas de dispositivos IoT |
| Ejemplos habituales | Teléfonos, tabletas, relojes, portátiles | Localizadores, contadores, sensores, terminales y dispositivos industriales |
La tabla no resuelve todos los casos particulares. Algunos routers se comportan como dispositivos de consumo. Algunos equipos industriales tienen sistemas operativos potentes e interfaces locales. Algunos wearables se gestionan mediante un teléfono vinculado, no directamente.
La selección de arquitectura debe seguir el ciclo de vida real, no una categoría de marketing.
SGP.32 frente a la arquitectura M2M consolidada
SGP.32 suele describirse como sucesora del modelo M2M anterior. Esa descripción orienta, pero puede resultar engañosa operativamente.
Los despliegues M2M existentes no desaparecerán de inmediato. Vehículos, contadores y dispositivos industriales pueden seguir activos diez años o más. Sus eUICC y software se diseñaron para SGP.01/02 y no necesariamente pueden convertirse a distancia a otra arquitectura.
Diferencias principales
| Área | M2M SGP.01/02 | IoT SGP.31/32 |
|---|---|---|
| Componentes centrales de suscripción | SM-DP y SM-SR | SM-DP+, eIM e IPA |
| Enfoque de gestión | Dirigido por servidores mediante la cadena M2M consolidada | Gestión remota orientada a flotas con arquitectura IoT |
| Ecosistema de preparación de perfiles | SM-DP específico de M2M | Basado en SM-DP+ |
| Asistente del dispositivo | La arquitectura no utiliza el modelo LPA de consumo | IPA en el dispositivo o la eUICC |
| Consideraciones de cambio de proveedor | Puede implicar relaciones SM-SR complejas | Diseñada para un ecosistema IoT más flexible, según la implementación |
| Base instalada | Importantes despliegues consolidados | Base de implementaciones más reciente y creciente |
Qué puede mejorar SGP.32
Para nuevos despliegues adecuados, la arquitectura puede ofrecer:
- una vía más escalable para equipos IoT limitados;
- menor dependencia de la interacción del consumidor;
- uso del ecosistema SM-DP+ más amplio;
- orquestación a escala de flota mediante funciones eIM;
- más flexibilidad al diseñar cadenas de suministro de conectividad;
- mejor alineación entre fabricantes, proveedores de servicios IoT y proveedores de conectividad.
Son oportunidades arquitectónicas, no resultados comerciales garantizados. El diseño contractual, la calidad de implementación, la interoperabilidad y los derechos de salida siguen siendo críticos.
¿Qué es el aprovisionamiento de perfiles en fábrica?
Algunos dispositivos necesitan un perfil adecuado durante la fabricación, las pruebas o la distribución inicial. SGP.41 de la GSMA define la arquitectura y los requisitos del aprovisionamiento de perfiles en fábrica, o IFPP.
IFPP aborda una etapa distinta de la gestión normal de perfiles en campo. Puede ayudar a los fabricantes a aprovisionar conectividad durante la producción, en lugar de insertar una SIM personalizada por separado o exigir que el dispositivo terminado realice su primera descarga de perfil solo después del despliegue.
Los beneficios potenciales incluyen:
- simplificación de variantes de fabricación;
- asignación automática de perfiles durante la producción;
- pruebas de conectividad más tempranas;
- menor manipulación de SIM físicas;
- soporte para dispositivos que necesitan conectividad inmediatamente al encenderse.
El aprovisionamiento en fábrica no debe considerarse una estrategia completa para toda la vida útil. El dispositivo puede seguir necesitando gestión remota de perfiles y conectividad después de salir de fábrica.
Elegir una arquitectura según el caso de uso
eSIM de viaje para smartphones
Elección probable: arquitectura de consumo.
El cliente tiene un teléfono compatible, puede aprobar la instalación y utilizar un QR, enlace de activación o aplicación. Las prioridades comerciales son entrega inmediata, instrucciones claras, cobertura, precios y asistencia.
Smartphones de empleados gestionados por una empresa
Elección probable: arquitectura de consumo combinada con gestión empresarial de dispositivos y procesos del operador.
Los teléfonos siguen siendo dispositivos de consumo aunque una empresa los compre y administre. Los controles empresariales no los convierten automáticamente en dispositivos IoT SGP.32.
Routers gestionados
Elección posible: arquitectura de consumo o IoT, según el router.
Un router con interfaz web y proceso de instalación accesible puede utilizar eSIM de consumo. Una gran flota desatendida puede beneficiarse de una arquitectura IoT. Los compradores deben comprobar la compatibilidad exacta del módem, eUICC, firmware y gestión, en lugar de aceptar «preparado para eSIM» como suficiente.
Telemática de vehículos
Elección posible: M2M consolidado para programas existentes, SGP.32 para nuevos diseños adecuados.
Los programas de automoción tienen ciclos de vida largos, requisitos de seguridad y cadenas de proveedores complejas. Migrar exige planificar cuidadosamente hardware y plataforma.
Contadores inteligentes y sensores ambientales
Elección probable para nuevos diseños con restricciones: arquitectura IoT.
Estos dispositivos pueden carecer de pantallas, funcionar con energía limitada y permanecer desplegados durante años. La gestión remota de flotas resulta más adecuada que instalar individualmente mediante códigos QR.
Terminales de pago y quioscos
Elección posible: arquitectura de consumo o IoT.
La decisión depende de si el terminal puede ofrecer una interfaz local controlada, de la disponibilidad de personal en campo y del número de dispositivos que necesitan cambios de perfil coordinados.
Equipos conectados desde fábrica
Elección posible: IFPP para el aprovisionamiento inicial combinado con gestión del ciclo de vida M2M o IoT.
El proceso de fábrica puede establecer la conectividad inicial, mientras que la arquitectura desplegada gobierna los cambios posteriores.
Preguntas antes de seleccionar SGP.22 o SGP.32
- ¿Tiene el dispositivo una interfaz local utilizable?
- ¿Habrá una persona presente durante el aprovisionamiento inicial?
- ¿Puede el dispositivo escanear, abrir o recibir información de activación de consumo?
- ¿Hay acceso fiable a Internet antes de instalar el nuevo perfil?
- ¿Cuántos dispositivos hay que gestionar?
- ¿Los cambios de perfil serán individuales o para toda la flota?
- ¿Cuánto tiempo permanecerán en servicio los dispositivos?
- ¿Pueden el firmware y la eUICC admitir la arquitectura requerida?
- ¿Se implementa el IPA en el dispositivo o en la eUICC?
- ¿Quién operará o suministrará el eIM?
- ¿Qué plataformas SM-DP+ y proveedores de perfiles son compatibles?
- ¿Qué conectividad inicial o de respaldo está disponible?
- ¿Qué ocurre si se interrumpe la descarga de un perfil?
- ¿Puede recuperarse el dispositivo sin acceso físico?
- ¿Qué parte está autorizada a solicitar y aprobar cambios de perfil?
- ¿Cómo migrará la flota a otro proveedor de conectividad?
- ¿Qué certificados, procesos de conformidad y controles de producción se aplican?
- ¿Qué eventos del ciclo de vida puede observar realmente la plataforma de gestión?
Por qué importa la conectividad inicial
La descarga remota de perfiles necesita una vía de comunicación. Un nuevo perfil no puede ayudar al dispositivo a contactar con el servicio de aprovisionamiento hasta que se haya descargado.
Por tanto, un diseño IoT necesita una estrategia de conectividad inicial. Según la implementación, puede implicar:
- un perfil inicial o bootstrap;
- conectividad de fábrica o local;
- acceso Wi-Fi o por cable;
- otro perfil activo;
- una red controlada de puesta en servicio;
- conectividad proporcionada durante el proceso de despliegue.
La solución inicial debe evaluarse por cobertura, coste, duración y dependencia del proveedor. Un perfil que caduque demasiado pronto o solo funcione en el país de fabricación puede impedir el aprovisionamiento posterior.
La resiliencia también importa. Si el perfil objetivo no se descarga o no conecta, el dispositivo puede necesitar mantener una vía de respaldo operativa para intentar otra operación.
La compatibilidad exige más que un logotipo eSIM
Un dispositivo «compatible con eSIM» puede admitir solo una arquitectura o flujo concreto.
Para un despliegue fiable, verifique:
- compatibilidad del hardware eUICC y del sistema operativo;
- arquitectura GSMA y versión de especificación admitidas;
- implementación del LPA o IPA;
- compatibilidad eIM cuando sea necesaria;
- interoperabilidad SM-DP+;
- compatibilidad de módem y bandas radio;
- comportamiento de conectividad inicial y respaldo;
- capacidad de actualización remota del firmware;
- límites de almacenamiento y habilitación de perfiles;
- recuperación tras interrupciones de alimentación o red;
- pruebas de conformidad y certificación.
Un router eSIM de consumo que acepta un QR no es automáticamente un router SGP.32. Una eUICC integrada no puede gestionarse automáticamente mediante cualquier servicio de aprovisionamiento remoto.
Requisitos operativos de una plataforma eSIM IoT
La descarga de perfiles es solo una parte de la gestión de flotas IoT.
Una plataforma práctica puede necesitar proporcionar:
- inventario de dispositivos y eUICC;
- correspondencia entre dispositivo, EID, perfil, ICCID y activo del cliente;
- operaciones masivas con controles de aprobación;
- programación y despliegues por fases;
- estados, reintentos y clasificación de fallos;
- políticas de conectividad y visibilidad de red;
- supervisión del consumo y alertas;
- suspensión y reactivación;
- historial de auditoría;
- roles de acceso para organizaciones cliente;
- integración API y webhooks;
- gestión de conectividad inicial y respaldo;
- procedimientos seguros de transición y salida entre proveedores.
El sistema debe distinguir el estado del perfil del estado de la red. «Perfil habilitado» no demuestra que un sensor se haya conectado a una red, alcanzado su endpoint de aplicación o entregado datos utilizables.
Cuestiones comerciales y contractuales
Las decisiones de arquitectura crean dependencias comerciales a largo plazo.
Los contratos deben aclarar:
- propiedad de eUICC, perfiles e identificadores;
- control del eIM, SM-DP+, SM-SR o cuentas de gestión relacionadas;
- derechos para trasladar perfiles o dispositivos a otro proveedor;
- responsabilidad de la conectividad inicial;
- niveles de servicio de las operaciones de aprovisionamiento;
- soporte de las versiones de especificación desplegadas;
- renovación de certificados y responsabilidades del ciclo de vida;
- acceso y conservación de datos;
- escalado de incidentes;
- costes de descargas, cambios, habilitación, almacenamiento y uso de API;
- tratamiento de los dispositivos tras terminar el contrato.
El precio más bajo por megabyte puede resultar irrelevante si la flota no puede cambiar de proveedor o recuperarse de una transición de perfil fallida.
Migración y coexistencia
Las grandes organizaciones deben prever la coexistencia de arquitecturas.
Una empresa puede operar simultáneamente:
- dispositivos antiguos de automoción con SGP.01/02;
- smartphones con SGP.21/22;
- nuevos sensores diseñados para SGP.31/32;
- dispositivos aprovisionados en fábrica que entran en servicio mediante IFPP.
Sustituir todos los dispositivos de una vez rara vez es rentable. Por ello, la capa de gestión debe mantener un inventario claro de arquitectura, capacidades eUICC, proveedor de perfiles y operaciones de ciclo de vida disponibles para cada grupo de dispositivos.
Un enfoque razonable de migración
- Segmentar la base instalada por dispositivo, módem, eUICC y arquitectura.
- Identificar qué dispositivos admiten un nuevo método de aprovisionamiento y cuáles necesitan sustitución.
- Definir los requisitos de futuros dispositivos nombrando explícitamente la arquitectura GSMA objetivo.
- Probar la interoperabilidad con la combinación real de eUICC, IPA, eIM y SM-DP+.
- Validar escenarios de conectividad inicial, reversión y pérdida de conectividad.
- Realizar un piloto controlado en países y redes representativos.
- Migrar por fases con criterios de éxito medibles.
- Mantener una vía operativa para dispositivos antiguos durante toda su vida útil restante.
Una migración de arquitectura nunca debe empezar con un cambio masivo de perfiles sin una vía de recuperación probada.
Ideas equivocadas habituales
«Todas las eSIM funcionan con SGP.22 y SGP.32»
No. La compatibilidad depende de la eUICC, el software del dispositivo, los componentes de aprovisionamiento y la arquitectura admitida.
«SGP.32 es simplemente eSIM de consumo sin pantalla»
No. Introduce un modelo de gestión específico para IoT con IPA y eIM para dispositivos limitados y operaciones de flota.
«SGP.32 sustituye inmediatamente a todas las eSIM M2M»
No. Los dispositivos M2M existentes pueden seguir operativos muchos años y quizá no puedan actualizarse a la nueva arquitectura.
«Utilizar un SM-DP+ significa que toda la solución admite SGP.32»
No. El SM-DP+ es una parte de la arquitectura. El dispositivo, la eUICC, el IPA, el eIM y las interfaces también deben admitir los procedimientos requeridos.
«La eSIM IoT proporciona automáticamente cobertura multirred»
No. El aprovisionamiento remoto cambia la gestión de perfiles. El acceso a la red sigue dependiendo del perfil comercial, del operador y de los acuerdos de itinerancia.
«Una flota siempre puede cambiar de proveedor a distancia»
Solo si el diseño técnico y contractual completo lo permite. Importan la conectividad inicial, la autorización, el control de la gestión, los perfiles compatibles y los procedimientos de recuperación.
«Todos los routers deberían utilizar SGP.32»
No necesariamente. Un router gestionado por su usuario puede funcionar bien con arquitectura de consumo. La elección depende de la escala de la flota, la accesibilidad y el ciclo de vida.
Cómo encaja SIM24.biz en la decisión de arquitectura
SIM24.biz ayuda a las empresas a crear ofertas de conectividad de consumo, SIM física e IoT con su propia marca.
El punto de partida comercial debe ser el producto y el ciclo de vida del dispositivo, no un número de especificación elegido de forma aislada. Una marca de viajes para smartphones tiene requisitos de aprovisionamiento distintos de un fabricante que despliega localizadores sellados en varios países.
SIM24.biz puede ayudar al socio a estructurar el modelo de conectividad, plataforma y operaciones necesario. El soporte concreto de una arquitectura GSMA, tipo de eUICC, componente de aprovisionamiento o función remota de ciclo de vida debe confirmarse para la implementación y combinación de proveedores elegidas. En la fecha de este borrador no se afirma públicamente que SIM24.biz opere por sí misma un eIM, SM-DP+, SM-SR o una plataforma SGP.32 certificada.
Esta distinción protege a ambas partes. Evita prometer que un producto de consumo con QR ofrece gestión completa de flotas IoT, o que una eUICC IoT puede utilizar cualquier plataforma de perfiles sin trabajo de compatibilidad.
Conclusión
La eSIM de consumo y la eSIM IoT comparten una idea general: los perfiles de operadores móviles pueden aprovisionarse de forma segura en una eUICC compatible. Sus entornos operativos son fundamentalmente diferentes.
La arquitectura de consumo SGP.21/22 presupone un dispositivo capaz de participar en un proceso interactivo de adquisición de perfil. Utiliza componentes como SM-DP+, LPA y SM-DS opcional y encaja bien en smartphones, tabletas y dispositivos manejados por usuarios.
La arquitectura IoT SGP.31/32 se diseña para dispositivos limitados por conectividad, interfaz o ambas. Introduce IPA y eIM para permitir gestión remota orientada a flotas utilizando infraestructura de perfiles SM-DP+.
La arquitectura M2M SGP.01/02 sigue siendo importante en despliegues consolidados de automoción e industria. SGP.41 añade una opción separada para aprovisionar perfiles durante la fabricación.
Ningún estándar elimina la necesidad de probar dispositivos, disponer de conectividad inicial, acuerdos de red, operaciones de flota o contratos claros. La arquitectura correcta es la que permite aprovisionar, conectar, recuperar y migrar los dispositivos reales durante toda su vida útil prevista.
Preguntas frecuentes
¿Cuál es la diferencia principal entre SGP.22 y SGP.32?
SGP.22 es la especificación técnica de la arquitectura eSIM de consumo, utilizada habitualmente por dispositivos interactivos como smartphones. SGP.32 es la especificación técnica de la arquitectura IoT diseñada para dispositivos con restricciones de red o interfaz y para la gestión de flotas.
¿Cuál es la diferencia entre SGP.21 y SGP.22?
SGP.21 define la arquitectura y los requisitos de consumo. SGP.22 proporciona la especificación técnica detallada que implementa esa arquitectura.
¿Cuál es la diferencia entre SGP.31 y SGP.32?
SGP.31 define la arquitectura y los requisitos del aprovisionamiento eSIM en dispositivos IoT limitados. SGP.32 especifica procedimientos técnicos detallados, interfaces, arquitectura eUICC y funciones de seguridad.
¿Qué son un IPA y un eIM?
El IoT Profile Assistant es la función del lado del dispositivo que admite operaciones de perfil en SGP.31/32. Puede residir en el dispositivo como IPAd o en la eUICC como IPAe. El eSIM IoT Remote Manager permite interacciones autorizadas de gestión remota con el IPA.
¿Utiliza SGP.32 un SM-DP+?
Sí. La arquitectura IoT utiliza un SM-DP+ para preparar y entregar perfiles. Una solución completa sigue necesitando dispositivo IoT, eUICC, IPA, eIM e interfaces de gestión compatibles.
¿Es SGP.32 mejor que SGP.22?
Es más adecuada para determinados entornos IoT, no universalmente mejor. Una eSIM de viaje para smartphone normalmente encaja en la arquitectura de consumo. Una flota de sensores desatendidos puede encajar en SGP.32.
¿Sustituye SGP.32 a SGP.01 y SGP.02?
Proporciona una arquitectura más reciente para despliegues IoT adecuados, pero dispositivos y plataformas M2M existentes coexistirán durante años. La migración depende del hardware, software, contratos y ciclos de sustitución.
¿Puede actualizarse un dispositivo eSIM de consumo existente a SGP.32?
No automáticamente. El dispositivo, la eUICC y el software deben admitir la arquitectura IoT. Una actualización de firmware por sí sola puede ser insuficiente.
¿Puede SGP.32 cambiar un dispositivo entre operadores móviles?
Admite aprovisionamiento y gestión remotos de perfiles, lo que puede permitir cambiar de operador cuando existen perfiles compatibles, autorizaciones, conectividad y acuerdos comerciales. No anula restricciones del dispositivo, del contrato o de la red.
¿Es SGP.32 necesaria para todos los despliegues IoT?
No. Algunos routers o terminales accesibles pueden utilizar correctamente eSIM de consumo. Los despliegues industriales existentes pueden utilizar arquitectura M2M. La decisión depende del modelo operativo real.
¿Qué es SGP.41?
SGP.41 define arquitectura y requisitos del aprovisionamiento de perfiles en fábrica. Aborda la entrega de perfiles durante la fabricación y complementa, no sustituye, la gestión del ciclo de vida en campo.
Elija una arquitectura eSIM adecuada para todo el ciclo de vida del dispositivo
SIM24.biz ayuda a las empresas a diseñar ofertas de conectividad de consumo e IoT con su propia marca, basadas en dispositivos reales, condiciones operativas y requisitos de gestión.
Hable con SIM24.biz sobre el modelo de aprovisionamiento y conectividad adecuado para su producto o flota.
Fuentes
- GSMA, «eSIM Consumer and IoT Specifications»: https://www.gsma.com/solutions-and-impact/technologies/esim/esim-specification/
- GSMA, «A Guide to eSIM Architectures»: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/a-guide-to-esim-architectures/
- GSMA, «SGP.21 v2.6, eSIM Consumer Architecture and Requirements»: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-21-v2-6/
- GSMA, «SGP.22 v2.7, eSIM Consumer Technical Specification»: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-22-v2-7/
- GSMA, «SGP.31 v1.3, eSIM IoT Architecture and Requirements»: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-31-v1-3/
- GSMA, «SGP.32 v1.3, eSIM IoT Technical Specification»: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-32-v1-3/
- GSMA, «M2M Specifications»: https://www.gsma.com/solutions-and-impact/technologies/esim/esim-m2m-specifications/
- GSMA, «SGP.01 v4.3, Embedded SIM Remote Provisioning Architecture»: https://www.gsma.com/solutions-and-impact/technologies/esim/wp-content/uploads/2022/11/SGP.01-v4.3-1.pdf
- GSMA, «SGP.02 v4.3, Remote Provisioning Architecture for Embedded UICC Technical Specification»: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-02-remote-provisioning-architecture-for-embedded-uicc-technical-specification-v4-3/
- GSMA, «SGP.41 v1.0, eSIM IFPP Architecture and Requirements»: https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/esim-ifpp-architecture-and-requirements/
- Android Open Source Project, «Implement eSIM»: https://source.android.com/docs/core/connect/esim-overview