ES2760613T3 - Procedimiento de comunicación para asegurar el mantenimiento de una sesión aplicativa entre un terminal y un servidor de aplicación - Google Patents

Abstract

Procedimiento de comunicación entre una primera entidad comunicante (UE) conectada a una primera red (INTERNET) a través de una primera pasarela NAT (NAT1) de una primera red local (NET1) y un servidor de aplicación (SERV_A), estando asociado dicho servidor de aplicación (SERV_A) con una pasarela NAT configurable (NAT0) que permite hacer corresponder al menos una dirección de al menos la primera pasarela NAT (NAT1, NAT2) con al menos una dirección pública (S1, S2) de la primera entidad comunicante (UE), llamada dirección reflexiva del par (AR-P), que incluye las siguientes etapas: - Establecimiento de una primera secuencia de intercambio de candidatos (SEQ1), comprendiendo dichos candidatos al menos una dirección IP y un puerto, que incluye: o Una recopilación de candidatos por la primera entidad (UE) acerca de un servidor que implementa los protocolos ICE, STUN o TURN para ser alcanzado por un servidor remoto (SERV_A) por medio de la primera pasarela NAT (NAT1); o Un intercambio de candidatos entre la primera entidad (UE) y el servidor de aplicaciones (SERV_A) que provoca la transmisión de la dirección reflexiva del par (AR-P) entre la pasarela NAT configurable (NAT0) y la primera pasarela (NAT1); o Una transmisión por la primera entidad (UE) de un historial de candidatos asignados a la primera entidad (UE) al servidor de aplicaciones (SERV_A); o Verificación de los canales entre pares de candidatos establecidos entre la primera entidad (UE) y el servidor de aplicaciones (SERV_A); - Generación de un primer canal de transmisión que garantiza el establecimiento de una primera sesión aplicativa (SA1); - Detección por la primera entidad comunicante (UE) de una nueva red de acceso (NET2) que incluye una segunda pasarela NAT (NAT2) o de una reconexión a la primera red de acceso (NET1) posterior a una desconexión, lo que provoca el establecimiento de una segunda secuencia de intercambios (SEQ2) de nuevos candidatos que incluye etapas similares a la primera secuencia (SEQ1); - Configuración automática de la pasarela configurable (NAT0) mediante una función del servidor de aplicación (SERV_A) para modificar la correspondencia entre la dirección de origen de la primera o de la segunda pasarela NAT (NAT1, NAT2) con la dirección reflexiva del par (AR-P) de la pasarela NAT configurable (NAT0) a partir del historial de los candidatos transmitidos por la entidad comunicante (UE); - Generación de un segundo canal de transmisión entre la primera entidad comunicante (UE) y el servidor de aplicación (SERV_A) garantizando el mantenimiento de la primera sesión aplicativa (SA1).

Description

DESCRIPCIÓN

Procedimiento de comunicación para asegurar el mantenimiento de una sesión aplicativa entre un terminal y un servidor de aplicación

Campo

El campo de la invención se refiere a procedimientos y sistemas de comunicación que aseguran una continuidad de funcionamiento cuando un terminal de usuario cambia de una red a otra. Más particularmente, el campo de la invención se refiere a la reconfiguración dinámica de una pasarela NAT para garantizar la continuidad de ciertos servicios de comunicación entre dos entidades comunicantes.

Estado de la técnica

Actualmente, existen técnicas de establecimiento de comunicación entre dos entidades comunicantes y se implementan dentro de las redes de comunicaciones, tal como entre dos terminales de usuario, entre aplicaciones comunicantes implementadas en equipos de una red o entre un terminal de usuario y un servidor de aplicación.

Sin embargo, las comunicaciones directas entre diferentes entidades comunicantes en Internet son difíciles de implementar debido a la complejidad de las arquitecturas de red implementadas y de las numerosas redes privadas o locales a través de las cuales las entidades comunicantes acceden a Internet. Esta dificultad resulta en particular del despliegue de protocolos que constituyen frenos para la implementación de enlaces dinámicos punto a punto. Por ejemplo, las pasarelas NAT que convierten direcciones locales de una red local a direcciones públicas en Internet, y viceversa, no permiten una implementación efectiva del establecimiento de dichos enlaces punto a punto. En efecto, la implementación de una pasarela NAT para acceder a otras redes tiene como consecuencia enmascarar las direcciones de los equipos de una red local y, en particular, de los clientes y servicios accesibles de dicha red local.

Para superar estas dificultades, se conoce según la terminología anglosajona el "Establecimiento de conectividad interactiva", denominado ICE, que define rutas de comunicación entre entidades comunicantes punto a punto teniendo en cuenta la arquitectura de las pasarelas NAT. Esta técnica se utiliza en particular para los protocolos de voz sobre IP, denominados VoIP, de transmisión de flujo de video o aún de transmisiones de mensajes instantáneos. La técnica ICE a menudo se asocia con los protocolos STUN (RFC5389) y TURN (RFC 5766). Los protocolos STUN y TURN designan respectivamente « Utilidades de Sesión Transversal para NAT » y « Transmisiones de Utilización Transversal alrededor de NAT ». Son protocolos que permiten la implementación de técnicas NAT cuando es necesario un descubrimiento de direcciones o es necesario un tercer transmisor para superar las dificultades, por ejemplo, de la implementación de un cortafuegos (“Firewall”) con una técnica NAT.

Un problema surge del hecho de que generalmente un enlace punto a punto establecido entre dos servicios o dos clientes de dos equipos de diferentes redes conectados a Internet implica para algunos medios la indicación de un puerto de comunicación que depende del tipo de medio. Aunque una pasarela NAT permite efectuar correspondencias de direcciones de una red local/privada a una red pública y viceversa. De hecho, una pasarela NAT no gestiona necesariamente las reasignaciones de los puertos durante los cambios de direcciones de los encabezamientos de los mensajes transmitidos pues estos últimos están indicados en el cuerpo de los mensajes intercambiados. Este es particularmente el caso cuando se utiliza una pasarela NAT con el protocolo SIP, cuyo acrónimo significa « Protocolo de inicialización de Sesión ».

Un servidor STUN permite intercambiar informaciones relativas a los diferentes tipos de direcciones públicas y locales, así como los números de puertos entre dos entidades comunicantes para que estas últimas puedan comunicarse a través de pasarelas NAT y con diferentes recursos aplicativos.

