ES3053684T3 - Communication management between a terminal and a network server - Google Patents
Communication management between a terminal and a network serverInfo
- Publication number
- ES3053684T3 ES3053684T3 ES18827201T ES18827201T ES3053684T3 ES 3053684 T3 ES3053684 T3 ES 3053684T3 ES 18827201 T ES18827201 T ES 18827201T ES 18827201 T ES18827201 T ES 18827201T ES 3053684 T3 ES3053684 T3 ES 3053684T3
- Authority
- ES
- Spain
- Prior art keywords
- terminal
- management
- transmission device
- message
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/03—Protecting confidentiality, e.g. by encryption
- H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
- H04W12/088—Access security using filters or firewalls
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/69—Identity-dependent
- H04W12/71—Hardware identity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/16—Gateway arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/08—Access point devices
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
La invención se refiere a un método de gestión implementado por un dispositivo de transmisión (RP) capaz de comunicarse mediante un primer enlace inalámbrico (L1) con un dispositivo de puerta de enlace (EP1) que forma un nodo de una red de telecomunicaciones y está configurado para comunicarse con al menos un servidor de dicha red a través de dicho dispositivo. Según la invención, el método es adecuado para establecer una sesión de comunicación segura con un terminal (C) incluido en una lista de terminales para los que dicho dispositivo de transmisión (RP) ha obtenido datos de gestión, para recibir, mediante el primer enlace de comunicación (L1), una solicitud para finalizar la gestión de dicho terminal y para eliminarlo de dicha lista tras la recepción de dicha solicitud. La invención también se refiere a un dispositivo de transmisión (RP) que implementa el método de gestión. (Traducción automática con Google Translate, sin valor legal)
Description
[0001] DESCRIPCIÓN
[0002] Gestión de comunicación entre un terminal y un servidor de una red
[0003] La invención se sitúa en el campo de las telecomunicaciones.
[0004] La invención hace referencia más particularmente a un sistema de comunicación en el que un terminal se comunica con un servidor de aplicaciones capaz de proporcionar servicios de aplicación a este terminal a través de una red de telecomunicaciones, y más particularmente a un servidor de esta red. No existe ninguna limitación en cuanto a la naturaleza del terminal o la naturaleza de los servicios de aplicación proporcionados. El terminal puede ser un terminal fijo o móvil, como por ejemplo un contador de electricidad, un sensor, etc. El servidor de aplicaciones puede ser explotado por cualquier proveedor de servicios, como un proveedor de electricidad o de agua, por ejemplo.
[0005] La invención también tiene una aplicación privilegiada pero no restrictiva en el contexto de la Internet de los objetos, y en particular de las arquitecturas o redes extendidas de tipo LoRaWAN<™>(por "Long Range Wide Area Network"). Como es sabido, el protocolo LoRaWAN<™>, actualmente en proceso de normalización, permite una radiocomunicación de baja velocidad (inferior a 50 kbit/s) y bajo consumo energético entre objetos que se comunican mediante la tecnología LoRa<™>(de "Long Range") y están conectados a Internet a través de una red de comunicación.
[0006] En una arquitectura LoRaWAN<™>, cada terminal se comunica con un servidor de aplicaciones a través de una red de telecomunicaciones. Más concretamente, los datos emitidos por cada terminal a través de un enlace de radio son recibidos por una serie de puertas de enlace o estaciones base, que los retransmiten a un servidor de red a través de una conexión por cable o celular. Este servidor de red filtra los mensajes recibidos de los terminales (y, en particular, comprueba su origen e integridad) y los retransmite a los servidores de aplicaciones correspondientes.
[0007] A pesar de tratarse de una tecnología de radio optimizada para el largo alcance, muchos terminales diseñados para utilizar la tecnología LoRa<™>no consiguen comunicarse con las puertas de enlace de la red Lora<™>deseadas porque las señales emitidas por estos terminales no llegan a las puertas de enlace. Esto ocurre sobre todo cuando estos terminales están colocados por ejemplo en zonas como sótanos, bodegas, edificios de chapa, etc.
[0008] Como es sabido, se pueden añadir puertas de enlace adicionales a la red LoRa<™>para permitir que estos terminales se comuniquen con esta red.
[0009] Sin embargo, estas puertas de enlace son caras. Además, necesitan una conexión a la red eléctrica y una conexión móvil o por cable.
[0010] Asimismo, no siempre se implementan o se implementan tarde.
[0011] En esta situación, que puede ser temporal o permanente, los terminales no pueden comunicarse con los servidores de la red LoRa<™>.
[0012] Uno de los objetivos de la invención es remediar insuficiencias/inconvenientes del estado de la técnica y/o aportar mejoras.
[0013] A tal efecto, la invención se refiere a un procedimiento y dispositivo de gestión tal como se define en las reivindicaciones independientes.
[0014] Otros aspectos de la presente invención están definidos por las reivindicaciones dependientes.
[0015] En la primera fase, un terminal se ubica fuera del área de cobertura de cualquier equipo puerta de enlace.
[0016] Además, aunque esté configurado para comunicarse a través de un equipo puerta de enlace de red con un servidor de aplicaciones en esta red, no puede comunicarse con ningún equipo puerta de enlace.
[0017] El dispositivo de transmisión, también denominado dispositivo repetidor, se sitúa en la zona de cobertura de radio del terminal para permitir que este terminal acceda a la red y se comunique con un servidor de aplicaciones asociado al terminal a través del servidor de red. Gracias a este dispositivo de transmisión, un terminal configurado para conectarse a un servidor de aplicaciones de red pero incapaz de acceder directamente a un equipo puerta de enlace de red a través de un enlace de radio, puede comunicarse con el servidor de red y en consecuencia con un servidor de aplicaciones a través del servidor de red.
[0018] La red es, por ejemplo, una red LoRa<™>.
[0019] El dispositivo de transmisión se comporta como un terminal en relación con la red. De este modo, se comunica con un equipo puerta de enlace a través de señales de radio, por ejemplo, señales de radio de largo alcance. El equipo puerta de enlace transmite informaciones desde el dispositivo de transmisión a un servidor en la red. Este servidor es normalmente un servidor, generalmente denominado “servidor de red”, capaz de retransmitir estas informaciones a un servidor de gestión asociado al dispositivo de transmisión. A la inversa, la información procedente del servidor de gestión y destinada al dispositivo de transmisión se transmite a este dispositivo a través del servidor o servidores de red y a través del equipo puerta de enlace.
[0020] El servidor de gestión es un servidor de aplicaciones asociado al dispositivo de transmisión.
[0021] Más específicamente, el terminal envía una solicitud de conexión a un servidor de aplicaciones en la red. La solicitud de conexión es interceptada por el dispositivo de transmisión que contiene datos de gestión que representan un derecho de gestión del terminal. El dispositivo de transmisión y el terminal establecen entonces mutuamente una sesión de comunicación segura. Para establecer esta sesión de comunicación segura entre el dispositivo de transmisión y el terminal, el dispositivo de transmisión utiliza al menos parte de los datos de gestión. El establecimiento de la sesión segura permite, por una parte, el envío de mensajes por el terminal y la recepción de estos mensajes por el dispositivo de transmisión, y por otra parte el envío de mensajes por el dispositivo de transmisión y la recepción de estos mensajes por el terminal.
[0022] Una vez establecida la sesión segura, los mensajes emitidos por el terminal a través del segundo enlace de comunicación y recibidos por el dispositivo de transmisión son retransmitidos por el dispositivo de transmisión a través del primer enlace de comunicación a un servidor en la red. Recíprocamente, los mensajes emitidos a través del primer enlace de comunicación por un servidor de red al terminal son recibidos por el dispositivo de transmisión y retransmitidos por este último a través del segundo enlace de comunicación y más particularmente a través de la sesión de comunicación segura al terminal.
[0023] En esta primera fase, cuando el terminal se encuentra fuera de la cobertura radio de cualquier equipo puerta de enlace de la red, el dispositivo de transmisión establece, utilizando datos de gestión, la sesión de comunicación del mismo modo que lo habría hecho un servidor de red si le hubiera llegado la solicitud de conexión. Además, para el establecimiento de la sesión de comunicación, el dispositivo de transmisión desempeña el papel de servidor de red.
[0024] Según la presente invención, la red es una red de tipo LoRa<™,>el establecimiento de la sesión por el dispositivo de transmisión permite a éste responder al terminal en un tiempo correspondiente a las expectativas del terminal. En efecto, según el protocolo LoRaWAN<™>, el terminal está configurado para recibir una respuesta a una solicitud de conexión dentro de un tiempo predefinido. Pasado ese tiempo, ya no espera una respuesta.
[0025] Una vez establecida la sesión, el dispositivo de transmisión actúa como relé para este terminal para el que ha recibido derechos de gestión.
[0026] Así, gracias al dispositivo de transmisión, un terminal situado fuera del área de cobertura radio de cualquier equipo puerta de enlace de la red puede comunicarse con al menos un servidor de esta red.
[0027] En una segunda fase, el terminal se ubica en el área de cobertura de un equipo puerta de enlace de la red mientras permanece posicionado en el área de cobertura del dispositivo de transmisión. Este cambio de situación se debe, por ejemplo, a la instalación de un equipo puerta de enlace adicional o al desplazamiento del terminal.
[0028] Este equipo puerta de enlace es capaz de transmitir a al menos un servidor de red las señales emitidas por el terminal y de transmitir al terminal las señales transmitidas por un servidor de red, destinado al terminal.
[0029] Para evitar que los mensajes intercambiados entre el terminal y un servidor de red pasen por un lado a través del dispositivo de transmisión y por otro lado a través del equipo puerta de enlace recientemente accesible, se envía un mensaje de solicitud final de gestión de terminal al dispositivo de transmisión. Este mensaje señala al dispositivo de transmisión que ya no debe asegurar la gestión de este terminal y, en consecuencia, eliminar este terminal de la lista de terminales que gestiona.
[0030] Al eliminar el terminal de la lista de terminales gestionadas por el dispositivo de transmisión, los mensajes emitidos por el terminal ya no son retransmitidos por el dispositivo de transmisión. Recíprocamente, los mensajes destinados al terminal y recibidos por el dispositivo de transmisión ya no son transmitidos por este último al terminal.
[0031] Así, sólo el equipo puerta de enlace recientemente accesible sirve como relé para estos mensajes.
[0032] El procedimiento permite así pasar de una gestión por el dispositivo de transmisión a una gestión a través del equipo puerta de enlace nuevamente accesible, sin pasar por el dispositivo de transmisión y sin necesidad de modificaciones a nivel del terminal. Este procedimiento es transparente para el terminal.
[0033] Ventajosamente, los enlaces de comunicaciones entre los distintos servidores y entre un servidor de red y un equipo puerta de enlace son enlaces convencionales por cable o celulares.
[0034] Sin embargo, no hay restricciones en cuanto al tipo de enlace.
[0035] Según la presente invención, la conexión entre el dispositivo de transmisión y el terminal es una conexión de radio de largo alcance según la tecnología LoRa<™>. Así, los terminales configurados para cumplir con el protocolo LoRaWAN<™>pueden acceder a una red LoRa<™>a servidores de aplicaciones a través del dispositivo de transmisión sin necesidad de adaptarlos.
[0036] Sin embargo, el enlace entre el dispositivo de transmisión y el terminal puede ser un enlace de radio con características diferentes, por ejemplo, un enlace de radio de corto alcance.
[0037] Según una realización particular del procedimiento de gestión, tras la recepción de dicha solicitud, el dispositivo de transmisión envía a dicho terminal una solicitud de emisión por dicho terminal de una segunda solicitud de conexión.
[0038] La recepción de este mensaje de solicitud de fin de gestión por parte del dispositivo de transmisión desencadena el envío de un mensaje por parte de este dispositivo de transmisión al terminal. Este mensaje indica al terminal que debe volver a emitir una nueva solicitud de conexión.
[0039] Durante la emisión de la nueva solicitud de conexión por el terminal, el dispositivo de transmisión no procesa esta solicitud. La solicitud de conexión sólo la toma en cuenta el equipo puerta de enlace nuevamente accesible por el terminal.
[0040] La emisión de una nueva solicitud de conexión permite establecer una nueva sesión de comunicación entre el terminal y un servidor de red. Esto permite reforzar la seguridad del sistema.
[0041] Según una característica particular del procedimiento de gestión, el establecimiento de la sesión segura comprende una generación de una clave de sesión compartida entre el dispositivo de transmisión y el terminal, generándose dicha clave a partir de al menos una parte de los datos de gestión.
[0042] Utilizando los datos de gestión obtenidos por el dispositivo de transmisión, el dispositivo de transmisión genera la clave de sesión como si fuera generada por un servidor de red.
[0043] En una realización particular, los datos de gestión comprenden una clave principal conocida por la red, y más precisamente por al menos un servidor de la red, y transmitida al dispositivo de transmisión. La clave de sesión se genera a partir de la clave principal. Esta clave de sesión también la genera el terminal que también tiene la clave principal.
[0044] Así, al obtener la clave principal, el dispositivo de transmisión puede actuar como servidor de red para generar la clave de sesión.
[0045] Según una realización particular del procedimiento de gestión, dicha solicitud de fin de gestión se recibe a través de dicho equipo puerta de enlace y a través de dicho servidor de red.
[0046] La transmisión de la solicitud de fin de gestión a través de dicho equipo puerta de enlace y a través de dicho servidor de red es sencilla de implementar.
[0047] De este modo, el dispositivo de transmisión recibe la solicitud de gestión a través de un enlace de radio. Por lo tanto, no es necesario prever otros medios de comunicación, como por ejemplo una conexión por cable, una conexión 4G, etc., entre el dispositivo de transmisión y el servidor de gestión.
[0048] Según una realización particular del procedimiento de gestión, la solicitud de finalización de la gestión se transmite al dispositivo de transmisión a través de una sesión de comunicación segura establecida entre el dispositivo de transmisión y un servidor de dicha red.
[0049] Esto permite una transmisión segura de la solicitud de fin de gestión.
[0050] Según una realización particular del procedimiento de gestión, la solicitud de emisión se emite en respuesta a un mensaje emitido por dicho terminal a través de la sesión de comunicación establecida entre el terminal y el dispositivo de transmisión.
[0051] En esta implementación, el terminal inicia el intercambio de mensajes y los servidores de red sólo pueden comunicarse con el terminal en respuesta a un mensaje emitido por este. Esto evita que los terminales tengan que
estar en constante escucha, lo cual consume energía. El dispositivo de transmisión es visto por la red como un terminal.
[0052] Según una realización particular del procedimiento de gestión, el terminal es eliminado de la lista después de recibir un acuse de recibo emitido por el terminal en respuesta a la solicitud de emisión.
[0053] Así, el dispositivo de transmisión asegura la gestión de este terminal hasta tener confirmación de que su solicitud de reconexión se ha recibido por el terminal. Esto permite evitar una pérdida de mensajes de datos.
[0054] Según una realización particular del procedimiento de gestión, la recepción de la solicitud de fin de gestión es seguida por el envío de una solicitud de tipo Nuevo Canal definida en el estándar LoRaWAN<™>.
[0055] El envío de este mensaje permite transmitir parámetros de configuración al terminal. Estos parámetros de configuración permiten al terminal adaptar la configuración de las señales de radio emitidas o recibidas por el terminal.
[0056] El envío de este mensaje permite, en particular, invalidar canales de frecuencia específicos del dispositivo de transmisión y no utilizados por los equipos puerta de enlace de la red.
[0057] Según una realización particular del procedimiento de gestión, dichos mensajes de datos emitidos por el terminal comprenden datos cifrados o firmados con la clave de sesión compartida por el terminal y el dispositivo de transmisión.
[0058] Según una realización particular del procedimiento de gestión, el procedimiento comprende una etapa de transmisión a un servidor de red de datos relativos a la clave de sesión generada.
[0059] La transmisión de estos datos permite al servidor de red tener la clave de sesión. Esto permite así al servidor de red descifrar y/o verificar la firma de los mensajes emitidos por el terminal y retransmitidos por el dispositivo de transmisión. De manera recíproca, esto permite al servidor de red cifrar y/o firmar los mensajes emitidos al terminal. Así, gracias a los datos relativos a la clave de sesión transmitidos, el terminal y el servidor de red se comportan como si el dispositivo de transmisión no estuviera retransmitiendo los mensajes.
[0060] Es como si la clave de sesión hubiera sido generada por un servidor de red.
[0061] Los datos relacionados con la clave de sesión son la clave de sesión.
[0062] Alternativamente, los datos relacionados con la clave de sesión son datos utilizados por el dispositivo de transmisión para generar la clave de sesión. Permiten que el servidor de red genere la misma clave de sesión. Los datos transmitidos también pueden incluir datos generados por el dispositivo de transmisión al establecer la sesión, por ejemplo una dirección del terminal.
[0063] De manera más general, los datos transmitidos son datos generados por el dispositivo de transmisión o recibidos desde el terminal durante la fase de establecimiento de la sesión.
[0064] La invención también se refiere a un producto de programa informático, no cubierto por la presente invención, que comprende instrucciones para implementar un procedimiento de gestión, no cubierto por la presente invención, como se ha descrito anteriormente, cuando este programa es ejecutado por un procesador.
[0065] La invención se refiere así a un software o programa, no cubierto por la presente invención, susceptible de ser ejecutado por un ordenador o por un procesador de datos, comprendiendo este software/programa instrucciones para controlar la ejecución de las etapas de un procedimiento de gestión. Estas instrucciones están destinadas a ser almacenadas en una memoria de un dispositivo informático, cargadas y, a continuación, ejecutadas por un procesador de este dispositivo informático.
[0066] Este software/programa puede utilizar cualquier lenguaje de programación, y estar en forma de código fuente, código objeto, o código intermedio entre el código fuente y el código objeto, tal como en una forma parcialmente compilada, o en cualquier otra forma deseable.
[0067] El dispositivo informático puede ser implementado por una o varias máquinas distintas físicamente y presenta globalmente la arquitectura de un ordenador, incluidos componentes de una arquitectura de este tipo: memoria(s) de datos, procesador(es), bus de comunicación, interfaz(es) de hardware para la conexión de este dispositivo informático a una red u otro equipo, interfaz(es) de usuario, etc.
[0068] La invención también hace referencia a un soporte de información legible por un procesador de datos, y que comprende instrucciones de un programa tal como el mencionado anteriormente. El soporte de datos puede ser cualquier entidad o dispositivo capaz de almacenar el programa.
[0069] Otras particularidades y ventajas de la presente invención serán evidentes a partir de la siguiente descripción de las formas de realización dadas a modo de ejemplo no restrictivo, con referencia a los dibujos adjuntos, en los que:
[0070] • la figura 1 es un esquema que ilustra un sistema en un primer estado de configuración y de acuerdo con una realización particular de la invención;
[0071] • la figura 2 es un esquema que ilustra el sistema de la figura 1 en un segundo estado de configuración;
[0072] • la figura 3 es un esquema que representa un dispositivo de transmisión capaz de implementar un procedimiento de gestión según una realización de la invención;
[0073] • la figura 4 es un diagrama de flujo que ilustra las diferentes etapas de un procedimiento de gestión según una realización particular de la invención.
[0074] La invención se implementa mediante componentes de software y/o hardware, no cubiertos por la presente invención. Desde esta óptica, el término "módulo" puede corresponder en este documento tanto a un componente de software, un componente de hardware como un conjunto de componentes de hardware y/o software, capaces de implementar una función o un conjunto de funciones, de acuerdo con lo que se describe a continuación para el módulo en cuestión.
[0075] Un componente de software corresponde a uno o más programas de ordenador, uno o más subprogramas de un programa o, de forma más general, a cualquier elemento de un programa o software. Un componente de software de este tipo se almacena en la memoria y, a continuación, se carga y ejecuta por un procesador de datos de una entidad física (terminal, servidor, pasarela, decodificador, enrutador, etc.) y es capaz de acceder a los recursos de hardware de dicha entidad física (memorias, soportes de registro, buses de comunicación, tarjetas electrónicas de entrada/salida, interfaces de usuario, etc.).
[0076] De la misma manera, un componente de hardware es cualquier elemento de un conjunto de hardware. Puede ser un componente de hardware programable o con un procesador integrado para la ejecución de software, por ejemplo, un circuito integrado, una tarjeta inteligente, una tarjeta electrónica para ejecutar firmware, etc.
[0077] La figura 1 y la figura 2 representan un sistema de comunicación SYS según la invención, en una realización particular.
[0078] En el ejemplo considerado, el sistema de comunicación SYS se basa en una red de telecomunicaciones de área amplia que implementa el protocolo LoRaWAN<™>. Como es sabido, el protocolo LoRaWAN<™>es especialmente adecuado en el contexto del Internet de los objetos, ya que permite que varios objetos comunicantes intercambien datos con servidores en Internet.
[0079] No hay ninguna limitación en cuanto a la naturaleza de los objetos comunicantes. Pueden ser diversos terminales, como por ejemplo sensores, actuadores o cualquier otro tipo de objeto. Como es sabido, debido a sus limitaciones de hardware y/o software, dichos objetos no se pueden conectar a través de redes de acceso convencionales como por ejemplo WiFi, celular o por cable a Internet para acceder a los servidores de aplicaciones a los que están conectados: se comunican con estos servidores a través de una red de telecomunicaciones adaptada a sus limitaciones, como por ejemplo LoRaWAN<™>, de acuerdo con una topología en estrella.
[0080] El sistema de comunicación SYS comprende al menos un dispositivo de transmisión RP, al menos un terminal C, al menos un equipo puerta de enlace, un servidor de red SR, un servidor de gestión SG y al menos un servidor de aplicaciones SA.
[0081] El servidor de gestión SG es un servidor de aplicaciones asociado al dispositivo de transmisión RP.
[0082] El sistema de comunicación SYS incluye, por ejemplo, un equipo puerta de enlace EP1.
[0083] No hay limitación en el número de servidores de aplicaciones, el número de dispositivos de transmisión, el número de equipos de pasarela o el número de terminales.
[0084] El servidor de red SR se puede comunicar, por una parte, con el servidor de gestión SG y, por otra parte, con el servidor de aplicaciones SA a través de un enlace LS.
[0085] El enlace LS es un enlace por cable, por ejemplo.
[0086] El enlace LS es preferiblemente seguro.
[0087] Cada equipo puerta de enlace es capaz, por una parte, de comunicarse con uno o más terminales a través de un enlace de radio y, por otra parte, de comunicarse con el servidor de red SR u otros equipos de red a través de un enlace de comunicación L.
[0088] El enlace de comunicación L es, por ejemplo, un enlace por cable o celular.
[0089] No hay restricciones ni en el tipo de enlace LS ni en el tipo de enlace L.
[0090] Como es sabido, el servidor de red SR se encarga de filtrar y controlar la integridad y autenticidad de los mensajes recibidos a través del enlace L antes de transmitirlos a los servidores de aplicaciones correspondientes.
[0091] El servidor de red SR también tiene acceso a una memoria ML que contiene una lista LT de terminales conectados. La lista LT incluye en particular, para cada terminal conectado, un identificador de dicho terminal en asociación con informaciones relativas a una sesión de comunicación establecida para este terminal. Esta información incluye, por ejemplo, un identificador del servidor de aplicaciones con el que está conectado, una o más claves de sesión, una dirección asignada al terminal conectado, etc. Por terminal conectado se entiende aquí un terminal para el que se ha establecido una sesión de comunicación y todavía está en curso.
[0092] Las informaciones contenidas en la lista LT permite al servidor de red SR realizar comprobaciones de integridad antes de transmitir o no un mensaje recibido.
[0093] Por ejemplo, la información almacenada para un terminal conectado se elimina de la lista LT al final de la sesión de comunicación.
[0094] Los datos intercambiados entre los distintos servidores SR, SA y SG de la red se pueden cifrar indiferentemente utilizando claves compartidas o pares de claves privadas-públicas o cualquier otro método de cifrado, o se pueden transmitir en claro. No existe ninguna restricción sobre la forma en que se intercambian estos datos.
[0095] El terminal C es un objeto comunicante.
[0096] Más concretamente, el terminal C se configura para emitir y recibir datos a través de un enlace de radio.
[0097] El terminal C es un contador de agua, por ejemplo.
[0098] El servidor de aplicaciones SA es, por ejemplo, un servidor de un proveedor de agua capaz de procesar los datos enviados por el contador de agua C y de proporcionar un servicio de aplicación. Este servicio de aplicación es, por ejemplo, la preparación de una factura a partir de los datos enviados, y el suministro de esta factura a un usuario asociado con el contador C. También se puede proporcionar al usuario un historial detallado de su consumo en un portal web del proveedor de agua, etc.
[0099] El terminal C se configura para comunicarse con el servidor de aplicaciones SA a través del servidor de red SR, y posiblemente a través de puertas de enlace o estaciones base.
[0100] Esto significa que cuando se instala en un área de cobertura de radio de un equipo puerta de enlace, puede comunicarse con el servidor de aplicaciones SA a través de un enlace de radio entre el terminal y este equipo puerta de enlace, a través de este equipo puerta de enlace, el enlace L, el servidor de red SR y el enlace LS. Para ello, el terminal C incluye una memoria en la que se han almacenado un identificador IdC del terminal C, un identificador IdS del servidor de aplicaciones SA asociado al terminal C y una clave criptográfica principal (o maestra) KPC durante una fase de inicialización previa. La clave principal KPC se almacena, por ejemplo, en una memoria segura del terminal C.
[0101] La clave principal KPC también se almacena en una memoria accesible por el servidor de red R, por ejemplo una memoria segura del servidor de red SR, por ejemplo en asociación con el identificador IdC del terminal C y el identificador IdS del servidor de aplicaciones SA.
[0102] El dispositivo de transmisión RP está configurado para comunicarse con el servidor de gestión SG a través del servidor de red SR y posiblemente a través de puertas de enlace o estaciones base.
[0103] En el ejemplo que se muestra aquí, el dispositivo de transmisión RP está ubicado dentro del área de cobertura de radio del equipo puerta de enlace EP1 y se comunica con el equipo puerta de enlace EP1 a través de un enlace de radio L1.
[0104] El enlace de radio L1 representa un primer enlace de comunicación en el sentido de la invención.
[0105] El dispositivo de transmisión RP se comunica con el servidor de gestión SG a través del enlace de radio L1 entre el dispositivo de transmisión RP y el equipo puerta de enlace EP1, a través del equipo puerta de enlace EP1, el enlace L, el servidor de red SR y el enlace LS.
[0106] El dispositivo de transmisión RP también es capaz de recibir señales de radio emitidas por uno o más terminales para los que ha obtenido derechos de gestión, por ejemplo en forma de una solicitud de gestión como se describe ulteriormente. También es capaz de emitir señales de radio destinadas a este o estos terminales.
[0107] La figura 1 muestra un ejemplo de un primer estado de configuración del sistema SYS.
[0108] En esta figura, el terminal C está ubicado dentro del alcance radio del dispositivo de transmisión RP. Se ubica fuera del alcance radio del equipo puerta de enlace EP1 y no puede comunicarse directamente con este equipo puerta de enlace EP1 ni con otros equipos puerta de enlace en el sistema SYS.
[0109] Las señales de radio emitidas por el terminal C no llegan a un equipo puerta de enlace de la red. Tampoco llegan directamente al servidor de red SR.
[0110] El terminal C se sitúa bajo tierra, por ejemplo, en el sótano de un edificio, en un edificio de chapa, etc.
[0111] Sin embargo, estando el terminal C ubicado dentro del área de cobertura de radio del dispositivo de transmisión RP, el terminal C y el dispositivo de transmisión RP se comunican a través de un enlace de radio L2.
[0112] En la realización descrita, los enlaces de radio L1 y L2 son enlaces según la tecnología de bajo caudal y bajo consumo LoRa<™>. Las señales de radio emitidas y recibidas son señales de bajo caudal (menos de 50 Kbits/s) con un gran alcance (es decir, de tipo Long range).
[0113] Alternativamente, uno o más de los enlaces L1 y L2 son enlaces de radio de diferentes tipos.
[0114] La figura 2 muestra un ejemplo de un segundo estado de configuración del sistema SYS.
[0115] Como se muestra en la figura 2, se ha añadido un equipo puerta de enlace adicional EPY y el terminal C ahora se ubica dentro del alcance de radio del equipo puerta de enlace EPY mientras permanece dentro del alcance del dispositivo de transmisión RP.
[0116] Alternativamente, el equipo puerta de enlace EPY se instaló inicialmente dentro del sistema SYS y el terminal se encuentra ubicado dentro del alcance de este equipo puerta de enlace EPY tras un desplazamiento del terminal C mientras permanece dentro del alcance del dispositivo de transmisión RP.
[0117] Según se ilustra en lafigura 3, el dispositivo de transmisión RP comprende, de manera conocida, en particular una unidad de procesamiento UT equipada con un microprocesador, una memoria de sólo lectura de tipo ROM y una memoria de acceso aleatorio de tipo RAM.
[0118] La memoria de sólo lectura de tipo ROM comprende registros que almacenan un programa informático PG que comprende instrucciones de programa adaptadas para implementar un procedimiento de gestión según una realización de la invención descrita ulteriormente con referencia a la figura 4.
[0119] El dispositivo de transmisión RP también comprende una memoria MP, por ejemplo una memoria segura, en la que se han grabado durante una fase de inicialización previa, por ejemplo durante su instalación, un identificador IdP del dispositivo de transmisión RP, el identificador IdG del servidor de gestión SG asociado al dispositivo de transmisión RP y la clave criptográfica principal (o maestra) KPP. La clave principal KPP es una clave asociada al servidor de gestión SG. Es compartida por el dispositivo de transmisión RP y el servidor de red SR.
[0120] La clave principal KPP también se almacena en una memoria segura del servidor de red SR, por ejemplo en asociación con el identificador IdP del dispositivo de transmisión RP y el identificador IdG del servidor de gestión SG.
[0121] El dispositivo de transmisión RP también comprende un primer módulo de comunicación COM1 y un segundo módulo de comunicación COM2.
[0122] El primer módulo de comunicación COM1 está configurado para recibir y emitir señales de radio emitidas a través del enlace L1, normalmente entre el dispositivo de transmisión y el equipo puerta de enlace EP1.
[0123] El segundo módulo de comunicación COM2 está configurado para recibir y emitir señales de radio emitidas a través del enlace L2, normalmente entre el dispositivo de transmisión RP y el terminal C.
[0124] Los módulos COM1 y COM2 pueden ser opcionalmente uno solo y mismo módulo.
[0125] El dispositivo de transmisión RP también incluye un módulo de autenticación AUT, un módulo de transferencia TRF y un módulo de gestión GST.
[0126] El dispositivo de transmisión RP también contiene una memoria MM en la que se ha grabado previamente una lista TG de terminales gestionados por el dispositivo de transmisión RP. La memoria MM contiene, para cada terminal de la lista TG, un identificador de terminal y datos de gestión asociados. Los datos de gestión representan derechos de gestión en el sentido de la invención.
[0127] A continuación se describirá una primera realización de un procedimiento de gestión implementado en el sistema SYS con referencia a la figura 4.
[0128] En esta realización, se supone que la lista TG contiene al menos un terminal, por ejemplo el terminal C. Más precisamente, la lista TG contiene el identificador IdC del terminal C y los datos de gestión DG.
[0129] Los datos de gestión de DG asociados al terminal C contienen en particular la clave principal KPC asociada al terminal C.
[0130] La lista TG se inicializa, por ejemplo, durante una fase de instalación del dispositivo de transmisión RP. Se puede añadir un terminal a la lista TG enviando un comando emitido por el servidor de gestión SG.
[0131] No existe ninguna limitación en el registro de un nuevo terminal en la lista. El procedimiento de registro debe, sin embargo, ser seguro para evitar ataques a la confidencialidad de los datos intercambiados por los terminales o a la autenticación de los propios terminales por la red.
[0132] Durante una etapa S0, el módulo de autenticación AUT del dispositivo de transmisión RP transmite una solicitud de conexión DA1 al servidor de red SR. El dispositivo de transmisión RP emite la solicitud de conexión DA1 a través del enlace de radio L1. Es retransmitida al servidor de red SR por el equipo puerta de enlace EP1 a través del enlace L.
[0133] La solicitud de conexión DA1 contiene el identificador IdP del dispositivo de transmisión RP, el identificador IdG del servidor de gestión SG con el que el dispositivo de transmisión RP solicita conectarse y un valor aleatorio AL1 generado por el dispositivo de transmisión RP.
[0134] La solicitud de conexión DA1 es, por ejemplo, un mensaje JoinRequest definido en el estándar LoRaWAN<™>. Durante una etapa S2, tras la recepción de la solicitud DA1, el dispositivo de transmisión RP y el servidor de red SR establecen una sesión de comunicación SC1.
[0135] El establecimiento del enlace de comunicación SC1 incluye una etapa de autenticación llevada a cabo, por una parte, por el dispositivo de transmisión RP y, por otra parte, por el servidor de red SR.
[0136] Más concretamente, el servidor de red SR genera un valor aleatorio AL2. Después, genera una clave de sesión KSP aplicando una función matemática predefinida F1 a los siguientes parámetros: la clave principal KPP, el valor aleatorio recibido AL1, el valor aleatorio AL2.
[0137] La generación de una clave de sesión, también denominada clave derivada, a partir de una clave principal (o maestra) es una técnica conocida por los expertos en la técnica y no se describirá en este caso.
[0138] La función F1, por ejemplo, es una función AES (por "Advanced Encryption Standard").
[0139] No hay restricciones para la función F1.
[0140] El servidor de red SR también genera una dirección ADP para el dispositivo de transmisión RP.
[0141] Alternativamente, la dirección ADP no se genera.
[0142] A continuación, en respuesta a la solicitud de autenticación DA1, el servidor de red SR genera y transmite un mensaje de aceptación de conexión MA1. El mensaje MA1 contiene, en particular, el valor aleatorio AL2 y la dirección ADP generada. También puede contener parámetros de conexión como, por ejemplo, una lista de canales habilitados para comunicarse a través del enlace L1 y/o una lista de canales que se deben deshabilitar y/o un tiempo de respuesta máximo en el que debe recibirse una respuesta a un mensaje emitido por el terminal. Este tiempo de respuesta es, por ejemplo, de 1 segundo.
[0143] El mensaje MA1 es, por ejemplo, un mensaje JoinAccept definido en el estándar LoRaWAN<™>.
[0144] Informaciones relativas a la conexión, es decir la sesión SC1 establecida, se registran en asociación con un identificador del dispositivo de transmisión RP, por ejemplo el identificador IdP, por el servidor de red SR en una memoria accesible por el servidor de red SR, por ejemplo en la lista LT de los terminales conectados.
[0145] Estas informaciones son, por ejemplo, el identificador IdG del servidor de gestión SG y la clave de sesión KSP generada.
[0146] Tras la recepción del mensaje MA1, el módulo de autenticación AUT del dispositivo de transmisión RP genera a su vez la clave de sesión KSP. La clave de sesión KSP se genera aplicando la función F1 a la clave principal KPP almacenada en la memoria MP del dispositivo de transmisión RP, al primer valor aleatorio AL1 generado por el dispositivo de transmisión P y al segundo valor aleatorio AL2 recibido en el mensaje MA1.
[0147] En la forma de realización descrita, el establecimiento de sesión implica la autenticación mutua del dispositivo de transmisión RP y el servidor de red SR.
[0148] Como alternativa, la clave de sesión KSP se genera, por ejemplo, mediante un dispositivo de seguridad (no mostrado) y se almacena previamente, por un lado, en el dispositivo de transmisión RP y, por otro lado, en el servidor de red SR.
[0149] Después de la etapa S2, el dispositivo de transmisión RP y el servidor de red SR tienen respectivamente la misma clave de sesión KSP. En otras palabras, la clave de sesión KSP es compartida por el dispositivo de transmisión RP y el servidor de red SR para la sesión de comunicación entre el dispositivo de transmisión RP y el servidor de red SR.
[0150] Como es sabido, el establecimiento de la sesión SC1 permite al dispositivo de transmisión RP transmitir mensajes de datos con destino al servidor de gestión SG. Los mensajes de datos contienen el identificador IdP del dispositivo de transmisión RP, el identificador IdG del servidor de gestión SG y datos cifrados con la clave de sesión KSP. Los mensajes de datos son recibidos por el servidor de red SR que descifra los datos con su clave de sesión KSP. El servidor de red SR transmite entonces, a través del enlace LS, los datos descifrados al servidor de gestión SG asociado con el dispositivo de transmisión RP.
[0151] De manera recíproca, el servidor de gestión SG puede transmitir un mensaje en respuesta a un mensaje recibido del dispositivo de transmisión RP. Este mensaje es transmitido por el servidor de gestión SG al servidor de red SR que cifra su contenido con la clave de sesión KSP antes de transmitirlo al dispositivo de transmisión RP.
[0152] En la etapa S2 le sigue una etapa S4 durante la cual el servidor de red SR envía un mensaje MG destinado al dispositivo de transmisión RP.
[0153] El mensaje MG contiene el identificador IdC del terminal C, el identificador IdS del servidor de aplicaciones SA asociado con el terminal C y la clave principal KPC asociada con este terminal.
[0154] Alternativamente, el mensaje MG no incluye el identificador IdS.
[0155] Asimismo, como alternativa, el mensaje MG incluye otros datos.
[0156] El mensaje MG se transmite al dispositivo de transmisión RP a través del equipo puerta de enlace EP1.
[0157] Los datos del mensaje MG se cifran con la clave de sesión KSP mediante el servidor de red SR.
[0158] El mensaje MG es generado por ejemplo por el servidor de red SR tras la recepción por parte del servidor de red SR de una solicitud de gestión del terminal C por parte del dispositivo de transmisión RP emitida por el servidor de gestión SG.
[0159] El mensaje MG es una solicitud de gestión de la terminal C. Los datos contenidos en el mensaje MG representan datos de gestión de DG asociados con la terminal C.
[0160] El mensaje MG se transmite, por ejemplo, al dispositivo de transmisión RP en respuesta a un mensaje de consulta emitido por el dispositivo de transmisión RP.
[0161] A la etapa S4 le sigue una etapa S6 durante la cual, tras la recepción del mensaje MG por el primer módulo de comunicación COM1 del dispositivo de transmisión RP, el módulo de gestión GST del dispositivo de transmisión RP obtiene, utilizando la clave de sesión KSP previamente calculada, los datos contenidos en el mensaje MG, en particular el identificador IdC del terminal C, el identificador IdS del servidor SA y la clave principal KPC asociada a este terminal. Después, registra estos datos en una memoria del dispositivo de transmisión RP.
[0162] En la realización descrita, estos datos se registran en la lista TG de terminales gestionados por el dispositivo de transmisión RP. La lista TG contiene para cada terminal gestionado por el dispositivo de transmisión RP, un identificador de dicho terminal y datos de gestión DG asociados. El identificador IdS y la clave principal KPC representan aquí datos de gestión de DG en el sentido de la invención.
[0163] Alternativamente, el identificador IdC, el identificador IdS y la clave principal KPC asociada se registran en el dispositivo de transmisión RP durante una fase de inicialización antes del establecimiento de la sesión SC1. No es necesario entonces que el servidor de red SR transmita estos datos.
[0164] Durante una etapa S8, el terminal C envía a través del segundo enlace de comunicación L2, una solicitud de conexión DA2 al servidor de aplicaciones SA.
[0165] La solicitud de conexión DA2 contiene el identificador IdC del terminal C, el identificador IdS del servidor de aplicaciones SA con el que el terminal C solicita conectarse y un valor aleatorio AL3 generado por el terminal C. La solicitud de conexión DA2 es, por ejemplo, un mensaje JoinRequest definido en el estándar LoRaWAN<™>. La solicitud DA2 es recibida por el segundo módulo de comunicación COM2 del dispositivo de transmisión RP durante una etapa S10. Asimismo, durante la etapa S10, el dispositivo de transmisión RP, a través de su módulo de gestión GST, verifica que la solicitud DA2 es emitida por un terminal de la lista TG de terminales para los que ha recibido derechos de gestión.
[0166] En el caso en el que el terminal que emitió la solicitud DA 2 no aparece en la lista TG de terminales gestionados por el dispositivo de transmisión RP, el dispositivo de transmisión RP no procesa la solicitud DA2.
[0167] El terminal C, y más precisamente el identificador IdC del terminal C, que aparece en la lista TG, la etapa S10 le sigue una etapa S12 durante la cual se establece una sesión de comunicación SC2 entre el terminal C y el dispositivo de transmisión RP.
[0168] Más precisamente, tras recibir la solicitud de conexión DA2, el módulo de autenticación AUT del dispositivo de transmisión RP genera un valor aleatorio AL4, una clave de sesión KC1 y una dirección AD1 para el terminal C. La clave de sesión KC1 se genera de manera convencional utilizando la clave principal KPC asociada al terminal C, el valor aleatorio AL3 recibido y el valor aleatorio AL4.
[0169] Después, el dispositivo de transmisión RP genera y transmite a través del módulo de comunicación COM2, un mensaje MA2 aceptando la conexión. El mensaje MA2 contiene en particular el valor aleatorio AL4 y la dirección generada AD1. También puede contener parámetros de configuración del terminal C.
[0170] El mensaje MA2 es, por ejemplo, un mensaje JoinAccept definido en el estándar LoRaWAN<™>.
[0171] Tras recibir el mensaje MA2, el terminal C genera a su vez la clave de sesión KC1.
[0172] Así, tras la etapa S12, el terminal C por un lado y el dispositivo de transmisión RP tienen la misma clave de sesión KC1. En otras palabras, la clave de sesión KC1 es compartida por el terminal C y el dispositivo de transmisión RP. Durante una etapa S14, siguiente la etapa S12, el primer módulo de comunicación COM1 del dispositivo de transmisión RP transmite un mensaje MTK, a través del enlace L1.
[0173] El mensaje MTK contiene el identificador IdC del terminal C, la clave de sesión KC1 generada por el dispositivo de transmisión RP y la dirección generada AD1. Los datos contenidos en el mensaje MTK se cifran con la clave de sesión KSP compartida entre el dispositivo de transmisión RP y el servidor de red SR.
[0174] En una variante, el mensaje MTK no contiene la clave KC1 y el mensaje MTK contiene datos que permiten al servidor de red SR generar esta clave KC1, es decir, en particular, el primer valor aleatorio AL3 y el segundo valor aleatorio AL4.
[0175] En una realización particular, el dispositivo de transmisión RP ordena el borrado en su memoria de la clave KC1 previamente generada, por ejemplo después de enviar el mensaje MTK.
[0176] Alternativamente, la clave KC1 permanece almacenada en una memoria del dispositivo de transmisión RP. El mensaje MTK es recibido por el servidor de red SR durante una etapa S16.
[0177] A la etapa S16 le sigue una etapa S17 durante la cual el servidor de red SR obtiene la clave de sesión KC1 y la dirección AD1 descifrando los datos del mensaje MTK utilizando la clave KSP almacenada en una de sus memorias.
[0178] Los datos así obtenidos se transmiten al servidor de gestión SG, que los analiza y genera y transmite al servidor de red SR, un mensaje MEK solicitando el registro del terminal C en la lista LT de terminales conectados (etapa S18).
[0179] Más precisamente, el mensaje MEK es una solicitud de registro en la lista TG, del identificador IdC y de informaciones IC1 relativas a la sesión de comunicación SC2.
[0180] Las informaciones IC1 son, por ejemplo, el identificador IdS del servidor de aplicaciones SA, la clave de sesión KC1 y la dirección AD1.
[0181] Durante una etapa S19, el servidor de red SR recibe el mensaje MEK y registra el terminal C en la lista LT de terminales conectados. Por ejemplo, el servidor de red SR registra, en asociación con el identificador IdC del terminal C, las informaciones IC1 relativas a la sesión de comunicación SC2.
[0182] Como alternativa, el mensaje MTK se transmite al servidor de gestión SG mediante el servidor de red SR y los datos del mensaje MTK son descifrados por el servidor de gestión SG.
[0183] Durante una etapa S20, realizada a continuación de las etapas descritas anteriormente, el terminal C que tiene datos DAT1 para transmitir al servidor de aplicaciones SA, genera y transmite un mensaje MD, a través del enlace de comunicación L2.
[0184] Los datos DAT1 son, por ejemplo, datos de medida obtenidos por el terminal C.
[0185] De manera más general, los datos DAT1 son datos que el terminal C desea transmitir al servidor de aplicaciones SA.
[0186] No hay limitaciones en el tipo de datos DAT1 del mensaje de datos MD.
[0187] El mensaje MD contiene el identificador IdS del servidor de aplicaciones SA, la dirección AD1 del terminal C así como los datos DAT1 cifrados con la clave de sesión generada KC1 generada por el terminal C. El mensaje MD también puede contener el identificador IdC del terminal C.
[0188] El mensaje MD es recibido por el segundo módulo de comunicación COM2 del dispositivo de transmisión RP durante una etapa S22.
[0189] Asimismo, durante la etapa S22, el módulo de gestión GST del dispositivo de transmisión RP verifica que el mensaje MD proviene del terminal C.
[0190] Si la verificación es positiva, el módulo de transferencia TRF del dispositivo de transmisión RP ordena la emisión del mensaje MD por el primer módulo de comunicación COM1 del dispositivo de transmisión RP.
[0191] El mensaje de datos MD emitido por el terminal C y recibido por el dispositivo de transmisión RP es así reemitido por este último.
[0192] Si la verificación es negativa, por ejemplo si el mensaje MD recibido por el dispositivo de transmisión RP es un mensaje emitido por un terminal para el cual el dispositivo de transmisión RP no ha recibido derechos, por ejemplo el identificador del terminal y la clave principal del terminal, el dispositivo de transmisión RP no reemite el mensaje. El mensaje MD, reemitido, a través del enlace L1, por el primer módulo COM1 del dispositivo de transmisión RP es recibido por el servidor de red SR durante una etapa S24.
[0193] El servidor de red SR comprueba entonces que el terminal C esté registrado en la lista LT de terminales conectados. Si este es el caso, utilizando los datos IC1 registrados en asociación con el identificador IdC del terminal C en la lista LT, el servidor de red SR puede realizar controles de integridad del mensaje MD.
[0194] Si el terminal no está registrado en la lista LT o si el servidor de red SR considera que los controles no son satisfactorios, el mensaje MD no se transmite al servidor de aplicaciones SA.
[0195] En caso contrario, también en la etapa S24, los datos DAT1 son obtenidos por el servidor de red SR descifrando el mensaje MD utilizando la clave de sesión KC1 registrada en asociación con el identificador IdC del terminal C en la lista LT.
[0196] El servidor de red SR transmite entonces los datos DAT1 al servidor de aplicaciones SA (etapa S24) y el servidor de aplicaciones SA recibe los datos DAT1 durante una etapa S26.
[0197] En la realización descrita, durante la etapa S22, el mensaje MD se retransmite sin sufrir ningún procesamiento por parte del dispositivo de transmisión RP.
[0198] Alternativamente, el mensaje MD es cifrado con la clave de sesión KSP por el dispositivo de transmisión RP antes de ser transmitido. El servidor de red SR lo descifra entonces utilizando la clave de sesión KSP.
[0199] Los etapas S20 a S26 pueden repetirse una o más veces.
[0200] Una de las etapas E26 puede ir seguida de una etapa S30 durante la cual el servidor de aplicaciones SA, que tiene datos DAT2 para transmitir al terminal C, genera y transmite un mensaje MD2 con destino al terminal C.
[0201] El mensaje MD2 es recibido por el servidor de red SR que verifica el mensaje MD2 y cifra los datos DAT2 con la clave de sesión KC1. Después, el servidor de red SR transmite un mensaje MD3 que contiene los datos DAT2 cifrados al dispositivo de transmisión RP a través del equipo puerta de enlace EP1 (etapa S32).
[0202] La transmisión del mensaje MD3 por el servidor de red SR se realiza por ejemplo tras la recepción por parte del servidor de red SR de un mensaje procedente del dispositivo de transmisión RP, generado por el dispositivo de transmisión RP o por el terminal C.
[0203] A la etapa S32 le sigue una etapa S34 durante la cual el dispositivo de transmisión RP, a través del primer módulo de comunicación COM1, recibe el mensaje MD3 y el módulo de transferencia TRF del dispositivo de transmisión RP, controla la reemisión a través del enlace de comunicación L2, por parte del segundo módulo de comunicación COM2, del mensaje MD3 recibido.
[0204] El mensaje MD3 es recibido por el terminal C durante una etapa E36.
[0205] Durante una etapa S50, el servidor de gestión SG obtiene una solicitud de fin de gestión DG1 relativa al terminal C.
[0206] La solicitud de fin de gestión DG1 contiene un identificador del terminal C, por ejemplo el identificador IdC, y un identificador del dispositivo de transmisión RP, por ejemplo el identificador IdP.
[0207] La solicitud de fin de gestión DG1 se transmite, por ejemplo, al servidor de gestión SG mediante el servidor de aplicaciones SA o el servidor de red SR después de constatar la recepción de una gran cantidad de mensajes duplicados. Esta situación se debe, por ejemplo, a que el terminal C ahora se encuentra dentro del área de cobertura del equipo puerta de enlace EPY mientras que permanece dentro del área de cobertura del dispositivo de transmisión RP (figura 2).
[0208] En efecto, tras la instalación del equipo puerta de enlace EPY, los mensajes emitidos vía enlace L2 por el terminal C son recibidos por una parte por el dispositivo de transmisión RP y por otra parte, por el equipo puerta de enlace EPY.
[0209] El dispositivo de transmisión RP transmite estos mensajes como se describe anteriormente al servidor de red SR, a través del equipo puerta de enlace EP1.
[0210] El equipo puerta de enlace EPY también retransmite estos mensajes al servidor de red SR
[0211] El servidor de red SR puede así constatar la doble recepción de mensajes y alertar al servidor de gestión SG o a un operador.
[0212] Alternativamente, la solicitud de fin de gestión DG1 también puede ser introducida por un operador por medio de una interfaz de usuario del servidor de gestión SG o un equipo capaz de comunicarse con el servidor de gestión SG, por ejemplo tras la instalación en el campo del equipo puerta de enlace EPY.
[0213] No existen limitaciones sobre cómo el servidor de gestión SG obtiene la solicitud final de gestión DG1.
[0214] A la etapa S50 le sigue una etapa S52 durante la cual el servidor de gestión SG envía al servidor de red SR una solicitud DG2 para el fin de la gestión del terminal C por parte del dispositivo de transmisión RP.
[0215] En la forma de realización descrita, el servidor de gestión SG también envía al servidor de red SR una solicitud DRC de extracción del terminal C de la lista LT de terminales conectados.
[0216] Alternativamente, la solicitud DRC no se retransmite.
[0217] La solicitud de fin de gestión DG2 contiene el identificador IdC del terminal C. También puede contener el identificador IdP del dispositivo de transmisión RP.
[0218] A la etapa S52 le sigue una etapa S54 durante la cual el servidor de red SR recibe la solicitud DG2 y envía al dispositivo de transmisión RP una solicitud DG3 de fin de gestión del terminal C correspondiente a la solicitud de fin de gestión DG2.
[0219] La solicitud de fin de gestión DG3 se transmite, por ejemplo, al dispositivo de transmisión RP en respuesta a un mensaje transmitido por este último, por ejemplo, un mensaje de consulta.
[0220] La solicitud de gestión DG3 contiene el identificador IdC del terminal C.
[0221] Los datos de solicitud de gestión DG3 son cifrados por el servidor de red SR con la clave de sesión KSP compartida por el dispositivo de transmisión RP y el servidor de red SR.
[0222] Tras la transmisión del mensaje DG3, el servidor de red SR borra de la lista LT de terminales conectados, el identificador IdC del terminal C así como las informaciones IC1 registradas en asociación con este identificador de terminal.
[0223] Alternativamente, la lista LT no se actualiza.
[0224] Tras la recepción de la solicitud de gestión DG3, a través del primer módulo de comunicación COM1 del dispositivo de transmisión RP, el módulo de gestión GST del dispositivo de transmisión RP registra los valores contenidos en la solicitud de gestión DG3 en una memoria del dispositivo de transmisión RP (etapa S56).
[0225] Posteriormente, durante una etapa S60, el terminal C envía un mensaje MD4 destinado al servidor de aplicaciones SA. La etapa S60 es, por ejemplo, similar a la etapa S36 descrita anteriormente.
[0226] El mensaje MD4 es, por ejemplo, un mensaje que contiene datos, por ejemplo datos de medida, cifrados con la clave de sesión KC1.
[0227] El mensaje MD4 es recibido por el segundo módulo de comunicación COM2 del dispositivo de transmisión RP durante una etapa S62.
[0228] Según las realizaciones, el mensaje MD4 puede o no ser retransmitido al servidor de red SR por el dispositivo de transmisión RP.
[0229] A la etapa S62 le sigue una etapa S64 durante la cual el dispositivo de transmisión RP, habiendo recibido el mensaje de solicitud de fin de gestión DG3 a través del primer enlace de comunicación L1, transmite al terminal C uno o más mensajes MFG a través del segundo enlace de comunicación L2. El o los mensajes MFG se transmiten, por ejemplo, en respuesta al mensaje MD4. Estos mensajes MFG están cifrados con la clave de sesión KC1.
[0230] Los mensajes MFG son generados por el módulo de gestión GST y transmitidos por el segundo módulo de comunicación COM2 del dispositivo de transmisión RP.
[0231] Estos mensajes contienen parámetros PAR de configuración del terminal y una solicitud DC de emisión, por el terminal C, de una nueva solicitud de conexión.
[0232] La solicitud DC se formula, por ejemplo, utilizando la opción “ForceRejoinReq” definida en la versión 1.1 del estándar LoRaWAN<™>.
[0233] Alternativamente, estos mensajes no incluyen parámetros de configuración del terminal.
[0234] Los parámetros de configuración PAR contenidos en los mensajes MFG incluyen, por ejemplo, una lista de canales admitidos por el equipo puerta de enlace EPY y/o una lista de canales de frecuencia que se invalidarán ya que son específicos del dispositivo de transmisión RP y no son utilizados por el equipo puerta de enlace EPY.
[0235] La actualización de la lista de canales se solicita, por ejemplo, en forma de una solicitud de "Nuevo Canal" definida en el estándar LoRaWAN<™>.
[0236] Los parámetros de configuración PAR contenidos en el o los mensajes MFG también pueden incluir uno o más valores de plazo de respuesta. Dicho retardo de respuesta es, por ejemplo, un intervalo de tiempo entre el final de la emisión de un mensaje por el terminal C y el inicio de una ventana de recepción durante la cual el terminal C está a la escucha de una respuesta.
[0237] Por ejemplo, este retardo se actualiza mediante una opción "MAC RXTimingSetupReq" definida en el estándar LoRaWAN<™>.
[0238] Tras la recepción del o de los mensajes MFG, el terminal C envía un acuse de recibo ACK de los mensajes MFG (etapa S66).
[0239] El mensaje ACK es recibido por el segundo módulo COM2 del dispositivo de transmisión RP y después de la recepción de dicho mensaje ACK, el módulo de gestión GST del dispositivo de transmisión RP ordena la eliminación del terminal C de la lista TG de terminales para la que tiene derechos de gestión (etapa S68). Más específicamente, el dispositivo de transmisión RP elimina de la lista TG el identificador IdC del terminal C y las informaciones registradas en asociación con este identificador.
[0240] Tras recibir la solicitud DC contenida en los mensajes MFG, el terminal C retransmite una nueva solicitud de conexión DA3 (etapa S70).
[0241] La solicitud de conexión DA3 contiene el identificador IdC del terminal C, el identificador IdS del servidor de aplicaciones SA con el que el terminal C solicita conectarse y un valor aleatorio AL5 generado por el terminal C. La solicitud de conexión DA3 es, por ejemplo, un mensaje "JoinRequest" definido en el estándar LoRaWAN<™>. La solicitud DA3 es recibida por el segundo módulo COM2 del dispositivo de transmisión RP, pero como el terminal C ya no está en la lista TG de terminales gestionados por el dispositivo de transmisión RP, la solicitud de conexión DA3 no está aceptada por el dispositivo de transmisión RP.
[0242] La solicitud DA3 también es recibida por la puerta de enlace EPY que la retransmite al servidor de red SR (etapa S72).
[0243] A la etapa S72 le sigue una etapa S74 durante la cual se establece una sesión de comunicación SC3 entre el terminal C y el servidor de red SR, a través del equipo puerta de enlace EPY.
[0244] Más precisamente, tras recibir la solicitud de conexión DA3, el servidor de red SR genera un valor aleatorio AL6, una clave de sesión KC2 y una dirección AD2 para el terminal C. La clave de sesión KC2 se genera de manera convencional utilizando la clave principal KPC asociada al terminal C, el valor aleatorio AL5 recibido y el valor aleatorio AL6.
[0245] A continuación, el servidor de red SR genera y transmite un mensaje MA3 de aceptación de la conexión. El mensaje MA3 contiene en particular el valor aleatorio AL6 y la dirección generada AD2. También puede contener parámetros de configuración del terminal.
[0246] El mensaje MA3 es, por ejemplo, un mensaje JoinAccept definido en el estándar LoRaWAN<™>.
[0247] Las informaciones relativas a la conexión, es decir, la sesión SC3 establecida, se registran por el servidor de red SR en la lista LT de terminales conectados. Esta información son, por ejemplo, el identificador IdC del terminal C, el identificador IdS del servidor de aplicaciones SA y la clave de sesión generada KC2.
[0248] Tras recibir el mensaje MA3, el terminal C genera a su vez la clave de sesión KC2.
[0249] Como es sabido, el establecimiento de la sesión SC3 permite al terminal C transmitir mensajes de datos con destino al servidor de aplicaciones SA. Los mensajes de datos contienen un identificador IdC del terminal C y datos cifrados con la clave de sesión KC2. Los mensajes de datos son recibidos por el servidor de red SR, que descifra los datos utilizando su clave de sesión KC2 almacenada en la lista LT en asociación con el identificador IdC del terminal C. Acto seguido, el servidor de red SR transmite los datos descifrados a través del enlace LS al servidor de aplicaciones SA asociado al terminal C.
[0250] Recíprocamente, el servidor de aplicaciones SA puede transmitir un mensaje en respuesta a un mensaje recibido del terminal C. Este mensaje es transmitido por el servidor de aplicaciones SA al servidor de red SR, que cifra su contenido con la clave de sesión KC2 antes de transmitirlo con destino al terminal C.
[0251] Las etapas S0, S2, S6, S10, S12, S14, S22, S34, S56, S62, S64 y S68 implementadas por el dispositivo de transmisión RP representan etapas del procedimiento de gestión según una realización de la invención.
[0252] En la realización descrita, el dispositivo de transmisión RP, tras recibir la solicitud DG3 de fin de gestión del terminal C, transmite mensajes MFG a través del enlace de comunicación L2.
[0253] Alternativamente, el dispositivo de transmisión RP no transmite mensajes MFG.
[0254] Al recibir mensajes transmitidos por el terminal C, el dispositivo de transmisión RP no procesa estos mensajes. Actúa entonces como si no los recibiera.
[0255] La terminal C continúa emitiendo mensajes cifrados con la clave de sesión KC1. Estos mensajes son retransmitidos por el equipo puerta de enlace EPY al servidor de red SR que descifra estos mensajes. Asimismo, el servidor de red SR transmite al terminal C, a través del equipo puerta de enlace EPY, mensajes que contienen datos generados por el servidor de aplicaciones SA y cifrados con la clave KC1 por el servidor de red SR.
[0256] Esta comunicación continúa hasta que el terminal C emite una nueva solicitud de conexión. La emisión de esta nueva solicitud de conexión provoca el establecimiento de una nueva sesión de comunicación entre el terminal C y el servidor de red SR, y en consecuencia la generación de una nueva clave de sesión.
[0257] En la realización descrita, al establecer una sesión entre el terminal C o el dispositivo de transmisión RP y un servidor de aplicaciones, por ejemplo el servidor de gestión SG o el servidor de aplicaciones SA, la autenticación del terminal o del dispositivo de transmisión se lleva a cabo por el servidor de red SR.
[0258] Alternativamente, dicha autenticación puede ser realizada por el servidor de gestión, el servidor de aplicaciones SA u otro equipo de red, por ejemplo, un servidor de autenticación de red. En esta variante, los datos asociados a un servidor de aplicaciones y necesarios para la implementación de la autenticación se ponen a disposición de este servidor.
[0259] Una clave secundaria generada a partir de una clave principal puede ponerse a disposición del servidor de red, que entonces autentica y/o descifra los mensajes procedentes de un terminal o dispositivo de transmisión antes de transmitirlos, preferiblemente a través de un enlace seguro, al servidor de aplicaciones correspondiente. A la inversa, los mensajes generados por un servidor de aplicaciones son firmados y/o cifrados con la clave secundaria por el servidor de red antes de su transmisión a un terminal o dispositivo de transmisión.
[0260] Una clave secundaria generada a partir de una clave principal también puede ponerse a disposición del servidor de aplicaciones, que puede así cifrar los mensajes antes de su transmisión y descifrar los mensajes recibidos. En la forma de realización descrita, se genera una clave de sesión para cada autenticación mutua. Durante la autenticación mutua del dispositivo de transmisión RP y el servidor de gestión SG se genera una clave de sesión KSP, durante la autenticación mutua del terminal C y el dispositivo de transmisión RP se genera una clave de sesión KC1, y durante la autenticación mutua del terminal C y el servidor de aplicaciones SA se genera una clave de sesión KC2.
[0261] Tal y como se define en el estándar LoRaWAN<™>, estas claves de sesión son claves de sesión de aplicación. En las arquitecturas de tipo LoRaWAN<™>, la seguridad de los intercambios entre los terminales y los servidores de aplicaciones se garantiza a dos niveles distintos, es decir, a nivel de la red mediante diversas comprobaciones de integridad efectuados por el servidor de red que actúa como intermediario entre los terminales y los servidores de aplicaciones y por los propios terminales, y a nivel de la aplicación mediante el cifrado/descifrado de los datos de aplicación intercambiados entre los terminales y los servidores de aplicaciones. Cada uno de estos mecanismos se basa, en cada sesión establecida por un terminal con un servidor de aplicaciones a través del servidor de red, en el conocido algoritmo de cifrado AES utilizado en el protocolo LoRaWAN<™>, a veces parametrizado mediante claves criptográficas de sesión de red, a veces mediante claves criptográficas de sesión de aplicación. Estas claves criptográficas tienen un tamaño de 128 bits. Cabe señalar, no obstante, que la invención permite prever fácilmente algoritmos de cifrado simétrico distintos del algoritmo de cifrado AES, así como otros tamaños de clave.
[0262] La invención también se aplica a esta arquitectura.
[0263] Así, en una forma de realización alternativa, durante la autenticación mutua requerida por el dispositivo de transmisión RP, la solicitud de autenticación DA1 emitida por el dispositivo de transmisión RP es interceptada por un servidor de red SR de la red LoRa<™>.
[0264] Tras recibir la solicitud de autenticación DA1, el servidor de red SR genera por una parte una clave de red KRP y por otra parte la clave de sesión KSP.
[0265] Además de la clave de sesión KSP, el dispositivo de transmisión RP también genera la clave de red KRP.
[0266] Los mensajes transmitidos por el dispositivo de transmisión RP con destino al servidor de gestión SG contienen datos cifrados por la clave de sesión KSP y, a continuación, firmados por la clave de red KRP. Cada mensaje es recibido por el servidor de red SR, que comprueba su integridad y autenticidad utilizando su clave de red KRP, y lo transmite al servidor de gestión SG, que lo descifra utilizando la clave de sesión KSP. Alternativamente, si ha sido
autorizado para ello, el servidor de red SR puede descifrar el mensaje con la clave de sesión KSP y transmitir el mensaje descifrado al servidor de gestión SG a través del enlace LS, que es preferiblemente seguro.
[0267] Asimismo, durante la etapa de autenticación mutua entre el terminal C y el dispositivo de transmisión DP, se puede generar una clave de red KRC1 a partir de la clave principal KPC, por un lado, por el terminal C y, por otro lado, por el dispositivo de transmisión RP.
[0268] Del mismo modo, durante la etapa de autenticación mutua entre el terminal C y el servidor de red SR, puede generarse una clave de red KRC2 a partir de la clave principal KPC, por una parte, por el terminal C y, por otra parte, por el servidor de red SR de la red LoRa<™>.
[0269] Los mensajes transmitidos por el terminal C también están entonces firmados por la clave de red KRC2 o KRC1. Como variante de esta realización, al recibir un mensaje de datos cifrado con la clave de sesión KC2 y firmado con la clave de red KRC2, desde el terminal C, el dispositivo de transmisión RP obtiene, utilizando la clave de red KRC2, los datos DATA cifrados con la clave de sesión KC2, es decir KC2(DATA). A continuación, cifra estos datos cifrados (KC2(DATA)) con la clave de sesión KSP y, a continuación, los firma con la clave de red KRP antes de transmitir el mensaje así obtenido.
[0270] El mensaje es obtenido por el servidor de red SR, que obtiene y transmite los datos cifrados con la clave de sesión KSP al servidor de gestión SG. Este mensaje es recibido por el servidor de gestión SG que, utilizando su clave KSP, obtiene los datos cifrados con la clave KC2 y transmite el mensaje resultante. Por último, este mensaje es recibido por el servidor de aplicaciones SA, que utiliza la clave KC2 para obtener los datos DATA.
Claims (11)
1. REIVINDICACIONES
1.Procedimiento de gestión que comprende las siguientes etapas implementadas por un dispositivo de transmisión (RP) capaz de comunicarse a través de un primer enlace de radio de largo alcance LoRa (L1) con un equipo puerta de enlace (EP1) que forma un nodo de una red de telecomunicaciones y configurado para comunicarse con al menos un servidor de dicha red a través de dicho equipo puerta de enlace:
tras la recepción (S10) de una primera solicitud de conexión (DA2) emitida a través de un segundo enlace de radio de largo alcance LoRa (L2), por un terminal (C) que aparece en una lista (TG) de al menos un terminal para el que dicho dispositivo de transmisión ha obtenido datos de gestión (DG), establecimiento (S12) de una sesión de comunicación segura (SC2) entre el dispositivo de transmisión (RP) y dicho terminal (C),
tras la recepción (S22) de un mensaje de datos (MD) emitido por dicho terminal a través de la sesión de comunicación segura (SC2), transferencia (S22) de dicho mensaje a través de dicho primer enlace de radio (L1), si dicho terminal aparece en dicha lista;
tras la recepción (S34) a través de dicho primer enlace de radio (L1) de un mensaje de datos (MD3) destinado a dicho terminal, transferencia (S34) de dicho mensaje a dicho terminal a través de la sesión de comunicación segura (SC2), si dicho terminal aparece en dicha lista;
recepción (S56) a través de dicho primer enlace de radio, de una solicitud (DG3) de fin de gestión de dicho terminal; tras la recepción de dicha solicitud de fin de gestión, eliminación (S68) de dicho terminal de dicha lista.
2.Procedimiento de gestión según la reivindicación 1, en el que tras la recepción de dicha solicitud de fin de gestión, el dispositivo de transmisión transmite (S64) a dicho terminal una solicitud de emisión por dicho terminal de una segunda solicitud de conexión.
3.Procedimiento de gestión según la reivindicación 1, en el que el establecimiento de la sesión segura comprende una generación de una clave de sesión (KC1) compartida entre el dispositivo de transmisión y el terminal, a partir de al menos parte de los datos de gestión.
4.Procedimiento de gestión según la reivindicación 1, en el que dicha solicitud (DG3) de fin de gestión se recibe a través de dicho equipo puerta de enlace (EP1) y a través de dicho servidor de red.
5.Procedimiento de gestión según la reivindicación 1, en el que la solicitud de fin de gestión se transmite al dispositivo de transmisión a través de una sesión de comunicación segura (SC1) establecida entre el dispositivo de transmisión y un servidor de dicha red.
6.Procedimiento de gestión según la reivindicación 2, en el que dicha solicitud de emisión se emite en respuesta a un mensaje emitido por dicho terminal a través de la sesión de comunicación establecida entre el terminal y el dispositivo de transmisión.
7.Procedimiento de gestión según la reivindicación 2, en el que el terminal es eliminado de la lista después de recibir un acuse de recibo emitido por el terminal en respuesta a la solicitud de emisión.
8.Procedimiento de gestión según la reivindicación 2, en el que la recepción de la solicitud de fin de gestión es seguida de un envío de una solicitud de tipo Nuevo Canal definida en el estándar LoRaWAN<™>.
9.Procedimiento de gestión según la reivindicación 3, en el que dichos mensajes de datos emitidos por el terminal comprenden datos cifrados o firmados con la clave de sesión compartida por el terminal y el dispositivo de transmisión.
10.Procedimiento de gestión según la reivindicación 3, en el que el procedimiento comprende una etapa de transmisión de datos relativos a la clave de gestión generada a un servidor de red.
11.Dispositivo de transmisión (RP) que comprende
un primer módulo de comunicación (COM1) configurado para comunicarse a través de un primer enlace de radio de largo alcance de tipo LoRa (L1) con un equipo puerta de enlace (EP1) que forma un nodo de una red de telecomunicaciones y para comunicarse con al menos un servidor de la red a través de dicho equipo puerta de enlace (EP1);
un segundo módulo de comunicación (COM2) configurado para comunicarse a través de un segundo enlace de radio de largo alcance de tipo LoRa (L2) con al menos un terminal, estando dicho segundo módulo de comunicación configurado para recibir a través de dicho segundo enlace de radio una primera solicitud de conexión (DA2) emitida por un terminal (C) que aparece en una lista (TG) de al menos un terminal para el que dicho dispositivo de transmisión ha obtenido datos de gestión (DG);
un módulo de autenticación (AUT) configurado para establecer, tras la recepción de la primera solicitud de conexión, una sesión de comunicación segura entre el dispositivo de transmisión (RP) y dicho terminal (C), un módulo de transferencia (TRF) configurado para transferir a través de dicho primer enlace de radio, al menos un mensaje de datos emitido a través de la sesión de comunicación segura por dicho terminal, si dicho terminal aparece en dicha lista, y para transferir, tras la recepción a través de dicho primer enlace de radio, un mensaje de
datos destinado a dicho terminal, dicho mensaje a dicho terminal a través de la sesión segura, si dicho terminal aparece en dicha lista;
estando el primer módulo de comunicación (COM1) configurado para recibir a través de dicho primer enlace de radio, una solicitud de fin de gestión de dicho terminal; y
un módulo de gestión (GST) configurado para, tras la recepción de dicha solicitud de fin de gestión, eliminar dicho terminal de dicha lista.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1761508A FR3074634A1 (fr) | 2017-12-01 | 2017-12-01 | Gestion de communication entre un terminal et un serveur d’un reseau |
| PCT/FR2018/053039 WO2019106302A1 (fr) | 2017-12-01 | 2018-11-29 | Gestion de communication entre un terminal et un serveur d'un réseau |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES3053684T3 true ES3053684T3 (en) | 2026-01-23 |
Family
ID=61224068
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES18827201T Active ES3053684T3 (en) | 2017-12-01 | 2018-11-29 | Communication management between a terminal and a network server |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US11540336B2 (es) |
| EP (1) | EP3718372B8 (es) |
| CN (1) | CN111418261B (es) |
| ES (1) | ES3053684T3 (es) |
| FR (1) | FR3074634A1 (es) |
| WO (1) | WO2019106302A1 (es) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11343089B2 (en) * | 2019-07-10 | 2022-05-24 | Tunnel VUE Inc. | Cryptography system and method |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7506370B2 (en) * | 2003-05-02 | 2009-03-17 | Alcatel-Lucent Usa Inc. | Mobile security architecture |
| EP1879332A1 (fr) * | 2006-07-12 | 2008-01-16 | France Télécom | Procede et systeme de gestion d'une transmission securisee |
| FR2906096B1 (fr) * | 2006-09-19 | 2008-10-24 | Radiotelephone Sfr | Procede de securisation de sessions entre un terminal radio et un equipement dans un reseau |
| FR2950768A1 (fr) * | 2009-09-30 | 2011-04-01 | Xiring Sa | Systeme et procede de transaction securisee en ligne |
| KR20140041226A (ko) * | 2012-09-27 | 2014-04-04 | 삼성전자주식회사 | 이동 통신 시스템에서 그룹 통신을 위한 보안 관리 방법 및 장치 |
| FR3000336A1 (fr) * | 2012-12-20 | 2014-06-27 | France Telecom | Mecanisme de gestion d'une session de communication |
| FR3023442B1 (fr) * | 2014-07-03 | 2017-11-24 | Predicsis | Procede de transfert d'une communication entre deux nœuds d'acces a un reseau de communication |
| FR3023663B1 (fr) * | 2014-07-11 | 2016-08-05 | Sagemcom Broadband Sas | Passerelle residentielle relais entre un dispositif terminal et un serveur |
| KR102294040B1 (ko) * | 2015-01-19 | 2021-08-26 | 삼성전자 주식회사 | 데이터 송수신 방법 및 장치 |
| US10447795B2 (en) * | 2015-10-05 | 2019-10-15 | Polycom, Inc. | System and method for collaborative telepresence amongst non-homogeneous endpoints |
| WO2017082955A1 (en) * | 2015-11-09 | 2017-05-18 | Intel Corporation | Enhanced direct ue communication |
| US20170171752A1 (en) * | 2015-12-14 | 2017-06-15 | Qualcomm Incorporated | Securing signaling interface between radio access network and a service management entity to support service slicing |
| US20170220810A1 (en) * | 2016-01-29 | 2017-08-03 | Rovi Guides, Inc. | Systems and methods for ensuring media shared on a closed network is returned to owner when end to closed network connection is imminent |
-
2017
- 2017-12-01 FR FR1761508A patent/FR3074634A1/fr not_active Ceased
-
2018
- 2018-11-29 EP EP18827201.7A patent/EP3718372B8/fr active Active
- 2018-11-29 WO PCT/FR2018/053039 patent/WO2019106302A1/fr not_active Ceased
- 2018-11-29 ES ES18827201T patent/ES3053684T3/es active Active
- 2018-11-29 US US16/767,554 patent/US11540336B2/en active Active
- 2018-11-29 CN CN201880077504.XA patent/CN111418261B/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US11540336B2 (en) | 2022-12-27 |
| EP3718372B1 (fr) | 2025-08-27 |
| CN111418261A (zh) | 2020-07-14 |
| FR3074634A1 (fr) | 2019-06-07 |
| WO2019106302A1 (fr) | 2019-06-06 |
| US20200374944A1 (en) | 2020-11-26 |
| EP3718372A1 (fr) | 2020-10-07 |
| CN111418261B (zh) | 2023-11-21 |
| EP3718372B8 (fr) | 2025-11-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10601594B2 (en) | End-to-end service layer authentication | |
| Tschofenig et al. | Transport layer security (tls)/datagram transport layer security (dtls) profiles for the internet of things | |
| Hummen et al. | Delegation-based authentication and authorization for the IP-based Internet of Things | |
| US20180288013A1 (en) | End-to-end secured communication for mobile sensor in an iot network | |
| CN107534658B (zh) | 使用公钥机制在服务层的端对端认证 | |
| JP7843767B2 (ja) | セルラネットワークを動作させるための方法 | |
| US10250578B2 (en) | Internet key exchange (IKE) for secure association between devices | |
| US10897509B2 (en) | Dynamic detection of inactive virtual private network clients | |
| ES2904975T3 (es) | Transmisión de datos entre un terminal y un servidor asociado | |
| US11218873B2 (en) | Communication system and method | |
| KR101688118B1 (ko) | 사물인터넷 환경에서의 보안 통신 장치 및 그 방법 | |
| KR100793472B1 (ko) | 암호화 방식들 간의 변환 처리를 가속화하기 위한 방법 및시스템 | |
| JP7442690B2 (ja) | 安全な通信方法、関連する装置、およびシステム | |
| EP3570487A1 (en) | Private key generation method, device and system | |
| KR20210061801A (ko) | Mqtt-sn 프로토콜의 보안을 위한 mqtt-sn 보안 관리 방법 및 시스템 | |
| Fossati | RFC 7925: Transport Layer Security (TLS)/Datagram Transport Layer Security (DTLS) profiles for the Internet of Things | |
| JP7769128B2 (ja) | 通信方法および通信装置 | |
| ES3053684T3 (en) | Communication management between a terminal and a network server | |
| ES2964007T3 (es) | Gestión de la comunicación entre un terminal y un servidor de red | |
| CN116132983A (zh) | 接入认证方法、装置、终端及核心网 | |
| CN119603339B (zh) | 物联网设备远程控制方法、平台、存储介质和程序产品 | |
| KR100934223B1 (ko) | 서버 기반 이동 인터넷 프로토콜 버전 6 시스템에서의 보안방법 | |
| US12587839B2 (en) | Method, devices and system for performing key management | |
| CN117915433A (zh) | 一种基于电力无线专网的安全接入方法及装置 | |
| GB2611284A (en) | Managing Connectivity Between Devices |