A method of operating an autonomous and resilient universal integrated circuit card, uicc, and corresponding device.
Abstract
A universal integrated circuit card (UICC) is provided for controlling radio communications over a radio communications network to and from a host device in which the UICC is installed in use, the UICC comprising: a microprocessor for control the operation of the UICC; a data store for storing data related to the operation of the UICC, the data store comprising: a plurality of mobile operator network profiles including: an operational profile comprising radio communications network configurations to connect the main device to a first radio communications network; and a boot profile comprising configuring the radio communications network to connect the primary device to a second radio communications network; and a program comprising a plurality of instructions for configuring the operation of the UICC; wherein, in use, the program configures the microprocessor to: use the operating profile to connect the host device to the first radio communications network; detecting a loss of operational connectivity with the first radio communications network; and using the boot profile to connect the primary device to the second radio communications network to reestablish radio communications to and from the primary device. Also provided is a main device comprising a processor having a memory, a radio module for connecting the main device to a radio communications network and the universal integrated circuit device. Also provided is a method for operating a UICC and a computer-implemented method for reestablishing a radio communications network connection between a host device and a network platform that provides the radio communications network connection, where the device main includes a UICC.

Term
14.4 yearsleft in the term
Expires 16 February 2041.
- Priority
- Filed
- Granted
- Today
- Expires
28 claims: 11 independent, 17 dependent
- 1Una tarjeta de circuito integrado universal (UICC) para controlar las comunicaciones por radio a través de una red de comunicaciones por radio hacia y desde un dispositivo principal en el que la UICC está instalada en uso, caracterizada porque comprende:un microprocesador para controlar el funcionamiento de la UICC;un almacén de datos para almacenar los datos relacionados con el funcionamiento de la UICC, el almacén de datos que comprende: una pluralidad de perfiles de red de operadores móviles que incluyen: un perfil operativo que comprende la configuración de la red de comunicaciones por radio para conectar el dispositivo principal a una primera red de comunicaciones por radio;y un perfil de arranque que comprende la configuración de la red de comunicaciones por radio para conectar el dispositivo principal a una segunda red de comunicaciones por radio;y Ri?nn ίη/ζζηζ/Ε/γίΛΐ un programa que comprende una pluralidad de instrucciones para configurar el funcionamiento de la UICC;en donde, en uso, el microprocesador es configurado por el programa para: usar el perfil operativo para conectar el dispositivo principal a la primera red de comunicaciones por radio;detectar una pérdida de conectividad operativa con la primera red de comunicaciones por radio;y usar el perfil de arranque para conectar el dispositivo principal a la segunda red de comunicaciones por radio para restablecer las comunicaciones por radio hacia y desde el dispositivo principal.
- 2La UICC de conformidad con la reivindicación 1, caracterizada porque es una UICC integrada (eUICC) que permite que el programa y los perfiles se configuren y/o actualicen de forma remota.
- 3La UICC de conformidad con las reivindicaciones 1 ó 2, caracterizada porque el programa comprende un subprograma que tiene un tamaño relativamente pequeño y una funcionalidad especifica.
- 4La UICC de conformidad con cualquier reivindicación anterior, caracterizada porque el almacén de datos se proporciona en un dominio transversal seguro de la UICC y el perfil operativo o el perfil de arranque puede proporcionar acceso seguro al dominio transversal seguro de la UICC para permitir que un servidor externo realice cambios en Ri?nn Ln/zznz/E/YiAi el programa almacenado en el mismo.
- 5La UICC de conformidad con cualquier reivindicación anterior, caracterizada porque comprende además un conjunto de parámetros variables almacenados como archivos en el almacén de datos para configurar los perfiles operativos y de arranque y su uso para controlar las comunicaciones por radio a través de la red de comunicaciones por radio hacia y desde el dispositivo principal.
- 6La UICC de conformidad con cualquier reivindicación anterior, caracterizada porque el programa comprende instrucciones para configurar el microprocesador en uso para:realizar una primera prueba de conectividad de la red de radiocomunicaciones para probar la conectividad de la red de radiocomunicaciones entre el dispositivo principal y la primera red de radiocomunicaciones y devolver un primer resultado de la prueba de conectividad basado en la prueba de conectividad de la red de radiocomunicaciones;determinar, basándose en el resultado de la primera prueba de conectividad, si se ha producido una pérdida de conectividad de la red de comunicaciones por radio entre el dispositivo principal y la primera red de comunicaciones por radio;y si se ha determinado tal pérdida de conexión, anular el perfil operativo y seleccionar el perfil de arranque y usar el perfil de arranque para conectarse a la segunda red de comunicaciones de radio en función de la configuración de red del perfil de arranque para restablecer la conectividad de la red de comunicaciones de radio con el dispositivo principal.
- 7La UICC de conformidad con cualquier reivindicación anterior, caracterizada porque el programa comprende instrucciones para configurar el microprocesador en uso para:iniciar un temporizador de cancelación, durante un periodo de tiempo predeterminado cuando se haya detectado una pérdida de conexión en la primera red;anular la selección del perfil de arranque y volver a seleccionar el perfil operativo una vez que se complete el temporizador de cancelación, y usar el perfil operativo para volver a conectarse a la primera red de comunicaciones por radio para restablecer la conectividad de la red de comunicaciones por radio entre el dispositivo principal y la primera red de radiocomunicaciones.
- 8La UICC de conformidad con cualquier reivindicación anterior, caracterizada porque el programa comprende instrucciones para configurar el microprocesador en uso para:realizar, siguiendo el uso del perfil de arranque para conectar el dispositivo principal a la segunda red de comunicaciones por radio, una segunda prueba de conectividad de la red de comunicaciones por radio para probar la conectividad de la red de comunicaciones por radio entre el dispositivo principal y la segunda red de comunicaciones por radio;y devolver un segundo resultado de la prueba de conectividad basado en la prueba de conectividad de la red de comunicaciones por radio;determinar, en base al resultado de la segunda prueba de conectividad, si se ha producido una pérdida de conectividad de la red de comunicaciones por radio entre el dispositivo principal y la segunda red de comunicaciones por radio;y si se ha determinado tal pérdida de conexión, anular la selección del perfil de arranque y volver a seleccionar el perfil operativo y usar el perfil operativo para conectarse a la primera red de comunicaciones por radio en función de la configuración de red del perfil operativo para restablecer la conectividad de la red de comunicaciones por radio al dispositivo principal.
- 9La UICC de conformidad con las reivindicaciones 7 u 8, caracterizada porque el programa comprende instrucciones para configurar el microprocesador en uso para:determinar un intervalo de tiempo para usar el perfil operativo reseleccionado;y retrasar la desconexión de la segunda red de radiocomunicaciones y el uso del perfil operativo reseleccionado para conectarse a la primera red de Ri?nn ίη/ζζηζ/Ε/γίΛΐ 100 radiocomunicaciones hasta que se alcance el intervalo de tiempo.
- 10La UICC de conformidad con la reivindicación 9, caracterizada porque el intervalo de tiempo se determina usando un número aleatorio o un dígito tomado de un ICCID, IMEI o MISDIN asociado con la UICC o el dispositivo principal.
- 11La UICC de conformidad con cualquiera de las reivindicaciones 8 a 10, caracterizada porque el programa comprende instrucciones para configurar el microprocesador, en uso, para realizar la primera o la segunda prueba de conectividad de la red de comunicaciones por radio probando la conectividad de la red de comunicaciones por radio entre el dispositivo principal y uno o más servidores de prueba dentro de la red de comunicaciones por radio que se está probando.
- 12La UICC de conformidad con la reivindicación 11, caracterizada porque el programa comprende instrucciones para configurar el microprocesador en uso para realizar la primera o la segunda prueba de conectividad de la red de radiocomunicaciones mediante la realización de una prueba de búsqueda de direcciones en Internet, en la que la prueba de búsqueda de direcciones en Internet comprende:enviar, a un servidor de prueba de uno o más servidores de prueba, un paquete de datos de reenvío;determinar si se recibe un paquete de datos de respuesta desde el servidor de prueba;y Ri?nn Ln/zznz/E/YiAi 101 devolver un primer o segundo resultado negativo de la prueba de conectividad de la red de comunicaciones por radio si el paquete de datos de respuesta no se recibe desde el servidor de prueba dentro de un período de tiempo predeterminado desde el envío del paquete de datos de reenvío.
- 13La UICC de conformidad con la reivindicación 11, caracterizada porque el programa comprende instrucciones para configurar el microprocesador en uso para realizar la primera o la segunda prueba de conectividad de la red de radiocomunicaciones mediante la realización de una prueba de secuencia de búsqueda de direcciones en Internet, en la que la prueba de la secuencia de búsqueda de direcciones en Internet comprende:enviar, a un primer servidor de prueba de uno o más servidores de prueba, un primer paquete de datos de reenvío;determinar si se recibe un primer paquete de datos de respuesta desde el primer servidor de prueba dentro de un primer período de tiempo predeterminado;enviar, a un segundo servidor de prueba de uno o más servidores de prueba, un segundo paquete de datos de reenvío, si se determina que el primer paquete de datos de respuesta no se recibe dentro del primer período de tiempo predeterminado;determinar si se recibe un segundo paquete de datos de respuesta desde el segundo servidor de prueba dentro de un segundo período de tiempo predeterminado;κπηη Ln/zznz/E/YiAi 102 enviar, a un tercer servidor de prueba de uno o más servidores de prueba, un tercer paquete de datos de reenvío, si se determina que el sequndo paquete de datos de respuesta no se recibe dentro del segundo período de tiempo predeterminado;determinar si el tercer paquete de datos de respuesta se recibe desde el tercer servidor de prueba dentro de un tercer período de tiempo predeterminado;devolver un resultado de prueba de la secuencia de búsqueda de direcciones en Internet neqativo si se determina que el tercer paquete de datos de respuesta no se recibe dentro del tercer período de tiempo predeterminado;devolver un primer o segundo resultado negativo de la prueba de conectividad de la red de comunicaciones por radio si se devuelve el resultado de la búsqueda de direcciones en Internet de secuencia neqativa.
- 14La UICC de conformidad con la reivindicación 13, caracterizada porque el programa comprende instrucciones para configurar el microprocesador en uso para realizar la primera o segunda prueba de conectividad de la red de radiocomunicaciones repitiendo la prueba de la secuencia búsqueda de direcciones en Internet una o más veces;y en el que el resultado negativo de la prueba de conectividad de la red de radiocomunicaciones se devuelve solo si el número de resultados negativos consecutivos de la prueba de la secuencia Rfrnn ίη/ζζηζ/Ε/γίΛΐ 103 de búsqueda de direcciones en Internet supera un umbral predeterminado.
- 15La UICC de conformidad con la reivindicación 11, caracterizada porque el programa comprende instrucciones para configurar el microprocesador en uso para realizar la primera o la segunda prueba de conectividad de la red de radiocomunicaciones mediante la realización de una prueba de datos, en la que la prueba de datos comprende:enviar, a un servidor de prueba, una cantidad predeterminada de datos;determinar si la cantidad predeterminada de datos ha sido entregada al servidor de prueba;y devolver un primer o segundo resultado negativo de la prueba de conectividad de la red de comunicaciones por radio en el caso de que la cantidad predeterminada de datos no se haya entregado al servidor de prueba.
- 16La UICC de conformidad con la reivindicación 11, caracterizada porque el programa comprende instrucciones para configurar el microprocesador en uso para realizar la primera o la segunda prueba de conectividad de la red de comunicaciones por radio realizando una prueba de capa de la red, en la que la prueba de capa de la red comprende:probar diferentes capas de la red de la primera o segunda red de comunicaciones por radio. 17 . La UICC de conformidad con cualquier Ri?nn ίη/ζζηζ/Ε/γίΛΐ 104 reivindicación anterior, caracterizada porque el almacén de datos comprende un perfil de itinerancia que comprende la configuración de la red de comunicaciones por radio para conectar el dispositivo principal a una red de comunicaciones por radio en itinerancia;y el programa comprende instrucciones para configurar el microprocesador en uso, después de detectar la pérdida de conectividad operativa con la primera red de comunicaciones, para usar el perfil de itinerancia para conectar el dispositivo principal a la red de comunicaciones de radio de itinerancia en función de la configuración de la red del perfil de itinerancia para restablecer las comunicaciones de radio hacia y desde el dispositivo principal.
- 1718. La UICC de conformidad con cualquier reivindicación anterior, caracterizada porque el almacén de datos comprende una pluralidad de perfiles de la red de radio, cada uno de los cuales comprende las configuraciones de la red de comunicaciones por radio para conectar el dispositivo principal a una red de comunicaciones por radio respectiva;y la UICC está configurada para permitir la selección remota del perfil operativo y el perfil de arranque de la pluralidad de perfiles.
- 1819. La UICC de conformidad con cualquiera de las reivindicaciones 1 a 17, caracterizada porque κπηη Ln/zznz/E/YiAi 105 el almacén de datos comprende una pluralidad de perfiles de la red de radio, cada uno de los cuales comprende las configuraciones de la red de comunicaciones por radio para conectar el dispositivo principal a una red de comunicaciones por radio respectiva;y la UICC está configurada para permitir la selección del usuario local del perfil operativo y el perfil de arranque de la pluralidad de perfiles.
- 1920. La UICC de conformidad con las reivindicaciones 18 ó 19, caracterizada porque cada perfil de la red de radio de la pluralidad de perfiles de la red de radio está asociado con una red de comunicaciones de radio independiente diferente.
- 2021. La UICC de conformidad con las reivindicaciones 18 ó 19, caracterizada porque cada perfil de red en la pluralidad de perfiles de red está asociado con una plataforma de red de comunicaciones por radio independiente o una instancia diferente de la misma plataforma de la red de comunicaciones por radio.
- 2122. La UICC de conformidad con cualquier reivindicación anterior, caracterizada porque comprende una eUICC, una Mini SIM, una Micro SIM, una Nano SIM o una SIM soldable.
- 2223. Un dispositivo principal, caracterizado porque comprende un procesador que tiene una memoria, un módulo de radio para conectar el dispositivo principal a una red de κπηη Ln/zznz/E/YiAi 106 comunicaciones por radio, y el dispositivo de circuito integrado universal de conformidad con cualquiera de las reivindicaciones 1 a 21.
- 2324. El dispositivo principal de conformidad con la reivindicación 23, caracterizado porque comprende un dispositivo de alarma, un teléfono inteligente, una tableta, un dispositivo de protección, un enrutador, un dispositivo de rastreo GPS, un dispositivo M2M, un dispositivo loT, un vehículo, un dispositivo de telesalud o un dispositivo de teleasistencia.
- 2425. Un método de operación de una tarjeta de circuito integrado universal (UICC) para controlar las comunicaciones de radio a través de una red de comunicaciones de radio hacia y desde un dispositivo principal en el que la UICC está instalada en uso, caracterizado porque comprende:proporcionar acceso a los datos relacionados con el funcionamiento de la UICC almacenados en un almacén de datos de la UICC, los datos que incluyen una pluralidad de perfiles de la red de operadores móviles que incluyen: un perfil operativo que comprende la configuración de la red de comunicaciones por radio para conectar el dispositivo principal a una primera red de comunicaciones por radio;y un perfil de arranque que comprende la configuración de la red de comunicaciones por radio para conectar el Ri?nn Ln/zznz/E/YiAi 107 dispositivo principal a una segunda red de comunicaciones por radio;y controlar el funcionamiento de la UICC usando un microprocesador de la UICC y un programa que comprende una pluralidad de instrucciones para configurar el funcionamiento de la UICC;la etapa de control que comprende: conectar el dispositivo principal a la primera red de comunicaciones por radio usando el perfil operativo, detectar una pérdida de conectividad operativa con la primera red de comunicaciones por radio;y conectar el dispositivo principal a la segunda red de comunicaciones por radio usando el perfil de arranque, para restablecer las comunicaciones por radio hacia y desde el dispositivo principal.
- 2526. Un producto de programa de computadora o un medio de almacenamiento legible por computadora, caracterizado porque comprende instrucciones que, cuando son ejecutadas por una computadora, hacen que la computadora realice el método de conformidad con la reivindicación 25.
- 2627. Un método implementado por computadora para restablecer una conexión de la red de comunicaciones por radio entre un dispositivo principal y una plataforma de la red que proporciona la conexión de la red de comunicaciones por radio, en el que el dispositivo principal incluye una tarjeta de circuito integrado universal (UICC) que tiene un perfil de red Ri?nn Ln/zznz/E/YiAi 108 de operador móvil para controlar la conexión de la red de radiocomunicaciones, caracterizado porque comprende:recibir, desde la UICC a través de la conexión de la red de comunicaciones por radio, un primer paquete de datos;recibir, desde la UICC a través de la conexión de la red de comunicaciones por radio, un segundo paquete de datos;determinar los primeros datos de tiempo indicativos de la cantidad de tiempo transcurrido entre la recepción del primer paquete de datos y la recepción del segundo paquete de datos;comparar los primeros datos de tiempo con un umbral de tiempo predeterminado;transmitir una solicitud de restablecimiento desde la plataforma de la red de comunicaciones por radio para restablecer la conexión de la red de comunicaciones por radio al dispositivo principal, si los primeros datos de tiempo son mayores que el umbral de tiempo predeterminado.
- 2728. El método implementado por computadora de conformidad con la reivindicación 27, caracterizado porque comprende además:iniciar un temporizador de reinicio después de la etapa de comparación, si los primeros datos de tiempo son mayores que el umbral de tiempo predeterminado;y comparar un valor del temporizador de reinicio con un umbral del temporizador de reinicio predeterminado;Ri?nn Ln/zznz/E/YiAi 109 en el que la etapa de transmisión se retrasa hasta que el valor del temporizador de reinicio es mayor que el umbral del temporizador de reinicio predeterminado.
- 2829. El método implementado por ordenador de conformidad con las reivindicaciones 27 ó 28, caracterizado porque el umbral predeterminado del temporizador de reinicio es configurable para diferentes periodos de tiempo.
Independent claims28
272 paragraphs in 3 sections, as filed
METHOD TO OPERATE AN INTEGRATED CIRCUIT CARD
UNIVERSAL (UICC) AUTONOMOUS AND RESILIENT AND DEVICE
CORRESPONDENT
Ri?nn Ln/zznz/E/YiAi
Field of Invention
The present invention relates to a self-contained and resilient universal integrated circuit (UICC) device. In particular, but not exclusively, the present invention relates to a UICC for controlling radio communications over a radio communications network to and from a central device in which the UICC is installed in use.
Background of the Invention Alarm signaling device and alarm network
In the event of an emergency, communications from the emergency location or person in need to emergency services or other entities requiring emergency alert must be prompt, responsive, and accurate. For example, in police and fire response, blue light emergency response, and telecare personal alarm systems, the speed and reliability of communication is critical as the emergency may involve a life-threatening situation. . However, current systems in this field often suffer from connectivity issues and outages and therefore unreliable communication channels. This can lead to the
Ref. 336831 signaling to emergency services is slow and does not respond. When using a telecare personal alarm system, slow or unresponsive signaling to emergency health services or nearby caregivers could present a risk to the health, or even life, of the person in need. In the case of an intruder alarm system, slow or unresponsive signaling to emergency police response could cause an intruder or attacker to escape after committing a crime.
There are several conventional signaling methods in remote monitoring of alarm systems in order to send signals between an alarm device and a remote alarm receiving center, where the remote alarm receiving center can subsequently alert emergency services or other entities that require emergency alert: Redcare, DualCom and Digicom. Redcare uses dual-path signaling, meaning it uses a Global System for Mobile (GSM) radio network path and a telephone line to communicate with the remote alarm receiving center. Both signaling paths are constantly polled to verify that the communication link is working and to indicate if there are any faults or errors on the line. Emizon also adopts dual-path signaling using one GSM radio network path and an on-site broadband connection. DualCom GPRS, from CSL DualCom Limited, is also a dual-path signaling device for intrusion alarms using the GSM radio network, with and without the use of General Packet Radio Service (GPRS). , and a wired telephone and/or Internet route to transmit intruder alarms, fire and personal attack signals, at high speed. If a first radio communications path using a GSM GPRS link cannot transmit signals, a second radio communications path using a non-GPRS GSM link can be used instead. As another example, if the wired telephone route, for example PSTN, was cut then the intruder alarm signaling device could communicate via a GSM GPRS link or a non-GPRS GSM link using a mobile network, for example Vodafone PakNet, or 2G mobile networks. Digicom, unlike previous signaling solutions, uses a single route over a telephone line to communicate with the remote alarm receiving center. A telephone line failure would result in a lack of communication capability. Therefore, dual-path connectivity solutions can be integrated into security devices to provide resilience against physical attacks and issues arising from connectivity providers such as mobile network operators (MNOs).
An alarm network 100 that uses dual-path signaling to communicate between an alarm device 102 and a remote alarm receiving center 104 is shown in Figure 1 (prior art). Alarm network 100 is described below with reference to DualCom GPRS, which is the subject of European patent application published as EP2124207 entitled An alarm network, as an example.
The purpose of the alarm network 100 is to improve communications between an alarm device 102, such as an intruder alarm unit or a fire alarm unit, and a remote alarm receiving center 104. Upon fulfillment of an alarm condition , such as detecting the presence of an intruder, the alarm device 102 emits and transmits an alarm signal to the remote alarm receiving center 104 through the alarm network 100. The remote alarm receiving center 104 then takes appropriate action, which could include, for example, informing the person responsible for the premises or informing the police.
The alarm device 102 includes a radio module 106, which is arranged to transmit and receive on the GSM radio network, with and without GPRS. A radio antenna 108 is connected to the radio module 106 and arranged to operate on the GSM network frequency and for use with GPRS. The alarm device 102 further includes a SIM card 110. The SIM card 110 stores account and communication details for
Rfrnn ίη/ζζηζ/Ε/γίΛΐ allow the radio module 106 to work on the GSM network and according to GPRS. It should be noted that the SIM card used in the particular DualCom GPRS example connects to a single MNO, specifically, Vodafone. The alarm network described below therefore uses a single MNO network, specifically, the MNO1 network 112 as shown in Figure 1. Additional MNO networks, such as MNO2 network 120 and MNO3 network 124, and corresponding servers such as MNO2 server 122 and MNO3 server 126, are appropriate when the SIM included within the alarm device can be connected to one of a plurality of MNOs. This is described in more detail below with reference to roaming SIMs.
The alarm device 102 also includes an input interface (not shown), a microprocessor (not shown), non-volatile memory (not shown), and a telephone line interface (not shown) to provide communication with a public switched telephone network (PSTN) telephone line.
The alarm network 100 provides several communication paths, between the alarm device 102 and the remote alarm reception center 104. These can be divided into a first radio communication path using a GPRS GSM link, a second communication path by radio using a non-GPRS GSM link and a wired communications path
Ri?nn Ln/zznz/E/YiAi that uses a PSTN line.
To establish the first radio communications path using the GPRS GSM link, a GPRS GSM radio communications link is initially provided between the alarm device 102 and a GPRS base station (not shown) of an MNO network (MNO1 network in figure 1) 112. A secure land line path is provided between the GPRS base station of the MNO network 112 and an MNO server 114 over the Internet 116, and also between the MNO server 114 and a base station (not shown) of a communications network wireless 118. Finally, the base station communicates with the remote alarm reception center 104 by radio through the wireless communications network 118. By way of specific example, the secure landline used in DualCom GPRS is provided by one or more leased lines or tunnels of a virtual private network (VPN), and the wireless communications network 118 is provided by Vodafone's Paknet, over an X.25 network like the one provided by Kilostream.
The second radio communications path using a non-GPRS GSM link may be established between the alarm device 102 and the remote alarm receiving center 104 in an analogous manner. To establish the second radio communications path using a non-GPRS GSM link, a radio communications link is initially provided.
Rfrnn ίη/ζζηζ/Ε/γίΛΐ non-GPRS GSM radio between the alarm device 102 and a GSM base station (which may or may not be the same as the GPRS base station used in the first radio communications path); of the MNO network 112. The GSM base station of the MNO network 112 is in communication with a base station of the wireless communications network 118 through the secure fixed route, through the MNO server 114 and the Internet 116. Finally, the base station then communicates with the remote alarm receiving center 104 by radio via the wireless communications network 118.
To establish the wired communications path between the alarm device 102 and the remote alarm receiving center 104, a first wired connection 128 is provided between the alarm device 102 and a telephone exchange 130 using, for example, a line. PSTN or Broadband. A second wired connection 132 is provided between the telephone exchange 130 and the alarm receiving center 104, again using, for example, a PSTN or broadband line. The telephone exchange 130 can also be connected to the Internet 116 via a cable connection. In DualCom GPRS, a PSTN line is used in order to establish the wired communications path between the alarm device 102 and the remote alarm receiving center 104.
The DualCom GPRS alarm device includes three modes of operation: Standby Mode, Alarm Mode and Link Failure Mode. In the standby mode, the alarm device 102 periodically sends a polling signal over the first radio communications path to the MNO server 114, also known as the polling server, of the alarm network 100. The polling signal indicates to the MNO server 114 that the alarm device 102 is functioning correctly. If no polling signal has been received after a predetermined time limit, the MNO server 114 sends a query signal to the alarm device 102 through the second radio communications path to check whether the alarm device 102 is working correctly or not. Upon receiving the query signal, the alarm device 102 attempts to send a response signal over the second radio communications path to confirm that the query signal has been received and that the alarm device 102 can respond accordingly. Upon receiving the response signal, the MNO server 114 therefore determines that the first radio communications path is not operational, but the second radio communications path is operational. Similarly, the alarm device 102 can detect whether the wired communications path is operational or not. Upon detecting that one of the routes has failed, the alarm device 102 enters link failure mode to communicate this failure to the MNO server 114 and the remote alarm receiving center 104.
When an alarm condition is met, for example motion has been detected, the alarm device 102 enters the alarm mode. The alarm device 102 generates and attempts to send an alarm signal to the remote alarm receiving center 104 so that appropriate action can then be taken. The alarm device 102 makes three attempts to transmit the alarm signal over the first radio communications path, then two attempts to transmit the alarm signal over the second radio communications path, followed by two attempts to transmit the alarm signal through the wired communications path. This routine ends when an acknowledgment signal is received from the remote alarm receiving center 104. The alarm device 102 then exits alarm mode. The purpose of the above routine in alarm mode is to ensure that signal transmission is attempted on an operable path, resulting in successful communication with the remote alarm receiving center 104, in case one or two of the communication routes become inoperable.
The prior art, as described with reference to Figure 1 and exemplified by DualCom GPRS, provides multiple communication paths to increase the chances of an alarm signal being transmitted to the center.
Ri?nn ίη/ζζηζ/Ε/γίΛΐ remote alarm reception 104, which can continue to operate satisfactorily even if some of the routes could become inoperable.
MNO Network Selection
The SIM card used in DualCom GPRS connects to a single MNO, specifically, Vodafone. In order to further improve resilience in signaling devices, a roaming SIM could be used where a roaming SIM has the ability to connect and operate on one of a plurality of MNO networks. For example, if the SIM 110 of the alarm device 102 shown in Figure 1 is a roaming SIM, the roaming SIM can connect not only to the MNO1 network 112, but also to a second MNO network (MN02) 120 and a MNO's third network 124 (MNO3). The roaming SIM stores a first, second, and third profiles associated with MNO1 network 112, MNO2 network 120, and MNO3 network 124, respectively. The MNO network that has the most stable connection can be selected for the radio communications path.
In typical mobile device use, such as web browsing on a mobile phone, an auto-roaming algorithm is used to select and switch between mobile operator networks. Automatic roaming typically involves a user having an agreement with a local MNO, where the local MNO itself maintains a list of roaming MNOs that
Ri?nn Ln/zznz/E/YiAi have a roaming agreement with the local MNO. The list of roaming MNOs is then prioritized to provide a preferred list of roaming MNOs, so that if the connection to the local MNO fails, connection to one of the roaming MNOs is attempted in the order of the prioritized list. However, signal integrity is crucial in alarm signaling devices and the roaming MNO selected by auto roaming may not provide the best signal integrity for a given area.
Alternative roaming algorithms have been developed for use in alarm devices, which select a roaming MNO that provides improved signal integrity. As an example, UK patent application published as GB2533853 entitled Selecting a cellular network for communication of an alarm signal based on reliably of the available cellular networks the reliability of available cellular networks) uses a roaming SIM, for example Vodafone GDSP, as part of the alarm device to select an MNO network. The key features of the alarm device 202, including the roaming SIM, are shown in Figure 2 (prior art) and are briefly described below.
The alarm device 202 includes a radio module 206 and an associated roaming SIM 210. The alarm device 202 further includes a radio antenna 208 connected to the radio module 206 for transmitting and receiving GPRS data. The alarm device 202 also includes a microcontroller 203 having a memory 205 that includes a flash memory and a non-volatile memory. The microcontroller 203 is connected to the radio module 206. The microcontroller 203 processes data for transmission and data received by the radio module 206 through the radio antenna 208. The microcontroller 203 controls the radio module 206 in relation to such transmission and reception of data. The microcontroller 203 also controls the radio link with an MNO network through the roaming SIM 210 associated with the radio module 206. Therefore, the microcontroller 203 controls and determines which MNO network the alarm device 202 is connected to. An algorithm called connection manager 207 is maintained in memory 205, which when executed on the microcontroller 203 allows transmission and reception of data between the alarm device 202 and the Internet through the MNO network.
The alarm device 202 also includes the following features in relation to the microcontroller 203 that, for simplicity, are not shown in Figure 2: a user interface, sensors, a power management circuit, an external input/output , a PSTN interface and a LAN interface.
The roaming SIM 210 can be connected to one of a plurality of MNO networks, such as the MNO1 network 212, the MNO2 network 220 and the MNO3 network 224. The radio module 206 uses the functionality of survey to provide information about the MNO networks 212, 220, 224 available at the location of the alarm device 202. The alarm device 202 then measures the reliability of the communication over each of the available MNO networks 212, 220, 224 based on signal strength. For each MNO network available at the location, the alarm device 202 instructs the radio module 206 and the roaming SIM 210 to connect in turn to each of the available MNO networks 212, 220, 224. The alarm device 202 then instructs the radio module 206 to transmit, via the radio antenna 208, a signal packet to a primary polling server (not shown) over the connected MNO network. In response, the primary polling server transmits a signal packet (not shown) back to the alarm device 202. The microcontroller 203 of the alarm device 202 analyzes the signal packet and saves data in memory 205 corresponding to the cell signal quality, the signal-to-noise ratio, the number of cells within the effective range of the alarm device 202. alarm 202 and bit error rate. The connection manager 207 then decides, based on the data collected for each of the MNO networks 212, 220, 224, when a change should be made to the MNO network and to what extent.
Ri?nn ίη/ζζηζ/Ε/γίΛΐ MNO network connection must be made. The connection manager 207 selects the MNO network with the highest measure of reliability. Through the connection manager 207, the microcontroller 203, the radio module 206 and the roaming SIM 210 are instructed to register and connect to the selected MNO network.
Some roaming SIMs are capable of not only roaming between MNO networks in the SIM's home country, but also between MNO networks in other countries. Such international roaming SIMs are used in alarm devices to provide access to additional MNO networks. As an example, DualCom Pro, from CSL DualCom Limited, uses an international roaming SIM, specifically, a multi-network 4G WorldSIM international SIM. An international roaming SIM card associated with a home network in your home country can be used in any other country that has a roaming agreement with the home network. For example, if a particular roaming SIM is associated with a local MNO operating in a home country outside the UK, when switched on in the UK, the roaming SIM could move between all available MNOs in the UK. UK that have a roaming agreement with the home MNO, rather than being locked to a single MNO in the UK. If an MNO had an outage, as determined by the network, then the SIM could be instructed to simply roam and connect to the next available MNO. This provides access to all mobile networks and uses a roaming algorithm to select the network with the strongest signal, thus eliminating downtime.
Dual SIM alarm devices
Since 2018, an increase in MNO outages has been seen as 4G networks have become capable of frequent network upgrades. To address this concern, alarm devices with a plurality of SIM slots and a plurality of associated radio modules, also known as dual SIM and dual radio alarm devices, were launched in 2019. Such devices include two or more SIM slots to enable two or more SIM cards operating on two independent radio modules to be used within the same alarm device. In case the device detects an MNO outage, while using a primary SIM located in a primary SIM slot, the device can switch from the primary SIM slot to the secondary SIM slot. A secondary SIM placed in the secondary SIM slot would then be connected to its respective MNO. For example, GradeShift Pro Radio/Radio, from CSL DualCom Limited, uses two 4G WorldSIMs, one as the primary path and one as the secondary path. Each SIM operates on a network independent of the other and uses its own radio module.
eUICC SIM: Backup and backup cancellation
Currently, the standard SIM card is a Universal Integrated Circuit Card (UICC) SIM and its applications and data play a vital role in ensuring the connectivity and security of the alarm device and network. The GSM Association (GSMA), based on existing UICC technology, defined a set of Integrated UICC (eUICC) specifications (also known as eSIM) that enable Over-the-Provisioning. Air (OTA) MNO profiles (subscriptions) on an eUICC SIM. This allows the SIM card operator to change the active MNO profile to allow the SIM to connect to an alternative MNO network.
When designing the eUICC's OTA capabilities, the main challenge the GSMA addressed was being able to change the SIM profile without having to physically visit the device. For example, if a new MNO profile was sent to the SIM, but for some reason the new MNO profile did not work, it would not be desirable to lose contact with the SIM. The OTA capabilities meant there was no need to physically visit the device to change the SIM, which is expensive to do. If an error occurred while switching to a new profile, it would render the device unusable until physically visited for repair as it would have lost connectivity.
The GSMA has defined two separate implementations of eUICC. The first implementation is aimed at the consumer's selection of the MNO network (also known as the consumer solution). For the direct-to-consumer channel, which targets consumers and businesses, this solution is required when the end-user (or consumer) has the direct option of MNO supply network connectivity. Alternate MNO profiles are sent to the eUICC and the consumer device. Since consumer devices have keyboards and displays, the device may present options that allow the consumer to actively choose an MNO to provide network connectivity. This is known as an extraction solution (to the device). As an example, the Apple SIM can be configured with different MNO profiles and present the different MNO profiles to the user through the user interface of the mobile device. This allows the user to actively choose and select the MNO profile and therefore connect to the MNO network of their choice.
The second implementation is aimed at business-to-business customers (also known as an M2M solution). For business-to-business channels, this solution meets the needs of business-to-business customers specifically in the Internet of Things (IoT) market. As devices may not have screens or keyboards and the device may be in a remote location, operators need the ability to push new MNO profiles and configurations to the eUICC. The standards for this are different than the consumer solution described above. This is known as an introductory (to-device) solution.
In the two previous implementations of eUICC, there are processes to control switching between different MNO profiles (for example, MNO Y and MNO X) so that the eUICC can reconnect in the event of a network outage or failure. from MNO. Such processes are now exemplified with reference to the alarm device 302 shown in Figure 3 (prior art). The alarm device 302 includes a radio module 306 and the associated eUICC 310. The alarm device 302 further includes a radio antenna 308 and a microcontroller 303 having a memory 305 containing a program 307, which are analogous to the corresponding features of the alarm device 202 shown in Figure 2. The program 307 when executed on the microcontroller 303 it allows the transmission and reception of data between the alarm device 302 and the Internet through the MNO Y network 312 or the MNO X network 320. As with the alarm device 202 of Figure 2, the microcontroller 303 of the alarm device 302 of Figure 3 controls the radio module 306 in relation to such transmission and reception of data, as well as the radio link with a MNO network through eUICC 310.
The eUICC 310 includes, in its memory (not shown), two profiles (shown schematically in Figure 3) so each profile is associated with a different MNO. That is, a first profile 311, which is often called an operational profile, is associated with MNO Y. A second profile 313, which is called a backup profile or boot profile, is associated with MNO X. The terms The backup profile and boot profile can be used interchangeably. For simplicity, the first profile 311 will be referred to as the operating profile 311 and the second profile 313 will be referred to as the backup profile 313 hereinafter.
In this example, the operational profile 311 is currently active, which means that the eUICC 310 is connected to the MNO Y network 312. In the event that the MNO Y network 312 or the alarm device 302 identifies a loss of service, a loss of service is identified. notifies eUICC 310 of the event. For example, if the MNO Y network 312 rejects a connection attempt due to a problem with the MNO Y network 312, such as network congestion, PLMN-specific network failures, or authentication failures, this network rejection event is provided to the eUICC 310 to communicate to the microcontroller 303 that there is no service available using the MNO Y network 312 due to a network rejection event. Alternatively, the microcontroller 303 together with
Rfrnn ίη/ζζηζ/Ε/γίΛΐ the radio module 306 of the alarm device 302 may identify a loss of service with the MNO Y network 312 and then communicate a loss of service event to the eUICC 310.
The eUICC 310 receives the network rejection event generated by the network or the loss of service event generated by the device and, upon receipt, triggers a process called a backup process. The backup process requires the eUICC 310 to switch from the operational profile, which is associated with MNO Y, to the boot profile, which is associated with a different MNO, in this example, MNO X. As a result, the eUICC 210 connects to the MNO X network 320, allowing the alarm device 302 to reconnect and come back online. It is important to note that the backup process is initiated by receiving a command from the network 312 or the alarm device 302 itself.
In the event of an outage in the MNO Canceling the backup allows the eUICC 310 to cancel the backup mechanism, thereby changing the eUICC 310 from the boot profile 313 to the operational profile 311. This was initially implemented for the automotive industry where the car may need to make an emergency call in the event of an accident if there was an interruption in the starting profile,
Ri?nn ίη/ζζηζ/Ε/γίΛΐ then the car would not be able to make a call, therefore the backup cancellation process was designed to switch from boot profile to operating profile. As with the backup process, to initiate the backup cancellation process, the alarm device 302 or the network 320 is required to command the eUICC 310 to perform the backup cancellation to return to the operating profile.
In summary, current state-of-the-art implementations of eUICC allow backup and unbackup processes to be performed only through the device or network that identifies connectivity issues or loss of service and subsequently , instructs the eUICC to switch between the operating profile and the boot profile. Without commands or instructions from the device or network, current implementations using eUICC cannot perform backup and unbackup processes.
This presents significant problems for the connectivity of the eUICC 310. First, in existing solutions, an interruption or failure of the MNO network can be detected only by the device or the network. The eUICC 310 is not capable of detecting or identifying an interruption independently. This can result in a time delay between the time the interruption occurs, the time the interruption is detected, and
Rfrnn ίη/ζζηζ/Ε/γίΛΐ the time when the eUICC receives instructions to change profiles and connect to a different MNO. Additionally, if the device or network does not detect an outage, then the eUICC will lose connectivity and will be stranded until the outage issues are resolved. The device may also have poorly implemented the standards, again resulting in the eUICC or the device being stranded.
Second, once the eUICC 310 has changed from the operating profile 311 associated with MNO Y to the boot profile 313 associated with MNO X, the MNO X network 320 may experience an outage or failure. In this situation, the backup cancellation process would normally have to be carried out manually from a remote platform. In rare circumstances, the backup cancellation process can be carried out by device instructions. In any case, if the MNO X network 320 experiences an outage and the backup cancellation process has not been implemented, the eUICC 310 will lose connectivity as a result.
The eUICC 310 in existing systems is effectively a slave to the device and network, and must be instructed to perform certain actions, such as performing backup and unbackup processes.
For example, if the eUICC 310 is in operating profile 311 and the network 312 or the device 302 detects an interruption in the MNO Y network 312, upon receiving an instruction from the network 312 or the device 302, the eUICC 310 changes the profile operating 311 to the boot profile 313 so that it can connect to the MNO X network 320. While in boot profile 313, the issues that caused the outage in the MNO Y network 312 are resolved, resulting in the MNO Y network 312 becoming functional again. If the MNO Initiating the backup cancellation process from the remote platform to switch to operational profile 311 would not be possible because the eUICC 310 is offline and can no longer be accessed. The eUICC 310 would remain disconnected until the outage in the MNO X network 320 is resolved and the eUICC 310 is manually reconnected to the MNO Y network 312.
It should now be clear that current eUICC implementations are still susceptible to failure under certain circumstances and are therefore not capable of responding to an outage autonomously or resiliently. Although mobile networks are an ideal transmission path for communications with emergency services, disruptions to MNO networks, for example due to frequent network upgrades or network failures, combined with a lack of resilience, can be seriously disruptive to communications and signaling in emergency response systems.
The present invention aims to overcome or at least partially mitigate one or more of the problems described above.
Summary of the Invention
The present invention relates to an improved self-contained and resilient SIM card that provides an improved method of dealing with disruptions in MNOs, for example due to frequent network updates or network failures. As a result of the improvement of the resilient and autonomous SIM card, the interruption of communications that use mobile networks as a transmission path is drastically reduced. This, in turn, has positive consequences on the signaling of emergency response systems, resulting in faster and more responsive alerts to emergency services.
The enhanced resilient and self-contained SIM card comprises an applet, which is installed on the SIM. The applet is configured to detect a loss of connectivity in MNO networks and manage profiles associated with different MNOs to ensure that connectivity is maintained whenever the active MNO providing the connectivity service experiences an outage. The SIM
Ri?nn Ln/zznz/E/YiAi of the present invention thus becomes interruption-proof.
It is important to note that in embodiments of the present invention, the operational logic to identify a possible outage in an MNO network exists in the applet, which runs in the SIM. This is in contrast to prior art systems where only the device or network would be able to identify a potential outage. Additionally, the operational logic for starting the backup and backup cancellation processes exists in the applet. In contrast, prior art systems require the device or network to instruct the SIM to perform these processes.
The SIM uses two or more independent MNOs and operates autonomously, so no human, platform or device interaction is required to maintain uptime and service continuity. Additionally, the SIM provides this functionality without requiring any changes to the device with which it is deployed.
Furthermore, a key advantage of the eUICC SIM of the present invention is that it can be adapted to any device that is compatible with an eUICC SIM card. For example, legacy devices that were designed and manufactured before GSMA standards were implemented or ratified cannot mimic the backup and unbackup processes using a standard SIM card. To address this problem, the SIM applet of the present invention provides the required standards in the SIM and allows instructions for the backup and backup cancellation processes to be activated from within the SIM. The SIM can be used in any device that is compatible with an eUICC SIM, including legacy devices that previously would not have been able to imitate such processes.
According to a first aspect of the present invention, a universal integrated circuit card (UICC) is provided for controlling radio communications over a radio communications network to and from a host device in which the UICC is installed in use. , the UICC comprising: a microprocessor to control the operation of the UICC; a data store for storing data related to the operation of the UICC, the data store comprising: a plurality of mobile operator network profiles including: an operational profile comprising radio communications network configurations for connecting the main device to a first radio communications network; and a boot profile comprising configuring the radio communications network to connect the primary device to a second radio communications network; and a program comprising a plurality of instructions to configure the operation
Ri?nn Ln/zznz/E/YiAi of UICC; wherein, in use, the program configures the microprocessor to: use the operating profile to connect the host device to the first radio communications network; detecting a loss of operational connectivity with the first radio communications network; and use the boot profile to connect the primary device to the second radio communications network to reestablish radio communications to and from the primary device.
The UICC can be an integrated UICC (eUICC) that allows the program and profiles to be configured and/or updated remotely.
The program may comprise a subprogram that had a relatively small size and specific functionality.
Data storage may be provided in a UICC secure traversal domain and the operating profile or boot profile may securely provide access to the UICC secure traversal domain to allow an external server to make changes to the program stored there. .
The UICC may further comprise a set of variable parameters, stored as files in the data store for configuring operational and boot profiles and their use to control radio communications over the radio communications network to and from the κπηη Ln/zznz/E/YiAi main device. Parameters can be stored in separate configuration files, so that the configuration file can be replaced by an update process. An example of a parameter stored in a configuration file is an Internet address lookup server address.
The program may comprise instructions for configuring the microprocessor in use to: perform a first radio communications network connectivity test to test the connectivity of the radio communications network between the host device and the first radio communications network and returning a first connectivity test result based on the radio communications network connectivity test; determining, based on the result of the first connectivity test, whether a loss of radio communications network connectivity has occurred between the host device and the first radio communications network; and if such connection loss has been determined, deselect the operating profile and select the boot profile and use the boot profile to connect to the second radio communications network based on the boot profile network configuration to reestablish radio communications network connectivity with the host device.
The program may include instructions for
Ri?nn ίη/ζζηζ/Ε/γίΛΐ configure the microprocessor in use to: start a cancellation timer, for a predetermined period of time when a connection loss has been detected on the first network; deselect the boot profile and reselect the operating profile once the cancel timer completes, and use the operating profile to reconnect to the first radio communications network to restore communications network connectivity by radio between the main device and the first radio communications network.
The program may comprise instructions for configuring the microprocessor in use to: perform, following use of the boot profile to connect the host device to the second radio communications network, a second connectivity test of the radio communications network to test the connectivity of the radio communications network between the main device and the second radio communications network; and returning a second connectivity test result based on the radio communications network connectivity test; determining, based on the result of the second connectivity test, whether a loss of radio communications network connectivity has occurred between the primary device and the second radio communications network; and if such connection loss has been determined, deselect the connection profile.
Ri?nn Ln/zznz/E/YiAi boot and reselect the operating profile and use the operating profile to connect to the first radio communications network based on the network settings of the operating profile to reestablish connectivity. the radio communications network with the main device.
In some embodiments, the program comprises instructions for configuring the microprocessor in use to: determine a time interval for using the reselected operating profile; and delaying disconnecting the second radio network and using the reselected operating profile to connect to the first radio network until the time interval is reached.
Preferably, the time interval is determined using a random number or digit taken from an ICCID, IMEI or MISDIN associated with the UICC or the host device. However, the time interval can be determined by other means.
In some embodiments, the program comprises instructions for configuring the microprocessor, in use, to perform the first or second radio network connectivity test by testing the radio network connectivity between the host device and one or more test servers. within the network
Ri?nn ίη/ζζηζ/Ε/γίΛΐ radio communications being tested.
Preferably, the program comprises instructions for configuring the microprocessor in use to perform the first or second connectivity test of the radio communications network by performing an Internet address lookup test, wherein the Internet address lookup test comprises: sending, to a test server of one or more test servers, forwarding a data packet; determining whether a response to the data packet is received from the test server; and returning a first or second negative radio network connectivity test result if a response to the data packet is not received from the test server within a predetermined period of time from sending the forwarding data packet.
The program may comprise instructions for configuring the microprocessor in use to perform the first or second connectivity test of the radio communications network by performing an Internet address lookup sequence test, in which the Internet address lookup sequence test The Internet comprises: sending, to a first test server of one or more test servers, a first forwarding data packet; if it is determined that a first response to the data packet from the first test server is not received within a first predetermined time period; sending, to a second test server of one or more test servers, a second forwarding data packet, if it is determined that the first response data packet is not received within the first predetermined time period; determining whether a second response data packet is received from the second test server within a second predetermined time period; sending, to a third test server of one or more test servers, a third forwarding data packet, if it is determined that the second response data packet is not received within the second predetermined time period; determining whether the third response data packet is received from the third test server within a third predetermined time period; returning a negative Internet address lookup sequence test result if it is determined that the third response data packet is not received within the third predetermined time period; return a first or second negative radio communications network connectivity test result if the negative sequence Internet address lookup result is returned.
The program may comprise instructions for configuring the microprocessor in use to perform the first or second connectivity test of the radio communications network by repeating the search sequence test.
Ri?nn Ln/zznz/E/YiAi addresses on the Internet one or more times; and wherein the negative radio network connectivity test result is returned only if the number of consecutive negative Internet address lookup sequence test results exceeds a predetermined threshold.
In some embodiments, the program comprises instructions for configuring the microprocessor in use to perform the first or second connectivity test of the radio communications network by performing a data test, wherein the data test comprises: sending, to a test server, a predetermined amount of data; determine whether the predetermined amount of data has been delivered to the test server; and returning a first or second negative radio communications network connectivity test result in the event that the predetermined amount of data has not been delivered to the test server.
The program may comprise instructions for configuring the microprocessor in use to perform the first or second connectivity test of the radio communications network by performing a network layer test, where the network layer test comprises: testing different network layers of the first or second radio communications network.
In some embodiments, the data store comprises a roaming profile comprising network configurations.
Radio communications Rfrnn ίη/ζζηζ/Ε/γίΛΐ for connecting the host device to a roaming radio communications network; and the program comprises instructions for configuring the microprocessor in use, after detecting the loss of operational connectivity with the first communications network, to use the roaming profile to connect the host device to the roaming radio communications network based on Roaming profile network settings to reestablish radio communications to and from the primary device.
The data store may comprise a plurality of radio network profiles, each of which comprises radio communications network configurations for connecting the host device to a respective radio communications network; and the UICC may be configured to allow remote selection of the operating profile and the boot profile from the plurality of profiles.
The data store may comprise a plurality of radio network profiles, each of which comprises radio communications network configurations for connecting the host device to a respective radio communications network; and the UICC may be configured to allow selection of the local user of the operating profile and the boot profile from the plurality of profiles.
Preferably, each radio network profile in the
Ri?nn ίη/ζζηζ/Ε/γίΛΐ plurality of radio network profiles is associated with a different independent radio communications network.
In some embodiments, each network profile in the plurality of network profiles is associated with an independent radio communications network platform or a different instance of the same radio communications network platform.
The UICC may comprise an eUICC, a Mini SIM, a Micro SIM, a Nano SIM or a solderable SIM.
According to a second aspect of the present invention, there is provided a main device comprising a processor having a memory, a radio module for connecting the main device to a radio communications network and the universal integrated circuit device described above. With reference to the first aspect of the present invention.
The primary device may comprise an alarm device, a smartphone, a tablet, a protection device, a router, a GPS tracking device, an M2M device, an IoT device, a vehicle, a telehealth device, or a telecare.
According to a third aspect of the present invention, a method is provided for operating a universal integrated circuit card (UICC) to control radio communications over a radio communications network to and from a host device in which The UICC is installed in use, the method comprising: providing access to data related to the operation of the UICC stored in a UICC data store, the data including a plurality of mobile operator network profiles including: an operational profile comprising configurations of the mobile communications network radio to connect the main device to a first radio communications network; and a boot profile comprising configuring the radio communications network to connect the primary device to a second radio communications network; and controlling the operation of the UICC using a UICC microprocessor and a program comprising a plurality of instructions for configuring the operation of the UICC; the control step comprising: connecting the main device to the first radio communications network using the operational profile, detecting a loss of operational connectivity with the first radio communications network; and connecting the primary device to the second radio communications network using the boot profile, to reestablish radio communications to and from the primary device.
According to a fourth aspect of the present invention, a software program product is provided.
Rfrnn ίη/ζζηζ/Ε/γίΛΐ computer or a computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to perform the method described above with reference to the third aspect of the present invention.
According to a fifth aspect of the present invention, a computer-implemented method is provided for reestablishing a radio communications network connection between a host device and a network platform that provides the radio communications network connection, wherein the main device includes a universal integrated circuit card (UICC) having a mobile operator network profile for controlling the connection of the radio communications network, the method comprising: receiving, from the UICC through connecting the radio communications network, a first data packet; receiving, from the UICC through the radio communications network connection, a second data packet; determining first time data indicative of the amount of time elapsed between receipt of the first data packet and receipt of the second data packet; comparing the first time data with a predetermined time threshold; transmit a reset request from the radio communications network platform to reestablish the radio communications network connection
Ri?nn Ln/zznz/E/YiAi to the main device, if the first time data is greater than the default time threshold.
The computer-implemented method may further comprise: starting a reset timer after the comparison step, if the first time data is greater than the predetermined time threshold; and comparing a reset timer value with a predetermined reset timer threshold; wherein the transmission stage is delayed until the reset timer value is greater than the default reset timer threshold.
The default reset timer threshold can be set for different time periods.
Within the scope of this application it is expressly intended that the various aspects, modalities, examples and alternatives set out in the previous paragraphs, in the claims and/or in the following description and figures, and in particular the individual characteristics thereof, can be taken independently or in any combination. That is, all modalities and/or characteristics of any modality can be combined in any way and/or combination, unless such characteristics are incompatible. The applicant reserves the right to change any claim originally submitted or to submit any new claim in
Ri?nn Ln/zznz/E/YiAi consequence, including the right to modify any claim originally submitted so that it depends on and/or incorporates any features of any other claim, even if it was not originally claimed in this way.
Brief Description of the Figures
Next, the present invention will be described, solely by way of example, with reference to the attached figures, in which:
Figure 1 is a schematic diagram showing a known alarm network that uses two-way signaling to communicate between an alarm device and a remote alarm receiving center;
Figure 2 is a schematic diagram showing a prior art alarm device comprising a roaming SIM;
Figure 3 is a schematic diagram showing another prior art alarm device comprising an eUICC;
Figure 4 is a schematic diagram showing an eUICC within an alarm device, and an alarm network for communicating between the alarm device and a remote alarm receiving center, according to a first embodiment of the present invention;
Figure 5 is a schematic diagram showing
Ri?nn Ln/zznz/E/YiAi the components of the eUICC and the alarm device shown in Figure 4 in greater detail;
Figure 6 is a schematic diagram showing the components of the alarm network shown in Figure 4 in greater detail;
Figure 7 is a flow chart showing the process by which connectivity of the eUICC is maintained in the event of an interruption in the active MNO network, according to the first embodiment;
Figure 8 is a flowchart showing the process by which the connectivity of the eUICC in Figure 7 is tested in greater detail;
Figure 9 is a flow chart showing the process by which the backup process of Figure 7 is carried out in greater detail, according to the first embodiment;
Figure 10 is a flow chart showing the process by which the backup cancellation process of Figure 7 is carried out in greater detail, according to the first embodiment;
Figure 11A is a schematic diagram showing an eUICC included within an alarm device, before an optional profile has been selected, according to a second embodiment of the present invention;
Figure 11B is a schematic diagram showing
Ri?nn Ln/zznz/E/YiAi the eUICC of Figure 11A, after having selected an optional profile, according to the second embodiment of the present invention;
Figure 12Ά is a schematic diagram showing an eUICC included within an alarm device, wherein the eUICC comprises profiles associated with mobile virtual network operators having agreements with mobile network operators, before a profile has been selected optional, according to a third embodiment of the present invention;
Figure 12B is a schematic diagram showing the eUICC of Figure 12A after having selected an optional profile, according to the third embodiment of the present invention;
Figure 13 is a schematic diagram showing national and roaming profiles that may be included within an eUICC, according to a fourth embodiment of the present invention;
Figure 14 is a flow chart showing the process by which eUICC connectivity is maintained in the event of an interruption in the active MNO network where the national and roaming profiles are available, according to the fourth embodiment;
Figure 15 is an alternative schematic diagram showing the process by which the κπηη Ln/zznz/E/YiAi connectivity of the eUICC is tested in Figure 8;
Figure 16 is a flowchart showing the Internet address lookup connectivity test of Figure 15 in greater detail;
Figure 17 is a schematic diagram of the eUICC state machine while performing the Internet address lookup connectivity tests of Figures 15 and 16 and initiating the backup and backup cancellation processes;
Figure 18 is a flow chart showing the steps taken during the backup and backup cancellation processes of Figures 9 and 10 in greater detail;
Figure 19 is a flow chart showing the process for synchronizing the applet and the platform and activating the location cancellation request, according to a further embodiment; and Figure 20 is a schematic diagram showing examples of SIMs that are compatible with embodiments of the present invention.
Detailed description of the invention
Embodiments of the present invention relate to an improved self-contained and resilient SIM card that provides an improved method of dealing with interruptions or connectivity problems in MNO networks, for example due to frequent network updates or failures.
Ri?nn Ln/zznz/E/YiAi on the network. As a result of the improvement of the resilient and autonomous SIM card, the interruption of communications that use mobile networks as the transmission path is drastically reduced. This, in turn, has positive consequences on the signaling of emergency response systems, resulting in faster and more responsive alerts to emergency services.
An eUICC according to a first embodiment of the present invention will now be described with reference to Figures 4 to 6, followed by the processes involved with reference to Figures 7 to 10.
Figure 4 shows an alarm network 400 that provides a communication channel between an alarm device 402 and a remote alarm receiving center 404. The alarm device 402 emits and transmits an alarm signal to the alarm receiving center 404. through the alarm network 400. The alarm receiving center 404 then takes the appropriate action, which could include, for example, informing the person responsible for the premises or informing the police.
The alarm device 402 comprises an eUICC 410 that stores account and communication details to enable a radio module (not shown) within the alarm device 402 to operate on the mobile telecommunications network. Therefore, the alarm device 402 can be connected to one or more MNO networks 412. As
Ri?nn Ln/zznz/E/YiAi example, MNO X and MNO Y are shown in Figure 4 as providers of the available MNO 412 networks.
The alarm network 400 provides a radio communications path between the alarm device 402 and the alarm receiving center 404. Initially a radio communications link is provided between the alarm device 402 and an MNO network 412. The radio communications link can be provided by Long Term Evolution (LTE), which is a 4G, GSM communication standard using 3G or 2G, Code Division Multiple Access (CDMA) networks. its acronym in English) that uses 3G or 2G, or a 5G network. A secure fixed line path is provided between the MNO network 412 and an MNO server 414 via Internet 416, and also between the MNO server 414 and a wireless communications network 418. Finally, the wireless communications network 418 has a radio communications link with the alarm reception center 404. In the present embodiment, the secure fixed line is provided by one or more leased lines or virtual private network (VPN) tunnels. ), and the wireless communications network 418 is provided, for example, by BT or Virgin Media. In some embodiments, the alarm network 400 may provide multiple communications paths, including radio communications paths and wire communications paths, between the alarm device 402 and the alarm receiving center 404.
Ri?nn ίη/ζζηζ/Ε/γίΛΐ
The components of the alarm device 402 and the eUICC 410 are shown in more detail in Figure 5. The alarm device 402 comprises a radio module 406, which is arranged to transmit and receive on the radio network (for example, 5G /4G/3G/2G). A radio antenna 408 is connected to the radio module 406 and arranged to operate on the radio network frequency. The alarm device 402 further comprises a microcontroller 403, connected to the radio module 406, which has a memory (not shown) that includes a flash memory and a non-volatile memory. The microcontroller 403 processes the data for transmission and the data received by the radio module 406 through the radio antenna 408. The microcontroller 403 controls the radio module 406 in connection with such transmission and reception of data. The alarm device 402 in some other embodiments may also include an input interface (not shown).
The eUICC 410 comprises a processor 434 having a secure memory 436. A set of profiles is maintained in the secure memory 436, where each profile is associated with a different MNO network. To make the eUICC resilient, each profile is associated with MNOs that operate independent networks. There are many points within an MNO network where connectivity issues could arise. Using MNO networks that are configured independently provides the advantage of reducing the likelihood of experiencing connectivity issues on both.
Ri?nn ίη/ζζηζ/Ε/γίΛΐ MNO networks at the same time is low, and this allows the eUICC to be more resilient. For example, independent MNO networks may use different radio poles and antennas. To further improve resilience, each profile can be associated with an MNO that operates a core network that is independent of the core networks operated by the MNOs associated with the other profiles. For example, in a 4G LTE network, the evolved packet core (EPC) represents the core of the LTE network. The EPC consists of multiple nodes, including the National Subscriber Server (HSS), which is used to store subscriber information, current location, SIM card details and authentication keys. Each of the MNOs associated with the profiles is associated with a separate EPC on the LTE network, so an outage to an MNO using a first EPC can be avoided by switching to an MNO using a different second EPC. MNOs may have roaming agreements in place with other MNOs where the roaming agreement may be a direct roaming relationship or an indirect roaming relationship through a GPRS roaming exchange (GRX). As an example, MNO Independent MNO networks (for example, MNO independent and independent interconnections in these centers.
Different MNOs may operate the same platform but on different instances, including segregation of physical infrastructure (e.g. Ericsson DCP, Jasper). For example, it would not be acceptable for the two networks to share the same physical hardware, even though they use different virtual machines. Since the chosen MNOs operate independent networks and either independent platforms or different instances of the same platform, an outage in one MNO's network can be avoided by switching to another MNO, which operates a different independent network.
The eUICC 410 of the present modality comprises two profiles: (i) an operational profile, which is associated with MNO Y; and (ii) a boot profile, which is associated with MNO which means that the eUICC 410 is connected to the MNO Y network.
In some embodiments, the profile set may comprise more than two profiles, allowing the eUICC to connect to more than two MNO networks. Such embodiments are described later in the present description with reference to Figures 11A, 11B, 12A, 12B and 13.
A small utility program that includes an algorithm, referred to herein as applet 438, is maintained in secure memory 436 (also referred to herein as secure traversal domain) and can be executed on processor 434. Applet 438 is responsible for to test the connectivity of the MNO Y network. In the event that the applet 438 identifies a connectivity interruption in the MNO network Y, the applet initiates a backup process, which requires the eUICC 410 to switch from the operational profile 440, which is associated with the MNO network Y, to the boot profile 442, which is associated with the MNO network X. This restores the connectivity of the eUICC 410 to the alarm network 400. After a predetermined time interval of starting the backup process, the applet 438 initiates a backup cancellation process, which allows the eUICC 410 to cancel the backup mechanism, thereby changing the eUICC 410 from the boot profile 442 to the operational profile 440. Once the change has been made, the eUICC 410 can reconnect to the MNO Y network through operational profile 440. The switching logic that allows the eUICC to switch between the operating profile and the boot profile is installed in the eUICC. Boot profile 442 is installed at the eUICC manufacturing point and can be changed to associate with a different MNO via an Over-the-Air (OTA) update (see
Ri?nn Ln/zznz/E/YiAi below description about OTA updates). The processes carried out by applet 438 are described in more detail below with reference to Figures 7 to 10.
The applet 438 can be configured over the air (OTA), so that the eUICC 410 can be provided with updated MNO profiles and credentials, as well as configuration settings. Each MNO profile resides in a secure area within the secure traversal domain in the eUICC SIM and therefore, to configure the OTA applet 438 in this manner, the applet 438 itself resides in the secure traversal domain in the eUICC 410 and provides a secure connection to the SIM card. The 438 applet itself can also be installed and updated via OTA. Since both the applet and the switching logic reside in the eUICC, the eUICC can be adapted to any device. The applet works within the necessary 3GPP/ETSI/GSMA standards and has been developed using a SIM application toolkit.
The elements of the alarm network 400 that allow OTA updates to be performed are shown in Figure 6. A manufacturer and supplier of a hosted platform 444 of the eUICC 410 is in radio communication with the eUICC 410 that is installed within of the alarm device 402, using one of the available MNO networks 412. Operators of
Rfrnn ίη/ζζηζ/Ε/γίΛΐ available mobile networks 446 are in communication with the manufacturer and the provider of the hosted platform 444. The manufacturer and the provider of the hosted platform 444 allow the eUICC 410 to be configured remotely with information from the operators of the mobile network 446. The available mobile network operators 446 and the manufacturer and provider of the hosted platform 444 are in collective communication with a machine-to-machine (M2M) management system 448 that allows the alarm device 402 to be configured and managed remotely.
The manufacturer and provider of the hosted platform 444 comprise a Subscription Manager Data Preparation (SM-DP) element 450 and a Subscription Manager Secure Routing (SM-SR) element 452. The SM-DP 450 and the SM-SR 452 are two key network elements used by available mobile network operators 446 to remotely manage the eUICC 410. In the present embodiment, the available mobile network operators 446 comprise MNO X 454 and MNO Y 456, which use the SM-DP 450 to securely encrypt their operator profiles for OTA installation within the eUICC 410. -DP 450 sends the encrypted profiles securely to the SM-SR 452. Subsequently, the SM-SR 452 receives and then securely delivers the encrypted profiles to the eUICC 410 via radio communication. The eUICC 410 receives and installs the profiles, and once the profiles are installed, the SM-SR remotely manages the eUICC 410.
In other words, the SM-DP 450 is responsible for securely packaging and managing the installation of the MNO profiles on the eUICC 410 and effectively secures the communications link between the eUICC 410 and SM-DP 450 for delivery. of MNO profiles. The SM-SR 452 is responsible for ensuring secure transport of commands to the eUICC 410 and managing the status of profiles on the eUICC 410 to load, enable, disable, and delete profiles on the eUICC 410 as necessary. The SM-SR 452 also comprises a configuration area (not shown) that is created specifically for the eUICC 410 applet 438. The configuration area allows OTA updates to be performed from the SM-SR 452 even when the applet 438 resides in a secure cross-sectional area of the eUICC 410. Alternatively, OTA updates can be performed through the SIM OTA platform. In most current systems, the OTA server cannot access the eUICC cross-sectional area and would not be able to make changes to the applet in the eUICC, so some modification to the OTA server would be necessary. To address this, the eUICC 410 may use one profile, for example the operational profile or the boot profile, or alternatively a different profile, for example a maintenance profile. The OTA server requires modification only once, then the profile selected to address this issue (operational profile, boot profile, or maintenance profile) allows changes to be made to applet 438 because access to the eUICC secure cross-domain 410 is allowed.
The processes carried out by the subprogram 438 will now be described with reference to Figures 7 to 10. In the present embodiment, the operational profile 440 is currently active, which means that the eUICC 410 is connected to the MNO network Y. The Subprogram 438 carries out its processes in three key stages. First, at step 700, applet 438 tests the connectivity of the MNO network Y and identifies whether there is an outage. In the event that applet 438 identifies a complete disruption of connectivity in the MNO Y network, applet 438, at step 900, initiates a backup process. The backup process requires the eUICC 410 to switch from operating profile 440, which is associated with the MNO network Y, to the boot profile 442, which is associated with the MNO network X. The connectivity of the eUICC 410 in the alarm network 400 is therefore reset using the MNO X network. Next, in step 1000, applet 438 initiates a backup cancellation process after a predetermined time interval. The backup cancellation process allows the eUICC 410 to cancel the backup mechanism, thereby changing the eUICC 410 from the boot profile 442 to the operating profile 440. Once the change has been made, the eUICC 410 can reconnect with the MNO network AND through profile
Ri?nn Ln/zznz/E/YiAi operational 440.
As noted above, applet 438 is responsible for testing the connectivity of the MNO network Y. As part of step 700, applet 438 first tests, in step 7 02, the connectivity of the MNO network Y a predetermined number of times. Subprogram 438 then checks, at step 704, whether the connectivity tests have been successful. If the tests have been successful, subprogram 438 returns to continue testing, in step 702, the connectivity of the MNO network Y. However, if the tests have not been successful, applet 438 proceeds to verify, at step 706, whether there has been a complete interruption of connectivity in the MNO network Y. If from the verification, applet 438 determines that there has been a complete disruption of connectivity on the MNO Y network, applet 438 continues with process step 900 to initiate the backup process. However, if applet 438 determines that there has not been a complete disruption of connectivity in the MNO network Y, applet 438 returns to continue testing, at step 702, the connectivity of the MNO network Y.
In the present embodiment, applet 438 uses the Internet address lookup test to test the connectivity of the eUICC to the MNO Y network, as shown in Figure 8. An Internet address lookup test determines whether the device alarm network 402 in which the eUICC 410 is installed can communicate with a server through the alarm network 400. It does this by sending a data packet to the server and waiting for a data packet in response. In cases where network communication is successfully established, the Internet address lookup test also determines the connection latency (the time it takes for the Internet address lookup (data packet) to return to the device 402) between the alarm device 402 and the server. In the present embodiment, applet 438 executes a series of Internet address lookups to different servers in the alarm network 400, namely server X, server Y, and server Z (not shown). The servers are independent and geographically dispersed.
Applet 438 begins the Internet address lookup test by sending, in step 802, an Internet address lookup or doing an Internet address lookup to server A response to the Internet address lookup has been received from the X server. Applet 438 begins verifying a response immediately after sending the Internet address lookup to the X server. In the event that a response to the Internet address lookup is received from server constantly after doing the address lookup on the Internet, this results in a connectivity latency that indicates normal operation and connectivity with server X and MNO network Y. If a response to the Internet address lookup is not received from server Internet to server Y. Applet 438 then checks, in step 808, whether a response to the Internet address lookup has been received from server Y. In the event that an Internet address lookup response is received from server Y, applet 438 returns to restart the Internet address lookup test by performing the Internet address lookup to server X again, at step 802. . If a response to the Internet address lookup is not received from server Y within a configurable predetermined time period, for example 4 seconds, then applet 438 continues to step 810, where applet 438 sends an address lookup on Internet to server Z. Applet 438 then checks, in step 812, whether a response to the Internet address lookup has been received from server Z. In the event that an Internet address lookup response is received from server Z, applet 438 returns to restart the Internet address lookup test by performing the Internet address lookup to server X again, at step 802. . If a web address lookup response is not received from server Z within a configurable predetermined time period, for example 4 seconds, this means that three consecutive web address lookup tests (specifically, a addresses on the Internet) have not been successful. After a first unsuccessful Internet address lookup sequence, applet 438 repeats steps 802 to 812 another two times to repeat the mode of the Internet address lookup sequence twice. If at the end of the third and final address lookup sequence no Internet address lookup response is received to server Z, then the applet determines whether there is a complete connectivity outage at step 706 as shown in figure 7.
At step 706, subprogram 438 determines whether there has been a complete loss of connectivity or a connectivity interruption between the eUICC 410 and the MNO network Y, based on the occurrence of three consecutive failed Internet address lookup sequences. If subprogram 438 determines that there has not been a complete loss of connectivity to the MNO network Y, then subprogram 438 returns to retest, at step 702, the connectivity of the eUICC 410 to the MNO network Y. However, If applet 438 determines that a complete loss of connectivity has occurred, then applet 438 continues to step 900 to initiate the backup process.
The backup process initiated by the applet 438 in step 900 will now be described in more detail with reference to Figure 9. First, the applet 438 sends, in step 902, a request to the processor 434 of the eUICC 410 to change from operating profile 440, which is associated with the MNO network Y, to the boot profile 442, which is associated with the MNO network X. Simultaneously, applet 438 sends, in step 904, a request to processor 434 of eUICC 410 to start a timer.
As part of the backup process, it is necessary to update the network configuration of the radio module 406 of the alarm device 402 so that the radio module 406 connects to the MNO X network. Therefore, the eUICC sends, in step 906, an update command to radio module 406 to initiate a network configuration update, as part of the backup process. This allows the radio module's network configuration to be updated with respect to the MNO X network.
The applet then sends, at step 912, a
Ri?nn ίη/ζζηζ/Ε/γίΛΐ command to processor 434 of the eUICC 410 to check the timer against a predetermined threshold. This check is carried out at step 914, and if the timer has reached a predetermined threshold, then the process continues to step 1000 to start the backup cancellation process and therefore reconnect to the MNO network. AND. However, if the result of the check, at step 914, indicates that the timer has not reached the predetermined threshold, then the process returns to where the applet 438 again sends, at step 912, a command to the processor 434 to which checks the timer against the default threshold.
The backup cancellation process initiated by the subprogram 438 in step 1000 will now be described in more detail with reference to Figure 10. As described above, the backup cancellation process allows the eUICC 410 to cancel the backup mechanism, thereby changing the eUICC 410 from the boot profile 442 back to the operating profile 440. Subprogram 438 determines, in step 1002, a time interval (a time period) in which the backup cancellation process is started. For example, applet 438 receives an input from device 402 after a predetermined period of time, for example every 30 seconds, to indicate that the predetermined period of time has passed, so that each time applet 438 receives an input, applet 438 adds one to a counter. Once the counter reaches a predetermined number of counts, for example three counts, applet 438 initiates the backup cancellation process. It is likely that there will be a plurality of alarm devices 402 in the alarm network 400 such that an eUICC in each of the alarm devices 402 is capable of carrying out the processes described herein. If several eUICCs are switched back to the operating profile at the same time, this can cause a so-called signaling storm and therefore overload the MNO Y network. This could cause further MNO outages. Applet 438 has a built-in mechanism to extend the switching of the eUICCs 410 back to the operating profile 440 over time after the backup cancellation process is initiated. This solves a technical problem because it avoids a signaling storm with the MNO associated with the operational profile 440, specifically, the MNO Y in the present embodiment. The time interval can be determined, for example, using the last digit of the eUICC IMEI, ICCID, EID or MISDEN codes. The time interval may be determined in other ways, for example, by randomizing the time period after which the change from boot profile 442 to operating profile 440 will occur.
Once the time interval has been determined
Ri?nn Ln/zznz/E/YiAi at which backup cancellation is to begin, subprogram 438 sends, in step 1004, a command to processor 434 to determine whether the time interval has been reached. Subprogram 438 proceeds to check the current time against the corresponding time interval in step 1006. Specifically, if the time interval has not been reached, then the process returns for applet 438 to resend, in step 1004, a command to processor 434 to check whether the time interval has been reached. If the time interval has been reached, the process continues and the applet 438 sends, in step 1008, a request to the processor 434 of the eUICC 410 to switch from the boot profile 442, which is associated with the MNO network X, to the operational profile 440, which is associated with the MNO network Y. Applet 438 then checks, in step 1010, whether connectivity has been established using the MNO network Y. If connectivity to the MNO network returns, at step 1012, to the beginning of step 900 to go through the backup process. However, if connectivity to the MNO network Y is established in step 1010, the eUICC 410 successfully connects to the MNO network Y and the process ends.
It should be noted that although the present embodiment uses time as a reference point to initiate the backup cancellation process, specifically, a period of time between two points is measured and compared to a threshold to determine a time interval in which backup cancellation is started - other means are also viable. For example, the applet may count the number of interactions or event triggers between the eUICC and the device and/or network, and initiate the backup cancellation process after a predetermined count of such interactions or events has been reached. Alternatively, the applet can use any combination of time, interactions, and events to determine the point at which the backup cancellation process begins.
In the embodiments described above with reference to Figures 4 to 10, the eUICC 410 comprises two profiles: (i) the operational profile 440, which is associated with MNO Y; and (ii) the boot profile 442, which is associated with MNO will be described with reference to figures 11A, 11B, 12A, 12B and 13.
An eUICC 1110 according to a second embodiment of the present invention is shown in Figures 11A and 11B. The
Ri?nn Ln/zznz/E/YiAi second modality is similar to the first modality and, as such, the following description will focus on the differences between the modalities.
The eUICC 1110 is installed inside an alarm device 1102 providing an M2M solution. The alarm device 1102 is part of an alarm network as described above with reference to Figure 4, where the alarm network provides a communications channel between an alarm device 1102 and a remote alarm receiving center. The alarm device 1102 and the eUICC 1110 comprise the features of the alarm device 402 and the eUICC 410, respectively, shown in Figure 5, although these features are not shown in Figure 11A. The difference between the first and the second modalities lies in the profiles that are stored in the eUICC 1110. The eUICC 1110 comprises four profiles: (i) a boot profile 1142a, which is associated with the MNO 1; (ii) an operational profile 1140a, which is associated with MNO 2; (iii) an optional profile A 1143a, which is associated with MNO 3; and (iv) an optional profile B 1144a, which is associated with MNO 4. It should be noted that the profiles included within eUICC 1110 are national profiles associated with MNOs, which provide connectivity in the country in which their own physical network operates. . Therefore, national profiles are associated with MNOs that provide connectivity in the same country in which the eUICC 1110 operates and
Ri?nn ίη/ζζηζ/Ε/γίΛΐ the alarm device. The eUICC may also include traveling profiles in addition to the national profiles and this is described in more detail with respect to the fourth modality and with reference to Figure 13.
Using the national profiles shown in Figure 11A, the eUICC 1110 can be connected to the MNO network 1, the MNO network 2, the MNO network 3 or the MNO network 4. In the present embodiment, as shown in the figure 11A, the operating profile 1140a is currently active, which means that the eUICC 1110 is connected to the MNO network 2. The MNO network that provides network connectivity, specifically, that is associated with the operational profile, can be selected from an alarm server in the alarm network. Optional Profile A 1143a and Optional Profile B 1144a would be presented as options on the server that allow control of which MNO should provide network connectivity.
The applet (not shown in Figures 11A or 11B) within the eUICC 1110 can carry out the processes detailed above with reference to the flow charts of Figures 7 to 10. That is, the applet tests the connectivity of the MNO network 2 that is associated with the operating profile 1140a (step 700, Figure 7) and, in case of loss of connectivity with the MNO network 2, the applet initiates an alternative process to restore the connectivity with the MNO network 1 that is associated with the boot profile 1142a κπηη Ln/zznz/E/YiAi (step 900, Figure 7). After a predetermined time interval, the applet initiates a backup cancellation process and reconnects to the MNO network 2 (step 1000, Figure 7).
Figure 11B shows the profiles within the eUICC 1110 after the optional profile A 1143a has been selected so that the MNO 3 can provide network connectivity. As such, the operational profile 1140b of Figure 11B is now associated with the MNO network 3. The boot profile 1142b remains associated with the MNO network 1. The optional profile A 1143a is now associated with the MNO network 2 and the profile is You can switch back to the MNO 2 network if desired. The optional profile B 1144a remains associated with the MNO 4 network.
Alternatively, the eUICC 1110 shown in Figures 11A and 11B could be installed in a consumer device such as a smartphone. In this case, the device user can select the MNO network that provides network connectivity, specifically, that is associated with the operating profile. Through an input device such as a touch screen, the consumer device may present optional profile A 1143a and optional profile B 1144a as options to allow the user to actively choose which MNO will provide network connectivity. After switching to one of the optional profiles 1143a, 1144a, the user has the option to switch back to the MNO 2 network if desired by selecting the optional profile A 1143b.
An eUICC 1210 according to a third embodiment of the present invention is shown in Figures 12A and 12B. The third modality is similar to the second modality and, as such, the following description will focus on the differences between the second and third modalities.
eUICC 1210 comprises profiles associated with mobile virtual network operators (MVNOs), where each MVNO has an agreement with an MNO so that it can use the MNO's network infrastructure to provide services to its customers.
Accordingly, the eUICC 1210 comprises a boot profile 1242a, which is associated with MVNO XI. MVNO XI has an agreement with MNO X to use MNO X's network infrastructure.
The eUICC 1210 further comprises an operational profile 1240a, which is associated with MVNO Y1. MVNO Y1 has an agreement with MNO Y to use MNO Y's network infrastructure.
The eUICC 1210 comprises two additional profiles 1241a, 1243a. The first additional profile 1241a is associated with MVNO X2, which has an agreement with MNO with MNO Y.
Using the profiles, the eUICC 1210 can be connected
Rfrnn ίη/ζζηζ/Ε/γίΛΐ to MNO network X or MNO network Y, through one of the associated MVNOs respectively. In the present embodiment, as shown in Figure 12A, the operating profile 1240a is currently active and therefore the eUICC 1210 is connected to the MNO network Y. The MNO providing network connectivity can be selected at the server (not shown) in the case the device 1202 is an M2M device, or can be selected by a user through an input device (not shown ) such as a touch screen in the case that the device 1202 is a consumer device. The operational profile and boot profile must be associated with different MNOs for the backup and unbackup processes to be effective. As boot profile 1242a is associated with MNO The first additional profile 1241a associated with MVNO X2 is currently not available for selection.
The applet (not shown in Figures 12A or 12B) within the eUICC 1210 can carry out the processes detailed above with reference to the flow charts of Figures 7 to 10.
Figure 12B shows the profiles within the eUICC 2110 after optional profile A has been selected
Ri?nn Ln/zznz/E/YiAi
1243a such that MNO Y can provide network connectivity through MVNO Y2. As such, operational profile 1240b of Figure 12B is now associated with MVNO Y2. The server (if device 1202 is an M2M device) or the user (if device 1202 is a consumer device) can switch back to MVNO Y1 using optional profile B 1243b as needed. Boot profile 1242b remains associated with the MVNO XI. However, the boot profile 1242b is OTA configurable and can therefore be changed to be associated with a different profile but still on a different MNO than the operational profile, for example, using the additional profile 1241b associated with MVNO X2.
The profiles provided within an eUICC according to a fourth embodiment of the present invention are shown in Figure 13. The fourth embodiment is similar to the second embodiment and, as such, the following description will focus on the differences between the second and the fourth modalities. The second modality eUICC comprises national profiles associated with MNOs, each of which provides connectivity in the country in which it operates its own physical network. Therefore, the national profiles are associated with mobile network operators that provide connectivity in the same country in which the eUICC and the alarm device operate.
On the contrary, in addition to the national profiles, the eUICC of this modality includes roaming profiles. Roaming profiles allow an eUICC operating in a first country to access the networks of MNOs operating in a second country. Therefore, the eUICC has access to the roaming network in addition to access to the national network. As such, the eUICC has access, through roaming profiles, to the available networks with which the MNO providing the profile has roaming agreements.
As shown in Figure 13, the eUICC comprises four national profiles 1302, 1304, 1306, 1308 and four roaming profiles 1310, 1312, 1314, 1316. Each of the profiles is associated with a different MNO. Specifically, the national profiles are associated with MNO 1, MNO 2, MNO 3 and MNO 4, respectively, which operate in the same country as the eUICC. The roaming profiles are associated with MNO A, MNO B, MNO C and MNO D, respectively, that operate in a country other than the eUICC. For national profiles, national operational profile 1304 is associated with MNO 2 and national boot profile 1302 is associated with MNO 1.
As with the previous embodiments, one of the optional national profiles 1306, 1308, each of which is associated with different MNOs to the current operational and boot profiles, may be selected to function as the national operational profile.
Rfrnn ίη/ζζηζ/Ε/γίΛΐ
The process by which the national profiles and roaming profiles are used by the applet of this modality is shown in Figure 14. First, the applet tests, in step 1402, the connectivity of the MNO network associated with the national operational profile 1304, specifically, the MNO 2. The applet then checks, in step 1404, whether the connectivity tests have been successful. If the connectivity tests have been successful, the process returns to continue testing the connectivity, at step 1402. If the connectivity tests have not been successful, the process continues checking, at step 1406, whether there has been a complete loss of connectivity. connectivity to the MNO network 2. If the applet determines that there has not been a loss of connectivity, then the process returns to continue testing connectivity, at step 1402. However, if it is determined that there has been a loss of connectivity to the MNO 2 network, the device notifies the eUICC accordingly. The applet allows the eUICC a predetermined amount of time after this notification to search for available roaming operators to find connectivity. In one embodiment, the applet allows sufficient time for the SIM/device to move through several networks, typically three networks. If the eUICC does not find connectivity through a roaming operator within the predetermined amount of time, the applet activates the processes
Backup ri?nn Ln/zznz/E/YiAi and backup cancellation.
Once notified of a loss of connectivity, the eUICC or the device checks, in step 1408, whether a roaming operator is available. If the eUICC determines that a roaming operator is available, then the eUICC switches, in step 1414, to the available roaming operator. Once connected to the available roaming operator, the applet tests, also in step 1414, the connectivity of the MNO associated with the roaming operator. The connectivity test performed by the subprogram is analogous to that performed in steps 1402, 1404 and 1406.
The roaming process effectively allows the eUICC to move between available roaming operators to find connectivity. If no roaming operators are available, then the applet continues to initiate the backup and backup cancellation processes according to steps 1410 and 1412, in the same manner as the embodiments described above.
This process allows the eUICC to switch between MNOs and therefore has the potential to quickly identify a roaming operator that can provide connectivity when connectivity is initially lost. Advantageously, this provides a first layer of resilience.
The connectivity tests performed by the applet will now be described in more detail with reference to Figures 15 to 17. Figure 15 shows a schematic version of the process of using an Internet address search as a connectivity test and subsequently initiating a backing as described above with reference to Figures 7 to 9. In particular, the diagram shows a series of Internet address lookup tests, where each Internet address lookup test involves doing the Internet address lookup to server X, server Y, and server Z, and the results of each test. A first Internet address lookup test 1502 results in an Internet address lookup response being received from all three servers. However, as a result of a second Internet address lookup test 1504, no Internet address lookup responses are received. The connectivity test continues with a third Internet address lookup test 1506 and subsequently a fourth Internet address lookup test 1508, both of which result in no Internet address lookup responses being received from either. servers. Three consecutive failed Internet address lookup tests lead to the backup process being activated in step 902 and the backup timer being started in step 904.
The Internet address lookup connectivity test is shown in more detail in Figure 16. The Internet address lookup connectivity test begins at step 1602, where the operational profile is active. At step 1604, the applet (not shown) sets a counter to zero. Next, the applet performs Internet address lookup to the X server at step 1606. If the applet receives an Internet address lookup response from server which represents the number of seconds between repeated Internet address lookup attempts to the X server. However, if the applet does not receive an Internet address lookup response from server If the applet receives an Internet address lookup response from server Y, the process enters a waiting state in which the applet waits, at step 1612, for [X] seconds before performing the address lookup again. on the Internet to the X server, in step 1606, and thus restart the Internet address search sequence. However, if the applet does not receive an Internet address lookup response from server Y, then the process continues and the applet proceeds to
Rfrnn ίη/ζζηζ/Ε/γίΛΐ perform Internet address lookup to server Z, at step 1614. Finally, if the applet receives an Internet address lookup response from server Z, the process enters a state of waits in which the applet waits, at step 1616, for [X] seconds before doing the Internet address lookup again to server X, at step 1606, and thus restarting the Internet address lookup sequence. However, if the applet does not receive an Internet address lookup response from server Z, then the process continues by adding 1 to the counter in step 1618.
The applet then checks, in step 1620, the value of the counter to determine whether or not there have been [N] or more failed Internet address lookup sequences, where [N] is a predetermined value representing the number of sequences. failed Internet address lookup required for the applet to initiate a backup process. Specifically, the applet checks whether the counter is greater than or equal to N. If the result of this check is negative, then the applet waits, at step 1622, for [Z] seconds, where [Z] is a predetermined number, representing the number of seconds to wait before restarting the search sequence. addresses on the Internet. After [Z] seconds, the applet restarts the Internet address lookup sequence κπηη Ln/zznz/E/YiAi by doing the Internet address lookup to the X server in step 1606. If the result of the check at step 1620 is positive, specifically, if the counter is greater than or equal to N, then the applet starts the backup process at step 1624 and simultaneously starts the timer at step 1626. backup cancellation. Steps 1624 and 1626 can be seen as analogous to steps 902 and 904, respectively, of Figure 9. Therefore, the subsequent steps of Figures 9 and 10 also apply in the present embodiment. It should be noted that in the process flow in Figure 16, the eUICC operational profile is currently active. The Internet address lookup connectivity test could also be carried out analogously if the boot profile is active instead of the operational profile, for example, after a backup process has already been performed and the change to boot profile. The process flow in this case is described below with reference to Figure 18.
The applet maintains a state machine while performing Internet address lookup connectivity tests and initiating the backup and backup cancel processes, as illustrated in Figure 17. The different states of the state machine ensure that the eUICC stay connected. It should be noted that the states and process flows shown in Figure 17 are for illustrative purposes only. At the beginning of the process, the eUICC uses an operational profile (profile 1), which is associated with a first MNO network, MNO 1. In state 1702, the applet registers profile 1 as good as it provides connectivity to the eUICC . The applet tests connectivity to the MNO 1 network by doing Internet address lookup to servers X, Y, Z to form an Internet address lookup sequence. In state 1704, the applet records a positive web address lookup sequence, specifically, web address lookup responses have been received from all three servers. The applet then repeats the Internet address lookup test. In state 1706, the applet records a negative web address lookup sequence, specifically, no web address lookup responses have been received from the servers. The applet repeats the Internet address lookup test two more times and in state 1708 and state 1710 records a second and third negative Internet address lookup sequence, respectively. The applet confirms that there have been three consecutive negative Internet address lookup sequences and initiates a backup process as a result. The backup process changes the profile that is currently active from the operational profile to the boot profile (profile 2), which is associated with a second MNO network, MNO 2. Simultaneously, a backup cancellation timer is started.
Once the backup process is performed, the applet can be in one of two states: a first state in which profile 2 does not provide connectivity to the eUICC, in state 1712; and a second state in which profile 2 provides connectivity to the eUICC, in state 1722. Starting with state 1712 (no connectivity), the applet continues testing connectivity to the MNO 2 network through profile 2 using Internet address lookup tests as described above. In states 1714, 1716, and 1718, the applet records three consecutive negative Internet address lookup sequences. The applet confirms that there have been three consecutive negative Internet address lookup sequences and initiates a backup cancellation process as a result. The backup cancellation process changes the currently active profile from the boot profile (profile 2) back to the operational profile (profile 1), which is associated with MNO network 1. Once the backup cancellation process has been performed, the applet can be in one of two states: a first state in which profile 1 does not provide connectivity to the eUICC, in state 1720; and a second state in which profile 1 provides connectivity to the eUICC, in the state
1702. In case no connectivity is recorded in state 1720, the applet continues testing connectivity to the MNO 1 network through profile 1 using Internet address lookup tests and states 1706, 1708, 1710 are repeated like this. In the event that connectivity to MNO network 1 through profile 1 is recorded in state 1702, the applet continues testing connectivity to MNO network 1 through profile 1 using Internet address lookup tests and repeat state 1704.
Returning to state 1722, profile 2 provides connectivity to the eUICC once the backup process has been carried out. The applet continues testing connectivity to the MNO 2 network through profile 2 using the Internet address lookup test as described above. In state 1724, the applet registers a positive Internet address lookup sequence. At this stage, the applet is checking whether the backup abort timer has expired. If it has expired, in state 1732, the applet registers the expiration of the backup cancel timer and starts a backup cancel process. Alternatively, if the backup cancellation timer has not yet expired, then the applet repeats the Internet address lookup test. In states 1726, 1728, and 1730, the applet records three Internet address lookup sequences
Ri?nn ίη/ζζηζ/Ε/γίΛΐ consecutive negatives. The applet confirms that there have been three consecutive negative Internet address lookup sequences and initiates a backup cancellation process as a result.
The backup cancel process changes the profile that is currently active from the boot profile (profile 2) to the operational profile (profile 1), which is associated with the MNO network 1. After the backup cancel process is performed, the applet can be in one of two states: a first state in which profile 1 does not provide connectivity to the eUICC, in state 1734; and a second state in which profile 1 provides connectivity to the eUICC, in state 1702. In case no connectivity is recorded in state 1734, the applet continues testing connectivity to the MNO 1 network through profile 1 using Internet address lookup tests and states 1706, 1708, 1710 are repeated like this. In the event that connectivity to MNO network 1 through profile 1 is recorded in state 1702, the applet continues testing connectivity to MNO network 1 through profile 1 using Internet address lookup tests and repeat state 1704.
Turning to Figure 18, the steps taken by the applet during the backup and backup cancellation processes are shown in greater detail. The process flow
Ri?nn Ln/zznz/E/YiAi Figure 18 follows the process flow of Figure 16 from a positive verification result at step 1618. Specifically, if the verification result at step 1618 (figure 16) is positive, specifically, if the counter is greater than or equal to N, then the process continues by checking, at step 1802 (Figure 18), the loaded profile indicator that indicates which profile is currently active in the eUICC. If the loaded profile indicator indicates that the operating profile is currently active, then the process proceeds to activate in step 1804, the backup process and simultaneously starts, in step 1806, the backup cancellation timer. Steps 1804 and 1806 shown in Figure 18 are therefore analogous to steps 1624 and 1626 shown in Figure 16.
After activating the backup process, the applet is disconnected, in step 1808, from the operating profile and subsequently connected, in step 1810, to the boot profile. After the applet has connected to the boot profile, the applet updates, in step 1812, the loaded profile flag to the boot profile and loads the context configuration of the boot profile.
The backup cancellation timer, which is started, in step 1806, by the applet, is set for a predetermined amount of time, specifically, [H] hours. The applet thus waits, at step 1816, for [H] hours and once the time limit has been reached, the applet activates, at step 1816, the backup cancellation process. Once the backup cancellation process has been activated, the applet cancels, in step 1818, the backup cancellation timer. The backup cancellation process itself involves the applet disconnecting, in step 1820, from the boot profile and connecting, in step 1822, to the operating profile. Next, the applet starts, in step 1824, a SIM activation timer for a predetermined amount of time, specifically, [T] minutes. The SIM activation timer ensures that the eUICC waits a period of time after the backup cancel timer has expired and the backup cancel process is completed. This staggers the movement of the eUICCs back to the operational profile (e.g., by random delay periods) and the corresponding MNO network to avoid a signaling storm as mentioned above in other embodiments. At step 1826, the applet checks whether [T] minutes have been reached and then updates, at step 1812, the loaded profile flag to the operating profile and loads, also at step 1812, the context settings of the operating profile.
In step 1802, if the loaded profile indicator
Ri?nn ίη/ζζηζ/Ε/γίΛΐ indicates that the boot profile is currently active in the eUICC, then the process continues directly to the activation, at step 1816, of the backup cancellation process and switches to the operational profile.
Table 1
Ri?nn Ln/zznz/E/YiAi
<td></td><td></td><td colspan="2">Profile type</td>
<td>Time</td><td>Description</td><td>National</td><td>Itinerant</td>
<td>N</td><td>Number of failed Internet address lookup sequence attempts</td><td>N</td><td>N</td>
<td>x</td><td>The number of seconds between Internet address lookup attempts</td><td>X(a) Seconds</td><td>X(b) Seconds</td>
<td>Z</td><td>Number of seconds before Internet address search is restored</td><td>Z(a) Seconds</td><td>Z(b) Seconds</td>
<td>h</td><td>Number of hours to count down before backup cancellation is activated</td><td>h</td><td>h</td>
<td>T</td><td>Number of minutes the SIM needs to wait after the backup cancel time expires and backup cancel is activated</td><td>See Trigger Timer Table</td><td>See Trigger Timer Table</td>
<td colspan="4"></td>
<td></td><td>Total expected time before the backup process is activated</td><td>[3]-[5] minutes</td><td>[6] to[15] minutes</td>
Table 1 summarizes the times used by the applet in the Internet address lookup connectivity tests and the backup and unbackup processes for domestic and roaming profiles. First, [N] 1902 is the number of failed Internet address lookup sequence attempts required for the applet to trigger a backup process. As shown in Figure 16, the applet checks whether the counter is greater than or equal to [N] to confirm whether the backup process should be activated (see step 1618).
Second, [X] 1904 is the number of seconds the applet waits between Internet address lookup attempts during the connectivity test. As shown in Figure 16, after doing the Internet address lookup to each of the servers X, Y, and Z, the applet waits [X] seconds before continuing to do the Internet address lookup to the X server ( see steps 1608, 1612 and 1616).
Third, [Z] 1906 is the number of seconds that the applet waits before restarting an Internet address lookup sequence. As shown in FIG. before doing the Internet address lookup to the X server again to restart the lookup sequence.
Ri?nn Ln/zznz/E/YiAi addresses on the Internet.
Fourth, [H]1908 is the number of hours the applet waits before triggering the backup cancellation process. As shown in Figure 18, the backup cancellation timer is started in step 1806 and the applet waits [H] hours in step 1814, using the timer to control the amount of time that has passed, before activating the backup cancellation process in step 1816.
Fifth, [T] 1910 is the number of minutes the applet waits after the backup cancel timer expires and performs the backup cancel process. As shown in Figure 18, the SIM activation timer is used, in step 1824, to monitor [T]. This staggers the movement of the eUICCs back to the operational profile and corresponding MNO network to avoid a signaling storm.
Finally, the total expected time before the applet triggers the backup process is approximately [3] to [5] minutes when using only domestic profiles and [6] to [15] minutes when using roaming profiles. in addition to national profiles. In the case where roaming profiles are used in the eUICC, the applet does not interfere with the roaming process between MNOs and ensures that sufficient time is provided to allow the eUICC to disconnect from one MNO and connect to another MNO, before activating any backup process. There are usually three or four MNOs in a given country. Therefore, the applet allows a configurable time between [3] and [15] minutes for the device and the eUICC to pass through the roaming MNOs. The time allowed varies depending on the critical nature of the service being delivered using the eUICC.
As described above, moving the eUICC back to the operational profile over time after a backup abort activation helps prevent a signaling storm and further outages. In some embodiments, the applet uses a random number, for example, this could be a digit taken from the ICCID (integrated circuit card identifier), IMEI (international mobile equipment identity) of the host device, MISDIN (access directory number). international mobile station subscriber) assigned by the network to the device, etc., and an associated time slot. The applet prevents the backup cancellation process from taking place until the specific time interval associated with the random number is reached, specifically, it delays the backup cancellation process. As an example, if the ICCID number ended in 2, the allocated time interval would be 12 to 18 minutes after the initial backup abort timer had expired.
Therefore, the eUICC applet would wait 12 minutes after the initial backup abort timer had expired before performing the backup abort process.
Rfrnn ίη/ζζηζ/Ε/γίΛΐ
Table 2
<td colspan="2">Activation timer table</td>
<td>Last digit of ICCID number</td><td>Time interval for one hour</td>
<td> 0</td><td>0 to 6/o. minute</td>
<td> 1</td><td>6/o. at 12/o. minute</td>
<td> 2</td><td>12/o. to 18/o. minute</td>
<td> 3</td><td>18/o. at 24/o. minute</td>
<td> 4</td><td>24/o. at 30/o. minute</td>
<td> 5</td><td>30/o. at 36/o. minute</td>
<td> 6</td><td>36/o. at 42/o. minute</td>
<td> 7</td><td>42/o. at 48/o. minute</td>
<td> 8</td><td>48/o. at 54/o. minute</td>
<td> 9</td><td>54/o. at 60/o. minute</td>
Table 2 shows an example of determining other possible time intervals using the last digit of the ICCID number. For example, if the last digit of the ICCID number is 4 (see Table 2), the assigned time interval is the 24th minute. at 30/o. (see table 2) after expiration of the backup cancel timer. In other embodiments, a random digit of the ICCID number could be used instead.
Applet elements can be configured through context settings. These context settings provide the applet with information about the environment, how it is operating, and how it should perform tests and trigger events. The applet can also be configured depending on whether a national profile or a roaming profile is being used. Table 3 summarizes the configurable elements of the applet.
Rfrnn ίη/ζζηζ/Ε/γίΛΐ
Table 3
<td>Profile type</td><td>Total time to complete the entire Internet address lookup sequence</td><td>Number of address search sequences on the Internet</td><td>Internet address lookup server</td><td>Time between address searches on the Internet</td><td>Number of failed Internet address lookups per server</td><td>latency limit</td>
<td rowspan="3">Roaming profile</td><td rowspan="3">[6]to[15] minutes</td><td>x</td><td>[xx.xx.xx.xx]</td><td rowspan="3">[60 seconds</td><td rowspan="3">[3] Internet address searches</td><td rowspan="3">[500] milliseconds</td>
<td>AND</td><td>[yy.yy.yy.yy]</td>
<td>Z</td><td>[zz.zz.zz.zz]</td>
<td rowspan="3">National profile</td><td rowspan="3">[3] to [5] minutes</td><td>x</td><td>[xx.xx.xx.xx]</td><td rowspan="3">[20] seconds</td><td rowspan="3">[3] Internet address searches</td><td rowspan="3">[500] milliseconds</td>
<td>AND</td><td>[yy.yy.yy.yy]</td>
<td>Z</td><td>[zz.zz.zz.zz]</td>
The total time 2102 allowed by the applet to complete the Internet address lookup sequence is configurable. In this modality, it is established between 6 and 15 minutes for traveling profiles and between 3 and 5 minutes for national profiles. Other configurable elements of the applet include the web address lookup sequence number 2104 and the Internet addresses of the corresponding web address lookup servers 2106 for the connectivity web address lookup test. These elements are especially important in the event that mobile network operators blacklist IP addresses that prevent Internet address lookup from a particular server, or in the event that a server is disabled. , and the server that is deactivated must be replaced by an alternative. Additionally, the Internet address lookup test may suffer from latency if the server is located in Europe and the eUICC is being used in Australia, accidentally triggering a backup process.
Additionally, parameters used by the applet can be configured, such as the time between Internet address lookup sequences 2108 (equivalent to [X]), the number of failed Internet address lookup sequence attempts before activating the backup process 2110 (equivalent to [N]) and Internet address lookup latency 2112, specifically, the time it takes for Internet address lookup to return, before it is considered a failed Internet address search.
Applet and platform synchronization provides real-time information directly from the applet to the MNO platform. If the MNO platform κπηη Ln/zznz/E/YiAi does not receive Internet address lookups from the applet, then it can automate a request to the MNO network Visitor Location Register (VLR) to reestablish the connection to the eUICC. This request is referred to herein as a Placement Cancellation Request. Figure 19 illustrates the process of synchronizing the applet and platform and triggering the location cancellation request.
First, the applet does an Internet address lookup, in step 2202, to a server on the MNO platform. The server then records, in step 2204, the received Internet address lookup, and subsequently, the server starts, in step 2206, timer A. The applet then does an Internet address lookup, at step 2208, on the server again and the server records this second Internet address lookup, at step 2210. Once the second address lookup has been recorded on Internet, the server starts timer B, in step 2216, while simultaneously stopping timer A, in step 2214. The server stores, in step 2214, the time of timer A in a database associated with the server. Therefore, the stored time of timer A represents the amount of time between the first and second Internet address lookups recorded by the server. Next, the applet does an Internet address lookup, at step 2218, on the server for the third time and the server records this third Internet address lookup at step 2220. Once the third address lookup has been recorded addresses on the Internet, the server restarts timer A, in step 2222, while simultaneously stopping timer B, in step 2224. The server stores, in step 2226, the time of timer B in a database associated with the server. Therefore, the stored time of timer B represents the amount of time between the second and third Internet address lookups that the server records.
The process continues by checking the server, at step 2228, for the time between Internet address lookups against a predetermined time threshold. Specifically, the server checks the stored time of timer A for the time between the second and third Internet address lookups, and the stored time of timer B for the time between the second and third Internet address lookups. If timer A or timer B is less than the predetermined threshold, this check is passed and the process returns to do the Internet address lookup again to the server, in step 2208, from the second Internet address lookup, specifically, without server intervention. However, if the time between Internet address lookups fails this check, indicating that the Internet address lookups are not reaching the server in time (specifically, that the time between Internet address lookups is greater than the default time threshold), then the server checks, in step 2230, whether timer Y has been started.
If it has not already been started, the server starts timer Y in step 2232. If timer Y has been started, then the server checks, in step 2234, whether timer Y is greater than or equal to 20 minutes. If the result of this check is negative, specifically, if timer Y is less than 20 minutes, then the process returns to redo the Internet address lookup to the server, at step 2208, from the second address lookup on Internet. If the verification result in step 2234 is positive, specifically, if timer Y is greater than or equal to 20 minutes, then the server calls, in step 2236, an API on the MNO platform to send a request for location cancellation to the VLR of the MNO network to reestablish the connection to the eUICC.
The location cancellation request is a request for the MNO network to remove the eUICC from the MNO network.
MNO. This forces the eUICC to restart the connection with the MNO, effectively reestablishing the connection to the eUICC. The server then waits, at step 2238, for an incoming Internet address lookup, then restarts the process from step 2202. The time the server waits at this step is configurable, but is typically about 10 minutes. If the server does not receive an incoming Internet address lookup, this may provide an indication that the device and/or eUICC have been turned off or are not functioning properly.
The connection to the eUICC could be reestablished in this way before the backup process is started. For example, the eUICC may be experiencing connectivity issues while in the operational profile. Simply resetting the connection based on the location cancellation request may be enough to fix any connectivity issues. Alternatively, the connection could be restarted after the backup process has started. For example, after the eUICC has changed from the operational profile to the boot profile, it may remain offline due to a problem with the MNO network, such as network congestion, or because the radio module needs to be rebooted. Reestablishing the connection to the eUICC after the backup process has been started may have the effect of resolving any network issues and/or resetting the module
Ri?nn Ln/zznz/E/YiAi radio on the device that was stuck or failed, allowing the eUICC to reconnect.
Additionally, applet and platform synchronization can provide the network operations center with a warning about a large-scale problem on the network, which they can then begin to resolve with the MNO before the backup process is initiated. This also allows customers to be automatically alerted of an impending network change to their eUICCs.
It should be noted that although Internet address lookup is used as a connectivity test in embodiments of the present invention, alternative connectivity tests can be used in any embodiment of the present invention to identify a potential problem. The applet may use a number of alternative end-to-end connectivity and service testing methods to test connectivity. Alternative testing methods include, at least, but not exclusively, one or more of the following: Address Resolution Protocol (ARP) Internet address lookup; data delivery, for example if the SIM can deliver [10] kb of data to a server; speed tests; and/or test one or more network layers, for example layer 1: physical; layer 2: data link layer; layer 3 - network layer; layer 4 - transport layer; layer 5 session layer; layer 6 - presentation layer; layer 7 93 application.
It should also be noted that, although the embodiments of the present invention are described with respect to the implementation of the applet on an eUICC, the applet can be installed on any compatible SIM (specifically, any UICC) and any format of SIM card. Examples of supported SIMs are shown in Figure 20. In particular, any of the following SIM types can be used: 2FF Mini SIM (25mm x 15mm x 0.76mm) 2302; Micro SIM 3FF (15mm x 12mm x 0.76mm) 23 04; 4FF Nano SIM (12.3mm x 8.8mm x 0.67mm) 2306; and MFF2 solder SIM 2308, as shown in figure 20.
Additionally, it should be noted that the applet is capable of working with SIM cards manufactured by any SIM provider, including but not limited to Gemalto, Thales, Giesecke & Devrient, Idemia (Morpho adn Oberthur Technologies), Bluefish, Datang and DZCARD .
It should be further noted that, although embodiments of the present invention are described with respect to the installation of the eUICC within an alarm device, the eUICC can be installed in any device that requires radio network connectivity. For example, eUICC can be installed on smartphones, tablets, dongles, routers, GPS tracking devices, M2M devices, IoT devices, vehicles or devices.
Ri?nn Ln/zznz/E/YiAi for telehealth and telecare.
It should also be noted that embodiments of the present invention can be used with various MNO platforms, including but not limited to Cisco Jasper, Ericsson DCP, Vodafone GDSP, Nokia Wing, Huawei loT Connection Management Platform and Orange Platform.
Features of one modality can also be used in other modalities, either as an addition to that modality or as a replacement for it.
It is stated that in relation to this date, the best method known to the applicant to put the aforementioned invention into practice is the one that is clear from the present description of the invention.
Contents3
20 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20
35 members in 20 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 20026639 | United Kingdom | – | |
| 202002663 | United Kingdom | A | |
| 20157590 | United Kingdom | – | |
| 202015759 | United Kingdom | A | |
| 2021050371 | United Kingdom | W |
Members35
| Document | Office | Kind | |
|---|---|---|---|
| GB202002663D0 | United Kingdom | D0 | |
| GB202015759D0 | United Kingdom | D0 | |
| GB2589724A | United Kingdom | A | |
| CA3170526A1 | Canada | A1 | |
| WO2021170974A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2021170974A3 | World Intellectual Property Organization (WIPO) | A3 | |
| GB2589724B | United Kingdom | B | |
| EP4035311A2 | European Patent Office (EPO) | A2 | |
| AU2021227420A1 | Australia | A1 | |
| IL295642A | Israel | A | |
| BR112022016826A2 | Brazil | A2 | |
| MX2022010049AThis record | Mexico | A | |
| MX2022010049AThis record | Mexico | A | |
| CN115777207A | China | A | |
| JP2023515277A | Japan | A | |
| US2023121282A1 | United States of America | A1 | |
| KR20230061291A | Republic of Korea | A | |
| US11882614B2 | United States of America | B2 | |
| US2024121849A1 | United States of America | A1 | |
| US2025133621A1 | United States of America | A1 | |
| EP4579625A1 | European Patent Office (EPO) | A1 | |
| EP4035311B1 | European Patent Office (EPO) | B1 | |
| JP7725507B2 | Japan | B2 | |
| AU2021227420B2 | Australia | B2 | |
| NZ791198A | New Zealand | A | |
| IL295642B1 | Israel | B1 | |
| DK4035311T3 | Denmark | T3 | |
| FI4035311T3 | Finland | T3 | |
| US12471169B2 | United States of America | B2 | |
| LT4035311T | Lithuania | T | |
| PT4035311T | Portugal | T | |
| PL4035311T3 | Poland | T3 | |
| HRP20251552T1 | Croatia | T1 | |
| ES3054888T3 | Spain | T3 | |
| US12557164B2 | United States of America | B2 |
Numbers
- Publication
- 2022010049
- Application
- 10049
Titles2
- Spanish
- MÉTODO PARA OPERAR UNA TARJETA DE CIRCUITO INTEGRADO UNIVERSAL (UICC) AUTÓNOMA Y RESILIENTE Y DISPOSITIVO CORRESPONDIENTE
- English
- METHOD OF OPERATING A RESILIENT, AUTONOMOUS UNIVERSAL INTEGRATED CIRCUIT (UICC) CARD AND CORRESPONDING DEVICE
Classification
- CPC, 12
- G08B25/004
- H04W76/19
- H04W8/183
- G08B25/10
- H04M11/04
- G08B25/08
- H04W4/60
- H04L41/0809
- H04W48/18
- H04W88/06
- H04W76/50
- H04W88/08
- IPC, 3
- H04W76 19
- H04W4 60
- H04W36 14