El documento de la técnica anterior US2010/0312880 describe la puesta en práctica de una usurpación de dirección IP o de número de puerto, con este fin, se proporciona una pasarela para interceptar o escuchar mensajes STUN, ICE, TURN.

Hoy en día, las técnicas ICE asociadas con los protocolos STUN y TURN tienen mecanismos para reconstruir sesiones aplicativas durante desconexiones de un equipo o de una báscula (“flip-flop”) de una red de acceso a otra. Un interés de estos mecanismos es permitir cierta movilidad de un terminal mientras se garantiza una independencia frente a la arquitectura de red. En particular, estos mecanismos se liberan de la arquitectura de red, en particular de la arquitectura de las pasarelas NAT o de los cortafuegos, para que las comunicaciones de datos sean inmunes a la ruta tomada por los paquetes de datos.

Sin embargo, cuando un terminal que se comunica con un servidor de aplicación cambia de redes de acceso a una red de Internet o cuando se desconecta y se vuelve a conectar a una misma red local, un inconveniente de las técnicas anteriores es que la sesión aplicativa debe ser reconfigurada entre el terminal y el servidor de aplicación. Incluso si se restauran los canales de transmisión de datos, el hecho es que esto es particularmente problemático durante el cambio de una primera red de acceso a una segunda red de acceso, especialmente cuando un usuario es móvil y desea mantener su sesión aplicativa.

Se entiende que la reconfiguración de una sesión aplicativa entre dos entidades comunicantes que generalmente requiere una inicialización e intercambios de datos preliminares implica una prolongación de las duraciones de latencia y una discontinuidad de los servicios ofrecidos. Por ejemplo, el protocolo VoIP requiere una reconfiguración de la sesión aplicativa lo más rápido posible habida cuenta de las restricciones en tiempo real. En consecuencia, los mecanismos de reconstrucción de sesiones aplicativas, aunque útiles, parecen insuficientes para garantizar una calidad de servicio a un usuario dado. Una opción puede ser no cambiar de redes hasta que se establezca una sesión aplicativa de manera que se ignore la consideración de la nueva red de acceso.

Compendio de la invención

La invención tiene como objetivo superar los inconvenientes mencionados anteriormente.

Según un aspecto, la invención se refiere a un procedimiento de comunicación entre una primera entidad comunicante conectada a una primera red a través de una primera pasarela NAT de una primera red local y un servidor de aplicación, estando asociado dicho servidor de aplicación con un pasarela NAT configurable NAT0 que permite hacer corresponder al menos una dirección de al menos la primera pasarela NAT con al menos una dirección pública de la primera entidad comunicante, llamada dirección reflexiva del par, que incluye las siguientes etapas:

• Establecimiento de una primera secuencia de intercambios de candidatos, comprendiendo dichos candidatos al menos una dirección IP y un puerto, que incluye:

o Una recopilación de candidatos por la primera entidad acerca de un servidor que implementa los protocolos ICE, STUN o TURN para ser alcanzado por un servidor remoto a través de la primera pasarela NAT;

o Un intercambio de candidatos entre la primera entidad y el servidor de aplicación que provoca la transmisión de la dirección reflexiva del par entre la pasarela NAT configurable y la primera pasarela;

o Una transmisión por la primera entidad de un historial de candidatos atribuidos a la primera entidad hacia el servidor de aplicación;

o Verificación de los canales entre pares de candidatos establecidos entre la primera entidad y el servidor de aplicación;

• Generación de un primer canal de transmisión que garantiza el establecimiento de una primera sesión aplicativa;

• Detección por la primera entidad comunicante de una nueva red de acceso que incluye una segunda pasarela NAT o de una reconexión a la primera red de acceso posterior a una desconexión, lo que provoca el establecimiento de una segunda nueva secuencia de intercambios de nuevos candidatos que incluyen etapas similares a la primera secuencia;

• Configuración automática de la pasarela configurable mediante una función del servidor de aplicación para modificar la correspondencia entre la dirección de origen de la primera o de la segunda pasarela NAT con la dirección reflexiva del par de la pasarela NAT configurable a partir del historial de los candidatos transmitido por la entidad comunicante;

• Generación de un segundo canal de transmisión entre la primera entidad comunicante y el servidor de aplicación que garantiza el mantenimiento de la primera sesión aplicativa.

Una ventaja es permitir garantizar una continuidad de funcionamiento de una aplicación a través del mantenimiento de una sesión aplicativa. La invención es particularmente aplicable en dos casos de figuras:

- cuando una entidad comunicante se desconecta por cualquier razón de la red y es necesaria una reconexión.

La configuración anterior permite restaurar una sesión aplicativa que ya estaba configurada sin tener que reinicializar una nueva sesión aplicativa;

- cuando una entidad comunicante detecta una nueva red y se recibe una indicación o se toma la decisión de proseguir una comunicación previamente establecida en una primera red hacia la nueva red detectada. En esta configuración, la comunicación prosigue por medio de la nueva red sin reinicializar la sesión aplicativa ya existente.

Según un modo de realización, los candidatos incluyen, además de una dirección IP y un número de puerto:

o Un identificador de aplicación y/o;

o Un identificador SIP.

Según un modo de realización, la sesión aplicativa comprende un identificador de aplicación de la entidad comunicante asociada con un identificador de aplicación del servidor de aplicación, implicando un mantenimiento de una sesión aplicativa el mantenimiento de la asociación de los identificadores de aplicación.

Según un modo de realización, el establecimiento de la primera y la segunda secuencia de intercambios de candidatos incluye sucesivamente:

• Un intercambio de candidatos de un protocolo de señalización entre la entidad comunicante y el servidor de aplicación;

• Un intercambio de candidatos de un protocolo de aplicación entre un cliente de la entidad comunicante y un cliente del servidor de aplicación;

• Un intercambio de candidatos de un protocolo de enrutamiento entre la primera o la segunda pasarela NAT y la pasarela configurable.

Según un modo de realización, la pasarela NAT comprende un reloj que permite determinar las duraciones durante las cuales no se transmite ningún dato en el canal de transmisión, permitiendo dicha duración generar un indicador de prioridad asignado a un candidato almacenado en la pasarela y asociado con un terminal.

