ES2942454T3 - Mecanismo de descubrimiento de servicios para servicios de configuración de habilitación del esim - Google Patents

Abstract

La invención se refiere a un método de descubrimiento de servicios para activar un dispositivo de módulo de identidad de suscriptor integrado (eSIM) que comprende: Iniciar al menos un dispositivo que comprende una eSIM; conectar el dispositivo a al menos uno de un punto de entrada de un operador de red móvil y un servidor de configuración de derechos designado, usar una configuración de derechos para activar automáticamente la eSIM a través de la conexión al servidor de configuración de derechos y conectar la eSIM con un servicio de datos o un red de datos del operador de red móvil en función de la autorización de casos de uso designados, en los que el dispositivo y el servidor de configuración de autorización validan parámetros y/o metodologías para la configuración de autorización. La invención también se refiere a un sistema para un derecho de eSIM, que comprende al menos un dispositivo con un eSIM, (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Mecanismo de descubrimiento de servicios para servicios de configuración de habilitación del esim

La presente solicitud se refiere a un método de descubrimiento de servicios para activar un dispositivo de módulo de identidad de abonado integrado (eSIM).

La solicitud se refiere además a un sistema para una habilitación del eSIM, que comprende al menos un dispositivo con un eSIM, al menos un punto de entrada de un servicio de datos o una red de datos de un operador de red móvil y un servidor de configuración de habilitación designado conectado al punto de entrada.

Los dispositivos respectivos de eSIM proporcionados con un eSIM se están volviendo más populares, y se espera que ganen mucho más terreno en los próximos años. Múltiples grupos de la industria, tales como 3gpp y GSMA, están, por lo tanto, trabajando en tecnologías normalizadas para habilitar el desarrollo de un entorno de la industria interoperable y de trabajo adecuado. En el Grupo de Dirección de Terminales de la GSMA (GMSA-TSG), el artículo de trabajo «TS.43 Habilitación del servicio» se ocupa de métodos, procedimientos y protocolos normalizados para habilitar los casos de uso de la habilitación del eSIM. Los casos de uso más importantes a estos respectos son la activación del servicio en el dispositivo (ODSA) para dispositivos primarios y secundarios, así como también transferencia del abono para dispositivos primarios y/o secundarios.

La TS.43 es esencial para el desarrollo de eSIM de la industria, puesto que normaliza los procedimientos que son necesarios para habilitar al equipo de usuario para que reciba y maneje los abonos de eSIM. A medida que la TS.43 va ganando cada vez más interés de parte de múltiples fabricantes de equipos originales (OEM) y operadores, también incluye cada vez más opciones sobre cómo se puede implementar una posible preparación de un servidor de habilitación.

Para el futuro, esto significa que cada operador tiene que hablar con cada OEM con el fin de alinearse sobre la forma de implementación para su red específica. Esto motivará una gran desventaja para operadores y OEM más pequeños. También aumenta la complejidad y el coste, a medida que el eSIM gana más terreno y la TS.43 tiene una mayor evolución.

La solicitud de patente US 2020/260241 A1 divulga una posible preparación de sistemas que se ocupan de proporcionar eSIM. La idea presentada en esta invención es hacer uso de la tecnología proporcionada por los métodos, procedimientos y protocolos normalizados de la TS.43. La solicitud de patente define la tecnología general, pero excluye la posibilidad de que existan numerosas formas posibles para preparar una infraestructura de habilitación. Dado que las redes de operadores de red móvil (MNO) difieren, así como también las capacidades del dispositivo, no es posible considerar la tecnología mostrada como una solución «única».

La presente solicitud tiene la intención de proponer un mecanismo que proporcionaría una solución normalizada para una infraestructura de habilitación para activar un dispositivo de eSIM, como un teléfono celular. Para conseguir este propósito, la solicitud incorpora los métodos, procedimientos, protocolos y parámetros normalizados de cada paso de verificación de habilitación divulgado en la TS.43. Además, la presente aplicación hace uso de las definiciones de sus artículos y términos.

El problema se resuelve mediante el método de la reivindicación 1 y el sistema de la reivindicación 15. Algunas formas de realización preferidas de la invención se agregan a las reivindicaciones dependientes. La principal característica del método propuesto es que el dispositivo y el servidor de configuración de habilitación (ECS) validan parámetros y/o metodologías para la configuración de habilitación. En el sentido de la solicitud, validar significa un procedimiento de evaluación de las interfaces y métodos para determinar si satisfacen los requisitos específicos del caso de habilitación. Debido a ello, el dispositivo que pide la habilitación y la red que habilita la habilitación pueden acordar un conjunto de parámetros y/o metodologías sobre cómo proceder con la configuración de habilitación.

De este modo, la solución es establecer un «mecanismo de descubrimiento de servicios». Un dispositivo, que solicita la habilitación del servicio desde una red, puede indicar que admite una clase específica de configuración de habilitación (p. ej., TS.43). La red también puede indicar que admite la habilitación de la TS.43.

Al definir un conjunto específico de posibilidades de implementación, el dispositivo y la red pueden acordar fácilmente un modo preferido de habilitación del servicio. Algunos ejemplos para diferentes formas de implementación son suministro de perfil en caso de suministro retrasado, comportamiento de sondeo/transmisión automática, soporte de protocolos o servicios específicos.

Antes de insertar cualquier procedimiento de habilitación en la red, un dispositivo insertaría un «procedimiento de descubrimiento de servicios» en la red/ECS. En este procedimiento, el dispositivo enumeraría todas sus diferentes capacidades con respecto a la habilitación del servicio. A continuación, la red/ECS podría enviar de regreso la configuración con la que desea proceder. Esto se puede implementar fácilmente usando REST, SOAP o una interfaz similar. A continuación, el dispositivo y la red saben cómo actuar y reaccionar en todos los diferentes procedimientos de habilitación.

Dado que actualmente no existe un «mecanismo de descubrimiento de servicios», los procedimientos de habilitación del eSIM solo funcionan para unos pocos OEM de envergadura con un puñado de MNO. Por lo tanto, un «mecanismo de descubrimiento de servicios» habilitaría a dispositivos de mercado abierto para que usen servicios de configuración de habilitación en cada red que admita el mismo mecanismo de descubrimiento de servicios.

El despliegue de dispositivos de eSIM en el campo está creciendo, y se espera que crezca mucho más en el futuro. Para habilitar la interoperabilidad, es esencial una norma como TS.43. Asimismo, el método del «mecanismo de descubrimiento de servicios» propuesto y su sistema relacionado reduce el coste y la complejidad, y posibilita un despliegue mayor.

A continuación, algunas formas de realización preferidas de los pasos de habilitación del «mecanismo de descubrimiento de servicios» se describen en más detalle, algunas de ellas se muestran como flechas de niveles de pasos sucesivos en la figura 1.

Para iniciar el método del «mecanismo de descubrimiento de servicios», existen algunos prerrequisitos que deben cumplirse. Al adaptar el procedimiento mostrado en la TS.43, el dispositivo necesita descubrir el nombre del dominio conocido del ECS. P. ej., el ECS suministra el recurso siguiente: OBTENER <well_known_domain>/apps. Al quedarse en este ejemplo, el ECS suministra además un recurso por aplicación admitida: OBTENER <well_known_domain>/apps/<app_id>.

En una forma de realización preferida del método, el dispositivo tiene que detectar los casos de uso admitidos. Por lo tanto, solicita al ECS que proporcione casos de uso admitidos por el ECS y reconoce la respuesta regresada por el ECS para habilitar los elementos de la interfaz de usuario que son requeridos para los casos de uso admitidos por el ECS y/o deshabilitar los elementos de la interfaz de usuario para los casos de uso que no son admitidos por el ECS. Los diferentes casos de uso que pueden ser suministrados por un ECS se identifican en la TS.43 mediante las llamadas «app ID (identidad de la aplicación)». Cada app ID identifica un caso de uso que requiere soporte para ciertas llamadas API, estructuras de datos e interacciones de usuario del lado del dispositivo y del lado del ECS.

Con el fin de permitir que el dispositivo encuentre qué casos de uso son admitidos por el ECS, se propone el mecanismo siguiente: El dispositivo envía la solicitud siguiente: OBTENER <well_known_domain>/apps, como se muestra en el nivel de paso 1 de la figura 1.

El ECS regresa una lista de aplicaciones admitidas mediante un documento legible por máquina (p. ej., JSON, YAML, XML), que se muestra con el siguiente nivel de paso 2 de la figura 1. A continuación, el dispositivo puede reconocer la lista recibida para habilitar o deshabilitar los elementos de la interfaz de usuario que son requeridos o no requeridos para las aplicaciones o casos de uso contenidos o no contenidos en la lista.

Cuando un dispositivo decide usar uno de los servicios o aplicaciones ofrecidos en el ECS, aún queda cierta incertidumbre sobre si los parámetros requeridos por el ECS pueden proporcionarse y serán proporcionados por el dispositivo. De ese modo, las llamadas API y parámetros requeridos tienen que detectarse en un segundo paso del método. Por lo tanto, el dispositivo solicita al servidor de configuración de habilitación que proporcione parámetros admitidos para un caso de uso designado y compara la respuesta regresada por el servidor de configuración de habilitación con sus proprios parámetros admitidos para el caso de uso designado.

Con el fin de aprender, qué llamadas API y parámetros son ordenados por el ECS para esta app id, se proponen los siguientes pasos preferidos: Mostrado con el nivel de paso 3 de la figura 1, el dispositivo envía la solicitud siguiente: OBTENER <well_known_domain>/apps/<app_id>.

Se prefiere que el parámetro admitido para un caso de uso designado respondido por el servidor de configuración de habilitación encierre puntos finales api y/o estructuras de datos proporcionados para el caso de uso designado. De este modo, el ECS debería regresar un documento legible por máquina que describa los puntos finales api y estructuras de datos esperados en la solicitud, así como también las respuestas enviadas por el e Cs , como se muestra con el nivel de paso 4 de la figura 1.

El nivel de paso 5 de la figura 1 se refiere solo al dispositivo, que reconoce el documento y lo compara con su propia lista de llamadas API y elementos de datos admitidos para configurar su conjunto de características. Tal documento legible por máquina para la descripción API podría estar siguiendo una especificación OpenAPI 3.

Si los requisitos del ECS y las capacidades del dispositivo no se corresponden, el dispositivo debería deshabilitar la funcionalidad y/o elementos de la interfaz de usuario relacionados. Por lo tanto, se prefiere que el dispositivo deshabilite la funcionalidad y/o elemento de la interfaz de usuario del caso de uso designado si un parámetro designado para el caso de uso designado admitido por el dispositivo no corresponde al parámetro designado para el caso de uso designado admitido por el ECS.

Si un dispositivo admite todas las llamadas API requeridas por el ECS y puede proporcionar todos los datos requeridos, un paso siguiente del método propuesto debería ser validar mutuamente las solicitudes y respuestas. De ese modo, se prefiere que el dispositivo determine secuencias de llamadas para una validación automatizada de las solicitudes y respuestas. Resulta útil subdividir la validación automatizada en dos pasos intermedios. Primero, se debe realizar la detección respectiva de la descripción de secuencias de llamadas. Luego, sigue la validación formal de solicitudes y respuestas desde la secuencia de llamadas contra la descripción formal de la interfaz obtenida en la detección de llamadas API y parámetros requeridos.

Se debería realizar la detección respectiva de la descripción de secuencias de llamadas, porque en algunos escenarios, diferentes clases de implementaciones son permitidas por el documento normalizado, lo que produce diferentes flujos de llamadas. De ese modo, se prefiere que, si una noma para la habilitación del eSIM permite diferentes implementaciones de secuencias de llamadas para el caso de uso designado, el dispositivo solicita al servidor de configuración de habilitación que proporcione la implementación admitida por el servidor de configuración de habilitación.

Con el fin de aprender qué flujos de llamadas son admitidas y qué comportamiento del dispositivo es esperado por el ECS, el dispositivo podría enviar la solicitud siguiente: OBTENER <well_known_domain>/apps/<app-id>/flows, como se muestra en el nivel de paso 6 de la figura 1.

El ECS podría regresar un documento legible por máquina que enumere los respectivos flujos de llamadas esperados o elegibles admitidos, que se muestra con el nivel de paso 7 de la figura 1. Esto puede hacerse como una lista ordenada de referencias de las secciones respectivas de la descripción api obtenida por el dispositivo durante la detección de llamadas API y parámetros requeridos. Si el ECS responde con un código de error HTTP (p. ej., 404), la validación automatizada no es admitida por el ECS.

Nuevamente, el dispositivo reconoce la información y la usa para configurar su conjunto de características, como se muestra con el nivel de paso 8 de la figura 1.

En este contexto, es una opción preferida que el parámetro admitido para un caso de uso designado respondido por el ECS encierre un enlace a datos de prueba para un paso de la secuencia de llamadas y el dispositivo solicite a los datos de prueba del enlace proporcionado que validen el paso de la secuencia de llamadas. Si un paso del documento entregado en el paso anterior contiene un enlace a un conjunto de datos de prueba, estos datos pueden ser usados por el dispositivo para validar este paso. Se prefiere que el dispositivo recupere los datos de prueba del link proporcionado en una descripción de secuencias o pasos.

Sobre la base de la descripción de secuencias recibida en el primer paso intermedio, el dispositivo puede ejecutar el segundo paso intermedio para validar mutuamente la interfaz entre el ECS y el dispositivo. Una validación preferida podría seguir este procedimiento preferido por paso de cada secuencia de llamada, como se muestra con el nivel de paso 9 de la figura 1: El dispositivo envía una solicitud de validación al ECS para validar los parámetros admitidos para un caso de uso designado. Esta podría ser la solicitud: OBTENER/REGISTRAR <well_known_domain>/apps/<appid>/validate(?<test_data>).

Si la solicitud de validación del dispositivo falla la validación del ECS, una respuesta de error regresa al dispositivo y el caso de uso designado no se ofrece al dispositivo.

Si el ECS responde un acuerdo a la validación del caso de uso designado, el dispositivo valida sus parámetros admitidos para el caso de uso designado. El dispositivo podría validarlo contra sus propias expectativas o contra la descripción formal de la respuesta recibida durante la detección de llamadas API y parámetros requeridos. A continuación, el dispositivo y el ECS pueden usar los servicios de habilitación normalizados para activar el eSIM del dispositivo, como se muestra con el nivel de paso 10 de la figura 1.

Pero en caso de que la solicitud desde el dispositivo falle la validación del ECS, debería regresar una respuesta de error significativa que pueda usarse para depuración. De ahí, el caso de uso / escenario afectado no debería ofrecerse al cliente en este caso. Por ende, si la validación de los parámetros admitidos para el caso de uso designado recibido por el ECS falla, el caso de uso designado no se establece en el dispositivo.

En caso de que la respuesta desde el ECS falle la validación de los dispositivos, el caso de uso / escenario afectado tampoco debería ser ofrecido por el cliente.

En un paso opcional, el dispositivo puede proporcionar información sobre la validación fallida al ECS si la especificación API formal contiene un punto final para recolectar telemedida de caso de uso, p. ej., mediante <well_known_domain>/apps/<app-id>/telemetry. Por consiguiente, se prefiere que, si una noma para la habilitación del eSIM contiene un punto final para recolectar datos del caso de uso, el dispositivo proporcione información sobre la validación fallida al servidor de configuración de habilitación.

Claims (15)

REIVINDICACIONES

1. Un método de descubrimiento de servicios para activar un dispositivo de módulo de identidad de abonado integrado, eSlM, que comprende:

Iniciar al menos un dispositivo que comprende un eSIM; conectar el dispositivo a al menos uno de un punto de entrada de un operador de red móvil y un servidor de configuración de habilitación designado, usando una configuración de habilitación para activar automáticamente el eSIM por medio de la conexión al servidor de configuración de habilitación y conectar el eSIM con un servicio de datos o una red de datos del operador de red móvil sobre la base de una habilitación de casos de uso designados,

en donde el dispositivo y el servidor de configuración de habilitación validan parámetros y/o metodologías para la configuración de habilitación,

caracterizado por que

el dispositivo solicita (3) al servidor de configuración de habilitación que proporcione parámetros admitidos para un caso de uso designado y compara (5) la respuesta regresada por el servidor de configuración de habilitación con sus proprios parámetros admitidos para el caso de uso designado.

2. El método de la reivindicación 1,

caracterizado por que

el dispositivo solicita (1) al servidor de configuración de habilitación que proporcione casos de uso admitidos por el servidor de configuración de habilitación y reconoce la respuesta regresada por el servidor de configuración de habilitación para habilitar los elementos de la interfaz de usuario que son requeridos para los casos de uso admitidos por el servidor de configuración de habilitación y/o deshabilitar los elementos de la interfaz de usuario para los casos de uso que no son admitidos por el servidor de configuración de habilitación.

3. El método de la reivindicación 1,

caracterizado por que

el dispositivo deshabilita la funcionalidad y/o elemento de la interfaz de usuario del caso de uso designado si un parámetro designado para el caso de uso designado admitido por el dispositivo no corresponde al parámetro designado para el caso de uso designado admitido por el servidor de configuración de habilitación.

4. El método de la reivindicación 1 o 3,

caracterizado por que

el parámetro admitido para un caso de uso designado respondido por el servidor de configuración de habilitación encierra puntos finales api y/o estructuras de datos proporcionados para el caso de uso designado.

5. El método de una de las reivindicaciones de 2 a 4,

caracterizado por que

el dispositivo determina secuencias de llamadas para una validación automatizada de las solicitudes y respuestas.

6. El método de la reivindicación 5,

caracterizado por que

si una noma para la habilitación del eSIM permite diferentes implementaciones de secuencias de llamadas para el caso de uso designado, el dispositivo solicita al servidor de configuración de habilitación que proporcione la implementación admitida por el servidor de configuración de habilitación.

7. El método de la reivindicación 6,

caracterizado por que

el parámetro admitido para un caso de uso designado respondido por el servidor de configuración de habilitación encierra un enlace a datos de prueba para un paso de la secuencia de llamadas y el dispositivo solicita a los datos de prueba del enlace proporcionado que validen el paso de la secuencia de llamadas.

8. El método de una de las reivindicaciones de 5 a 7,

caracterizado por que

el dispositivo y el servidor de configuración de habilitación validan la interfaz entre el dispositivo y el servidor de configuración de habilitación.

9. El método de la reivindicación 8,

caracterizado por que

el dispositivo envía una solicitud de validación al servidor de configuración de habilitación para validar los parámetros admitidos para un caso de uso designado.

10. El método de la reivindicación 9,

caracterizado por que

si la solicitud de validación del dispositivo falla la validación del servidor de configuración de habilitación, una respuesta de error regresa al dispositivo y el caso de uso designado no se ofrece al dispositivo.

11. El método de la reivindicación 9,

caracterizado por que

si el servidor de configuración de habilitación responde un acuerdo a la validación del caso de uso designado, el dispositivo valida sus parámetros admitidos para el caso de uso designado.

12. El método de la reivindicación 9,

caracterizado por que

si el servidor de configuración de habilitación responde un acuerdo a la validación del caso de uso designado, el dispositivo valida el parámetro admitido para el caso de uso designado contra los parámetros admitidos para el caso de uso designado recibido por el servidor de configuración de habilitación.

13. El método de la reivindicación 9,

caracterizado por que

si la validación de los parámetros admitidos para el caso de uso designado recibido por el servidor de configuración de habilitación falla, el caso de uso designado no se establece en el dispositivo.

14. El método de la reivindicación 13,

caracterizado por que

si una noma para la habilitación del eSIM contiene un punto final para recolectar datos del caso de uso, el dispositivo proporciona información sobre la validación fallida al servidor de configuración de habilitación.

15. Un sistema para una habilitación del módulo de identidad de abonado integrado, eSIM,

que comprende al menos un dispositivo con un eSIM, al menos un punto de entrada de un servicio de datos o una red de datos de un operador de red móvil y un servidor de configuración de habilitación designado conectado al punto de entrada,

caracterizado por que

la habilitación del eSIM está implementada entre el dispositivo y el servidor de configuración de habilitación designado usando un método de descubrimiento de servicios según unas de las reivindicaciones de 1 a 14.