Según otro aspecto, la invención se refiere a un sistema de comunicación que incluye un servidor de aplicación que incluye al menos un cliente de aplicación y una pasarela NAT configurable, pudiendo dicho servidor de aplicación realizar un intercambio de candidatos con una entidad comunicante remota a petición por medio de la pasarela NAT, atribuyendo dicha pasarela NAT configurable una dirección pública al servidor de aplicación, denominada dirección reflexiva del par, estando asociada esta dirección con la entidad de comunicación remota, a fin de establecer un primer canal de transmisión que garantice el establecimiento de una primera sesión aplicativa, caracterizado por que una nueva solicitud de intercambio de candidatos que incluye un historial de candidatos anteriores recibido de una misma entidad comunicante hacia el servidor de aplicación provoca una configuración de la pasarela NAT configurable para modificar la asociación entre al menos un candidato transmitido y la dirección reflexiva del par de la pasarela NAT configurable, estableciendo el sistema un segundo canal de transmisión entre la entidad comunicante y el servidor de aplicación que garantiza el mantenimiento de la primera sesión aplicativa.

Según otro aspecto, la invención se refiere a una entidad comunicante que incluye al menos un módulo de radio o red que permite transmitir datos en al menos una interfaz de dicho terminal conectado a una red, incluyendo dicha entidad comunicante una memoria en la que se registra un historial de candidatos. y asociada con un servidor de aplicación, siendo recogidos dichos candidatos por ejemplo de un servidor que implementa uno de los protocolos ICE, STUN o TURN, incluyendo dicha entidad comunicante al menos un ordenador para insertar en al menos una trama de un protocolo SIP un campo de datos que incluyen el historial de los candidatos recopilados y almacenados una vez que se genera un canal de transmisión entre dicho terminal y un servidor de aplicación, incluyendo la entidad comunicante dos módems para detectar la presencia de al menos dos redes de acceso y generar dos canales de transmisiones en paralelo en los que una sesión aplicativa establecida entre dicho terminal de usuario y un servidor de aplicación cambia de un canal de transmisión a otro mientras mantiene el mismo identificador de sesión.

Breve descripción de las figuras

Otras características y ventajas de la invención surgirán al leer la descripción detallada que sigue, con referencia a las figuras adjuntas, que ilustran:

La fig. 1: una arquitectura de comunicación que permite ilustrar la primera etapa de recopilación de candidatos del procedimiento de la invención de un servidor ICE/s Tu N/TURN;

La fig. 2: las etapas principales del procedimiento de la invención;

La fig. 3: la secuencia de recolección de candidatos y de intercambio entre estos últimos entre dos entidades comunicantes;

La fig. 4: una arquitectura de comunicación de la fig. 1 que representa la secuencia de intercambio de los candidatos de un protocolo de señalización entre las dos entidades comunicantes;

La fig. 5: una arquitectura de comunicación de la fig. 1 que representa la secuencia de intercambio de los candidatos de un protocolo de aplicación entre las dos entidades comunicantes;

La fig. 6: una arquitectura de comunicación de la fig. 1 que representa la validación de la secuencia de intercambio de los candidatos entre dos entidades comunicantes;

La fig. 7: un caso de ejemplo en el que una entidad comunicante detecta una segunda subred e inicia una secuencia de recogida de candidatos según el procedimiento de la invención;

La fig. 8: una arquitectura de comunicación de la fig. 7 que representa la secuencia de intercambio de los candidatos de un protocolo de señalización entre las dos entidades comunicantes para comunicarse a partir de la segunda subred descubierta;

La fig. 9: una arquitectura de comunicación de la fig. 7 que representa la secuencia de intercambio de los candidatos de un protocolo de aplicación entre las dos entidades comunicantes para comunicarse a partir de la segunda subred descubierta.

Descripción

El procedimiento de la invención se describe a continuación a partir de un ejemplo que emplea dos entidades comunicantes. Las entidades comunicantes pueden ser según los modos de realización:

• dos servidores de aplicación;

• dos terminales de usuarios;

• un terminal de usuario y un servidor de aplicación.

En la continuación de la descripción, se detalla el modo de realización de un canal de transmisión de datos entre un terminal UE y un servidor de aplicación SERV_A. En el modo de realización descrito más adelante, el terminal UE incluye un cliente AC para una aplicación dada y el servidor de aplicación SERV_A incluye un servicio para esta aplicación dada. En este caso, la aplicación se define por la conjunción de funcionamiento del cliente y del servicio asociado que realiza funciones de una aplicación dada.

Son compatibles otras configuraciones con la invención, por ejemplo, cuando dos servicios cooperan o dos clientes cooperan para realizar una función de una aplicación dada. La invención también se refiere a los casos en que las entidades comunicantes comprenden una pluralidad de servicios y de clientes. Se entiende que, dependiendo de las configuraciones consideradas, el servidor de aplicación SERV_A puede comprender una parte de cliente.

La fig. 1 representa una red de INTERNET a la que está conectada:

• una primera red local NET1 a partir de una primera pasarela NAT1;

• una segunda red local NET2 a partir de una segunda pasarela NAT2;

• una tercera red local NET0 a partir de una segunda pasarela configurable NAT0.

• un servidor ICE/STUN/TURN, denominado SERV_IST, que implementa al menos uno de los protocolos ICE, STUN o TURN y que ofrece servicios conocidos de asignación de candidatos para equipos dispuestos en una red local y visibles y/o accesible por equipos conectados a la red de INTERNET por medio de una pasarela NAT.

En esta configuración ilustrada en la fig. 1, un servidor de aplicación SERV_A está conectado a la red de INTERNET por medio de la red local NET0 a través de la primera pasarela NAT0. El terminal UE está conectado a la red de INTERNET por medio de una primera red local NET y una pasarela NAT1. En la continuación de la descripción, se detallará el caso de una detección por el terminal UE de una segunda red local NET2 conectada a la red de INTERNET por medio de una segunda pasarela NAT2.

Terminal de UE

En la fig. 1 se ha representado un terminal de usuario UE que incluye un cliente AC. El cliente AC permite realizar una pluralidad de funciones de una aplicación dada. Para comunicarse con un tercero, el cliente se interconecta con un cliente ICE/STUN, denominado IS_CLIENT. Este cliente permite obtener informaciones que permiten establecer un canal de transmisión de datos con un tercero. Por ejemplo, el IS_CLIENT permite obtener una dirección y un puerto a partir de una pasarela NAT para que un tercero exterior a la red local NET1 pueda « verlo ». El cliente IS_CLIENT permite establecer canales de transmisión de datos que soporten una sesión aplicativa para garantizar el funcionamiento de una aplicación implementada por el par {Cliente; Servicio}.

Un terminal de usuario UE incluye como mínimo:

• una calculadora que permite realizar cálculos, comparaciones de campos de mensajes, correlaciones de valores, etc.;

• una memoria que permite almacenar parámetros, datos de identificaciones, etc.;

• al menos una interfaz de datos asociada con al menos un módulo de radio o red que permite transmitir datos en al menos un enlace.

Según un modo de realización, un terminal UE incluye dos módulos de radio/red asociados con dos interfaces de salida del terminal. Esta configuración permite, en particular, establecer enlaces paralelos entre por una parte el terminal UE y por otra parte al menos dos pasarelas NAT para:

• establecer simultáneamente diferentes sesiones aplicativas entre por una parte el terminal UE y por otra parte diferentes servidores de aplicación o;

• permitir un cambio de un canal de transmisión a otro canal de una sesión aplicativa entre el terminal UE y un servidor SERV_A.

A cada una de las interfaces del terminal UE se asocia una dirección local asignada, por ejemplo, por una pasarela NAT1 de una subred local NET1 o por equipos de la red. La fig. 1 ilustra dos direcciones locales asignadas a dos interfaces de red del terminal UE: L/H_S@IP(L1:I1) y L/H_S@IP(L2:I2). Estos últimos son asignados por la red, por ejemplo, una red LTE. En el caso de ejemplo de la fig. 1, el NAT1 asigna la dirección de red S1:s1 a la interfaz de red de la pasarela NAT1.

El terminal puede ser un ordenador, una tableta, un teléfono inteligente, otro servidor, un objeto conectado o cualquier otro equipo electrónico que tenga una interfaz de conexión a una red de datos y un sistema operativo que permita implementar al menos un protocolo de comunicación.

Servidor de Aplicación

La segunda entidad comunicante, en la presente descripción, es un servidor de aplicación denominado SERV_A que comprende medios para implementar una pluralidad de funciones posiblemente de diferentes aplicaciones. Según una realización ejemplar, el servidor de aplicación SERV_A permite implementar un servicio de una aplicación. El servidor de aplicación SERV_A incluye un cliente ICE/STUN, denominado IS_CLlENT, que permite obtener informaciones que permiten establecer canales de transmisión de datos que soportan al menos una sesión aplicativa entre el cliente del terminal UE y el servicio alojado por el servidor de aplicaciones SERV_A.

Según un modo de realización, se puede acceder al servidor de aplicaciones SERV_A a través de una pasarela NAT configurable y denominada NAT0. La invención es compatible con una arquitectura que incluye diferentes pasarelas NAT en cascada. La invención se refiere en particular a los dos casos siguientes:

• el caso en el que el servidor está conectado a una red local NET0 accesible por medio de al menos un servidor NAT configurable;

• el caso en el que el servidor está conectado directamente a la red de Internet, por ejemplo, cuando el servicio es un servicio WEB.

En este último caso, se implementa un algoritmo de gestión de candidatos directamente dentro del servidor SERV_A. En lo que sigue de la descripción, se detalla el modo de realización en el que el servidor SERV_A está conectado a una pasarela NAT configurable.

El servidor de aplicaciones SERV_A incluye como mínimo:

• una calculadora que permite realizar cálculos, comparaciones de campos de mensajes, correlaciones de valores, etc.;

• una memoria que permite almacenar parámetros, datos de identificación, etc.

• al menos una interfaz de datos asociada con al menos un módulo de radio o red que permite transmitir datos en al menos una interfaz del servidor.

Cuando el servidor de aplicaciones SERV_A se encuentra en una red local NET0 accesible a través de una pasarela NAT0 configurable, esta última permite hacer corresponder al menos una dirección @serv_a del servidor de aplicaciones SERV_A con al menos una dirección pública, llamada « dirección reflexiva del par » y denominada AR-P.

SERVIDOR ICE/STUN/TURN

Para permitir la implementación de una aplicación por el servidor de aplicación SERV_A y por el terminal UE a partir de un servicio y de un cliente respectivamente alojados por este último, el procedimiento de la invención incluye una secuencia de recopilación candidatos acerca de un servidor ICE/STUN/TURN.

Se denominan « candidatos » en la descripción a cualesquiera informaciones o datos relativos a un direccionamiento dinámico o estático o un conjunto de identificadores, tales como:

• el direccionamiento de un equipo de red tal como un servidor, un terminal, una pasarela, un rúter o un conmutador;

• el direccionamiento de un cliente, ya sea que se ejecute en un terminal o en cualquier otro equipo.

Además, según un modo de realización de la invención, las siguientes informaciones se pueden transmitir con los candidatos:

• el identificador de un servicio, ya sea ejecutado en un servidor de aplicación o en cualquier otro equipo;

• El identificador de un protocolo de señalización, protocolo de enrutamiento o cualquier otro protocolo que permita establecer un canal de transmisión entre dos equipos.

Los candidatos pueden ser recopilados, por ejemplo, por un terminal de UE, para:

• configurar la transmisión de un mensaje indicando la dirección de origen y un puerto en el encabezamiento y el cuerpo de una trama emitida;

• configurar una interfaz o un cliente, tal como el cliente IS_CLIENT, para establecer un canal de transmisión entre diferentes entidades comunicantes accesibles a través de pasarelas NAT;

• actualizar una tabla de correspondencia de una pasarela NAT o de un rúter de la red de Internet o de una red local.

Diferentes modos de realización permiten implementar ciertos aspectos de la invención según los tratamientos de los candidatos recopilados por una entidad comunicante acerca de un servidor SERV_IST.

El servidor SERV_IST incluye direcciones de retransmisión para el modo de realización en el que se activa el protocolo TURN. Están indicadas en la fig. 1: R@IP(R1:r1) y R@IP(R2:r2).

Introducción de las etapas del procedimiento

La fig. 2 muestra las principales etapas del procedimiento de la invención. Comprende una primera secuencia SEQ1 para recoger candidatos acerca del servidor SERV_IST por el terminal UE y por el servidor de aplicación SERV_A. Esta primera etapa se detalla en la fig. 3. La fig. 3 también ilustra la etapa de intercambio de candidatos y de validación de los enlaces establecidos entre dos entidades comunicantes.

El procedimiento incluye a continuación una segunda etapa C1/SA1 de establecimiento de un canal de transmisión para establecer una sesión aplicativa entre el terminal UE y el servidor de aplicaciones SERV_A, puede tratarse, por ejemplo, de un servicio de voz en IP. Esta etapa se ilustra en las figs. 4 y 5, incluye la transmisión de candidatos recopilados por el terminal UE en el servidor SERV_A y de un historial de candidatos recogidos por el terminal.

El procedimiento incluye una tercera etapa DETECT en la que el terminal detecta:

• o bien una nueva red local NET2 en la que puede cambiar al menos una comunicación con un tercero a través de una segunda pasarela NAT de esta segunda red local;

• o bien una desconexión y una reconexión a la red local NET1, por ejemplo, después de una desconexión relacionada con la red, como cuando ocurre por ejemplo una desconexión a la red LTE por el hecho de una ausencia de recepción de señal o porque un cronómetro de la pasarela NAT desencadena una desconexión después de la detección de una inactividad en un canal de transmisión establecido.

Esta tercera etapa se ilustra en la fig. 7.

El procedimiento incluye una cuarta etapa CONF_NAT en la que la pasarela NAT se configura automáticamente para establecer un canal de transmisión desde el servidor de aplicación SERV_A al terminal UE a través de una segunda red local NET2. Esta etapa se ilustra en las figs. 8 y 9. De una manera general, la reconfiguración de la pasarela NAT permite conservar, por ejemplo, un identificador SIP o un identificador de una sesión aplicativa después de un cambio de ruta física en la red entre las dos entidades comunicantes. Esto también puede aplicarse a una desconexión y una reconexión del terminal UE a una misma subred.

El establecimiento de un segundo canal de transmisión tiene lugar en una quinta etapa C2/SA1 consecutiva a la etapa de configuración CONF_NAT de la pasarela NAT sin que se efectúe una modificación de los candidatos de la sesión aplicativa previamente establecida desde el punto de vista del servidor SERV_A que siempre se comunica con el cliente IS_CLIENT con la misma dirección asignada por la NAT0. Esta etapa se ilustra en las figs. 8 y 9.

Descripción detallada de las principales etapas del procedimiento.

Primera etapa: SEQ1

- Recopilaciones de los candidatos.

La fig. 3 representa las principales etapas de intercambio de datos de una secuencia SEQ1 llamada « de intercambio de candidatos » entre un servidor ICE/STUN/TURN y un terminal UE. Dicha secuencia SEQ1 se conoce parcialmente por el estado de la técnica y constituye una primera etapa del procedimiento de la invención. Se sabe por el estado de la técnica cómo se lleva a cabo una primera recopilación de candidatos entre un primer equipo de UE y un servidor SERV_IST, luego entre un segundo equipo SERV_A y el servidor SERV_IST y finalmente entre el primer equipo UE y el segundo equipo SERV_A.

El procedimiento es particularmente ventajoso porque esta secuencia SEQ1 incluye una mejora con respecto al estado de la técnica. En efecto, la mejora consiste en que el terminal UE comunica un historial de candidatos recopilados en el pasado durante conexiones anteriores entre el primer equipo de UE y el segundo equipo SERV_A. Esta ventaja, como se detalla a continuación, permite configurar la pasarela NAT0 para garantizar una continuidad de funcionamiento de mejor calidad, en particular en lo que respecta al mantenimiento de la conexión lógica de la sesión aplicativa entre el cliente y el servidor que realizan la aplicación.

La etapa SEQ1 se refiere a la recogida de candidatos acerca del servidor SERV_IST por el terminal UE y por el servidor de aplicación SERV_A.

En el preámbulo, se observa que los candidatos recopilados de acuerdo con la aplicación implementada y/o la sesión de medios que se establecerá pueden incluir al menos un candidato entre los cuales:

- una dirección IP local y un puerto;

- una dirección IP privada del servidor de aplicación SERV_A y un puerto transpuesto por una pasarela NATx de la red, esta dirección también se denomina « dirección reflexiva » del servidor;

- una dirección IP pública del servidor de aplicación SERV_A y un puerto transpuesto por una pasarela NATx de la red, esta dirección también se denomina « dirección reflexiva del par » del servidor;

- una dirección de retransmisión y un puerto del servidor SERV_IST cuando se implementa el protocolo TURN.

En particular, los candidatos del terminal UE comprenden, por ejemplo:

- una dirección IP local y un puerto del terminal UE;

- una dirección privada IP del terminal UE y un puerto transpuesto por una pasarela NATx de la red, esta dirección también se denomina « dirección reflexiva » del terminal UE;

- una dirección IP pública del terminal UE y un puerto transpuesto por una pasarela NAT0 de la red, esta dirección también se denomina « dirección reflexiva del par » del terminal UE;

- una dirección de retransmisión y un puerto del terminal UE retransmitido por el servidor SERV_IST cuando se implementa el protocolo TURN.

El terminal UE genera una primera solicitud REQ al servidor ICE/STUN/TURN con el fin de recuperar, por ejemplo, una dirección IP y un puerto para que sean visibles y accesibles desde un equipo conectado a la red INTERNET más allá de la red. NET1 local. Este modo de funcionamiento corresponde al funcionamiento del protocolo STUN en el que los candidatos son transmitidos al terminal UE.

Según otro modo de realización que implica la implementación del protocolo TURN, los candidatos comprenden las direcciones de retransmisión del servidor SERV_IST. En este último caso, las interfaces de retransmisión del servidor SERV_IST se utilizan para llegar a un equipo de terceros. Este modo de realización no se detalla, sin embargo, el procedimiento de la invención también se refiere a su implementación. El experto en la técnica puede adaptar fácilmente las etapas de la invención a la implementación de una configuración que implica un protocolo TURN.

En un modo de realización en el que el protocolo STUN se implementa en la etapa de recopilación de candidatos, etapa también conocida como « recopilación de candidatos ICE », los candidatos comprenden al menos una dirección IP y un puerto.

En esta etapa de recopilación, la solicitud REQ que considera solicitar los candidatos acerca del servidor SERV_IST puede incluir la recopilación de varios candidatos para implementar diferentes sesiones de medios entre el terminal UE y uno o más servidores de aplicaciones SERV_A. Estos candidatos son reenviados en un mensaje por el servidor IST al terminal UE y al servidor s Er V_A, en particular en otra etapa de recopilación iniciada por el servidor SERV_A.

El terminal UE puede, en una segunda ocasión, intercambiar los candidatos con la pasarela NAT1 de su red local. La pasarela NAT1 puede utilizar, en particular los candidatos, para definir una dirección pública y actualizar la tabla de correspondencia entre las direcciones públicas y privadas del equipo de la red local NET1. El terminal UE incluye un cliente IS_CLIENT que permite obtener las informaciones que permiten establecer un canal de transmisión con un tercero que incluya un cliente similar. La dirección IP de origen y el puerto se pueden generar en los encabezamientos y, si es necesario, en el cuerpo de los mensajes enviados a un tercero más allá de la red local NET1.

La secuencia SEQ1 incluye una etapa similar de recopilación de candidatos por el servidor de aplicaciones SERV_A acerca del servidor IST o de un servidor SERV_IST duplicado.

- Intercambio de candidatos UE-SERV_A

Se recuerda que los candidatos pueden concernir a diferentes sesiones de medios, diferentes aplicaciones, un protocolo de señalización y/o las direcciones IP y puertos de las interfaces, etc.

Por ejemplo, un enlace de aplicación que define una sesión aplicativa establecida entre el terminal UE y el servidor SERV_A puede requerir la transferencia de los candidatos desde el terminal UE al servidor SERV_A y viceversa. En consecuencia, según la aplicación, la elección y la configuración de las emisiones de candidatos entre las dos entidades son generadas por el cliente y el servicio que realizan la aplicación.

La secuencia SEQ1 incluye por tanto una etapa SBR de intercambio de candidatos entre el terminal UE y el servidor de aplicación SERV_A. Cuando el terminal UE emite los candidatos y un historial de estos últimos al servidor SERV_A, este último provoca la transmisión de la dirección reflexiva del servidor SERV_IST entre la pasarela configurable NAT0 y la primera pasarela NAT1.

Más precisamente, según el procedimiento de la invención, esta secuencia SEQ1 incluye una transmisión por la primera entidad UE de un historial de candidatos asignados a la primera entidad UE hacia el servidor de aplicación s Er V_A. Este historial incluye las diferentes asignaciones de direcciones que el UE ha utilizado previamente de manera que el servidor sea capaz de usarlas para configurar la pasarela NAT0 configurable según sea necesario.

- Validación de los pares

Esta secuencia SEQ1 incluye, además, una etapa de verificación CHKc de los canales entre pared de candidatos establecidos entre la primera entidad UE y el servidor de aplicaciones SERV_A. Esta etapa consiste en verificar el emparejamiento de los candidatos probando el enlace IP o el enlace descriptivo, por ejemplo establecido a partir de un protocolo SIP. Finalmente, la sesión aplicativa también se puede verificar.

Cuando se establecen todos los enlaces, el procedimiento de la invención implementa una etapa de validación de la conectividad de estos últimos. Por ejemplo, una solicitud STUN: « Solicitud de Enlace STUN » se puede emitir desde el terminal UE al servidor SERV_A para cada candidato.

El servidor SERV_A reenvía una respuesta, como por ejemplo una « RESPUESTA DE ENLACE STUN ». Esta etapa permite el descubrimiento de la dirección reflexiva del par del terminal UE, es decir, M_UE:m_ue, según lo asignado por la pasarela NAT0.

El servidor SERV_A puede transmitir entonces una dirección pública del servidor generado por la pasarela configurable de la NAT0 denominada AR-P.

Al final de esta primera secuencia SEQ1, el terminal UE y el servidor de aplicación SERV_A pueden alcanzar en la medida en que los candidatos, es decir, las direcciones y puertos del equipo de terceros, sean equipos conocidos en su red local, respectivamente NET0 y NET1. La segunda etapa C1/SA1 del procedimiento comienza entonces para desembocar en el establecimiento de una sesión aplicativa SA1 en el canal de transmisión C1. Durante el establecimiento de los enlaces entre el terminal UE y el servidor de aplicación SERV_A, las pasarelas NAT1 y NAT0 que se atraviesan transponen las direcciones locales en direcciones públicas. El cliente IS_CLIENT asociado con una aplicación de un equipo permite generar las direcciones de los campos necesarios en los encabezamientos y el cuerpo de los paquetes que se transmiten al equipo de terceros para que este sea « visto » correctamente y alcanzado por este tercero.

Segunda etapa: C1/SA1

La fig. 4 representa la segunda etapa del procedimiento de la invención C1/SA1 que incluye el establecimiento de un canal de transmisión C1 y de una sesión aplicativa SA1 entre el servidor de aplicación SERV_A y el terminal UE. En el ejemplo de la fig. 4, el establecimiento del canal C1 implementa un protocolo de señalización SIP para la implementación de una sesión aplicativa SA1 que incluye una solicitud y una respuesta. Se señala que la invención no se limita a la implementación del protocolo SIP y que también se refiere a cualquier otro tipo de protocolo que no sea el protocolo SIP. Se puede tratar, por ejemplo, de una solicitud de INVITE del protocolo SIP que permite a un cliente solicitar una nueva sesión, también se puede tratar de una solicitud de REGISTER que permite el registro de un cliente acerca de un servicio del servidor u de otro servidor. Al establecer estos intercambios, el procedimiento de la invención permite transmitir los candidatos SIP anteriores al servidor de aplicaciones SERV_A. En este caso de figura, el terminal UE y la aplicación están configurados para transmitir el historial de los candidatos previamente utilizados al servidor de aplicaciones SERV_A.

Además del historial de candidatos, el establecimiento de transmisión C1 también puede comprender los identificadores de aplicaciones anteriores o los identificadores SIP, o cualquier otro candidato, que se hayan intercambiado entre el terminal UE y el servidor SERV_A. Como hemos visto anteriormente, en el marco de la implementación del protocolo SIP en la invención, los identificadores SIP anteriores que han servido para establecer enlaces previos entre el terminal UE y el servidor SERV_A pueden transmitirse en este historial.

El servidor de aplicaciones SERV_A puede emitir una respuesta al terminal UE para finalizar el establecimiento de un canal de transmisión C1 y de la sesión aplicativa SA1. En el caso en que se implementa el protocolo SIP, el SERV_A puede emitir una respuesta OK. El cuerpo del mensaje puede formalizarse según un protocolo XML o SDP o cualquier otro protocolo que permita transmitir un flujo de informaciones de una entidad comunicante a otra.

El establecimiento del canal de transmisión puede comprender la implementación de una pluralidad de pares de enlaces correspondientes a una pluralidad de capas de protocolo activadas entre el terminal UE y el servidor de aplicación SERV_A.

Un interés es transmitir una dirección pública AR-P del servidor SERV_A al terminal UE y/o a la pasarela NAT1 que sigue siendo idéntica habida cuenta que un tratamiento de los candidatos recopilados en los enlaces pasados por el procedimiento de la invención permitirá conservar un enlace lógico. Esta posibilidad permite, en particular, asociar la misma dirección AR-P a nuevos candidatos detectados de un equipo que ya ha establecido un enlace previamente con el servidor de aplicación SERV_A.

En efecto, la dirección pública del terminal UE puede cambiar potencialmente, por ejemplo, cuando el terminal UE es visto o detectado por otra red local NET2. Un efecto particularmente interesante obtenido por la invención reside en el mantenimiento de al menos una sesión aplicativa que puede implementarse por el hecho de la configuración de la NAT configurable.

El procedimiento de la invención comprende una tercera etapa DETECT que tiene como consecuencia que la pasarela configurable NAT0 es capaz de percibir el terminal UE a partir de otro enlace físico distinto del enlace que se ha establecido previamente en la segunda etapa, en particular en lo que se refiere a la dirección de origen que le es asignada por una segunda pasarela NAT2 o posiblemente por la primera pasarela NAT1, cuando este nuevo enlace físico es consecuencia de una desconexión.

Existen al menos dos modos de realización de la invención que corresponden a dos tipos de escenarios que se pueden considerar.

En un primer caso, el terminal UE detecta o es detectado por una segunda red local NET2. El procedimiento de la invención permite realizar una báscula de al menos una sesión aplicativa desde un primer canal de transmisión a un segundo canal de transmisión, uniendo dichos canales el terminal UE a un servidor de aplicación SERV_A.

En un segundo caso, el terminal UE se desconecta de la primera red por cualquier razón y luego se vuelve a conectar. En este segundo caso, se debe volver a editar la etapa de recopilación de candidatos del servidor SERV_IST.

Estos dos modos apuntan a restaurar un segundo enlace físico entre el terminal UE y el servidor de aplicación SERV_A. El primer modo se describe en la continuación de la descripción. El experto en la técnica adaptaría fácilmente el primer modo al segundo modo.

Cuando el terminal UE detecta una segunda red local NET2, por ejemplo, una red WIFI, el cliente IS_CLIENT del terminal UE procede a una segunda recopilación de candidatos acerca del servidor SERV_IST por medio de la pasarela NAT2. Esta etapa se muestra en la fig. 7. Las etapas ya descritas en la secuencia SEQ 1 son similares a las etapas realizadas por el terminal UE con el servidor SERV_IST. Los candidatos anteriores asignados al terminal UE se vuelven a emitir así en esta secuencia SEQ1, completan un historial de candidatos ya recopilados por el terminal UE.

Durante el establecimiento del segundo canal de transmisión C2, esta etapa se representa en las figs. 8 y 9, los candidatos se intercambian entre el terminal UE y el servidor SERV_A. Esta etapa es similar al intercambio de los candidatos realizado para establecer el canal C1.

El servidor de aplicaciones SERV_A puede transmitir a la pasarela configurable NAT0 datos relacionados con los candidatos recopilados y el historial de estos candidatos que proviene del establecimiento del segundo canal C2. El procedimiento de la invención incluye entonces una etapa de configuración de la pasarela NAT0.

Según un primer modo de realización, la pasarela NAT0 puede reconfigurar estas tablas de correspondencias a partir del historial de los candidatos transmitidos y de un algoritmo de priorización alojado e implementado por la pasarela NAT0. La configuración de la pasarela NAT0 está activa.

Según un segundo modo de realización, la tabla de correspondencias de las direcciones de la pasarela NAT0 se actualiza a partir de una consigna generada por el servidor de aplicaciones SERV_A.

La pasarela NAT0 realiza los cálculos para reconfigurar las tablas de correspondencias, en particular con las direcciones públicas y los puertos, a partir de las informaciones provenientes de SERV_A.

Por ejemplo, puede tratarse de un identificador de aplicación o de un identificador SIP. La configuración de la pasarela NAT0 es en este caso pasiva.

El procedimiento de la invención se refiere a estos dos modos de realización.

En el primer modo de realización, la pasarela NAT reconfigura sus tablas de correspondencia a partir de los nuevos candidatos transmitidos por el terminal UE al servidor SERV_A y luego emitidos desde el servidor s ErV_A a la pasarela NAT0. El algoritmo de priorización implementado por la pasarela NAT0 permite determinar a partir del historial de los candidatos transmitidos si el terminal UE ya ha establecido una sesión aplicativa o un descubrimiento SIP.

En este último caso, la pasarela NAT0 modifica estas tablas de correspondencias entre direcciones públicas y direcciones privadas mediante la transposición de la dirección pública del servidor AR-P como dirección de origen del servidor SERV_A para el nuevo canal de transmisión C2 establecido entre el terminal UE y el servidor SERV_A. Un interés es mantener los identificadores o las direcciones asignados para establecer las sesiones de aplicación entre el terminal UE y el servidor SERV_A que estaban activas a través del canal C1. Por lo tanto, una ventaja es ofrecer una continuidad de servicio a nivel de aplicación durante un cambio de la red local NET1 a NET2, por ejemplo, cuando el terminal UE está sujeto a movilidad.

Claims (7)

REIVINDICACIONES

1. Procedimiento de comunicación entre una primera entidad comunicante (UE) conectada a una primera red (INTERNET) a través de una primera pasarela NAT (NATI) de una primera red local (NET1) y un servidor de aplicación (SERV_A), estando asociado dicho servidor de aplicación (SERV_A) con una pasarela NAT configurable (NAT0) que permite hacer corresponder al menos una dirección de al menos la primera pasarela NAT (NAT1, NAT2) con al menos una dirección pública (S1, S2) de la primera entidad comunicante (UE), llamada dirección reflexiva del par (AR-P), que incluye las siguientes etapas:

• Establecimiento de una primera secuencia de intercambio de candidatos (SEQ1), comprendiendo dichos candidatos al menos una dirección IP y un puerto, que incluye:

o Una recopilación de candidatos por la primera entidad (UE) acerca de un servidor que implementa los protocolos ICE, STUN o TURN para ser alcanzado por un servidor remoto (SERV_A) por medio de la primera pasarela NAT (NAT1);

o Un intercambio de candidatos entre la primera entidad (UE) y el servidor de aplicaciones (SERV_A) que provoca la transmisión de la dirección reflexiva del par (AR-P) entre la pasarela NAT configurable (NAT0) y la primera pasarela (NAT1);

o Una transmisión por la primera entidad (UE) de un historial de candidatos asignados a la primera entidad (UE) al servidor de aplicaciones (SERV_A);

o Verificación de los canales entre pares de candidatos establecidos entre la primera entidad (UE) y el servidor de aplicaciones (SERV_A);

• Generación de un primer canal de transmisión que garantiza el establecimiento de una primera sesión aplicativa (SA1);

• Detección por la primera entidad comunicante (UE) de una nueva red de acceso (NET2) que incluye una segunda pasarela NAT (NAT2) o de una reconexión a la primera red de acceso (NET1) posterior a una desconexión, lo que provoca el establecimiento de una segunda secuencia de intercambios (SEQ2) de nuevos candidatos que incluye etapas similares a la primera secuencia (SEQ1);

• Configuración automática de la pasarela configurable (NAT0) mediante una función del servidor de aplicación (SERV_A) para modificar la correspondencia entre la dirección de origen de la primera o de la segunda pasarela NAt (NAT1, NAT2) con la dirección reflexiva del par (AR-P) de la pasarela Na T configurable (NAT0) a partir del historial de los candidatos transmitidos por la entidad comunicante (UE);

• Generación de un segundo canal de transmisión entre la primera entidad comunicante (UE) y el servidor de aplicación (SERV_A) garantizando el mantenimiento de la primera sesión aplicativa (SA1).

2. Procedimiento de comunicación según la reivindicación 1, caracterizado por que los candidatos incluyen, además de una dirección IP y un número de puerto:

o Un identificador de aplicación y/o;

o Un identificador SIP.

3. Procedimiento de comunicación según cualquiera de las reivindicaciones 1 a 2, caracterizado por que la sesión aplicativa incluye un identificador de aplicación de la entidad comunicante (UE) asociada con un identificador de aplicación del servidor de aplicación (SERv_A), un mantenimiento de una sesión aplicativa que implica el mantenimiento de la asociación de los identificadores de aplicación.

4. Procedimiento de comunicación según cualquiera de las reivindicaciones 1 a 3, caracterizado por que el establecimiento de la primera y la segunda secuencia de intercambios de candidatos (SEQ1) incluyen sucesivamente:

• Un intercambio de candidatos de un protocolo de señalización entre la entidad comunicante (UE) y el servidor de aplicación (SERV_A);

• Un intercambio de candidatos de un protocolo de aplicación entre un cliente de la entidad comunicante (UE) y un cliente del servidor de aplicación (SERV_A);

• Un intercambio de candidatos de un protocolo de enrutamiento entre la primera o la segunda pasarela NAT (NAT1, NAT2) y la pasarela configurable (NAT0).

5. Procedimiento de comunicación según cualquiera de las reivindicaciones 1 a 4, caracterizado por que la pasarela NAT comprende un reloj que permite determinar las duraciones durante las cuales no se transmite ningún dato en el canal de transmisión (C1), permitiendo dicha duración generar un indicador de prioridad asignado a un candidato almacenado en la pasarela y asociado con un terminal (UE).

6. Sistema de comunicación que incluye un servidor de aplicación (SERV_A) que incluye al menos un cliente de aplicación y una pasarela NAT configurable (NAT0), pudiendo realizar dicho servidor de aplicaciones (SERV_A) un intercambio de candidatos que comprenden al menos una dirección IP y un puerto, con una entidad comunicante remota (UE) bajo solicitud por medio de la pasarela NAT, asignando dicha pasarela NAT configurable (NAT0) una dirección pública al servidor de aplicación (SERv_A), llamada dirección reflexiva del par (AR-P), estando asociada esta dirección con la entidad de comunicación remota (UE), de manera que establezca un primer canal de transmisión que garantice el establecimiento de una primera sesión aplicativa (SA1), caracterizado por que una nueva solicitud de intercambio de candidatos que incluye un historial de los candidatos anteriores recibido de una misma entidad comunicante hacia el servidor de aplicación (SERV_A) provoca una configuración de la pasarela NAT configurable (NAT0) para modificar la asociación entre al menos un candidato transmitido y la dirección reflexiva del par (AR-P) de la pasarela NAT configurable (NAT0), estableciendo el sistema un segundo canal de transmisión entre la entidad comunicante y el servidor de aplicación (SERV_A) que garantiza el mantenimiento de la primera sesión aplicativa (SA1).

7. Entidad comunicante (UE) que incluye al menos un módulo de radio o red que permite transmitir datos en al menos una interfaz de dicho terminal (UE) conectado a una red, incluyendo dicha entidad de comunicación (UE) una memoria en la que se registra un historial de candidatos, que comprende al menos una dirección IP y un puerto, y está registrado y asociado con un servidor de aplicaciones (SERV_A), siendo recopilados dichos candidatos, por ejemplo, acerca de un servidor que implementa uno de los protocolos ICE, STUN o TURN (SERV_IST), incluyendo dicha entidad de comunicación (UE) al menos una calculadora para insertar en al menos una trama de un protocolo SIP un campo de datos que incluyen el historial de los candidatos recopilados y memorizados tan pronto como se genera un canal de transmisión entre dicho terminal (UE) y un servidor de aplicación (SERV_A) , incluyendo dicha entidad de comunicación (UE) dos módems que permiten detectar la presencia de al menos dos redes de acceso (NET1, NET2) y generar dos canales de transmisiones en paralelo en los que una sesión aplicativa establecida entre dicho terminal de usuario (UE) y un servidor de aplicación (SERV_A) cambia de un canal de transmisión a otro mientras se mantiene un mismo identificador de sesión.