ES2587913T3 - Procedimiento y equipo con múltiples conexiones físicas ("multi-homed") para establecer una conexión multi-trayecto - Google Patents
Procedimiento y equipo con múltiples conexiones físicas ("multi-homed") para establecer una conexión multi-trayecto Download PDFInfo
- Publication number
- ES2587913T3 ES2587913T3 ES13193319.4T ES13193319T ES2587913T3 ES 2587913 T3 ES2587913 T3 ES 2587913T3 ES 13193319 T ES13193319 T ES 13193319T ES 2587913 T3 ES2587913 T3 ES 2587913T3
- Authority
- ES
- Spain
- Prior art keywords
- connection
- equipment
- path
- auxiliary
- main
- 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
- 238000000034 method Methods 0.000 title claims abstract description 29
- 238000004891 communication Methods 0.000 claims abstract description 132
- 230000005540 biological transmission Effects 0.000 claims description 5
- 238000010586 diagram Methods 0.000 description 7
- 101150012579 ADSL gene Proteins 0.000 description 2
- 102100020775 Adenylosuccinate lyase Human genes 0.000 description 2
- 108700040193 Adenylosuccinate lyases Proteins 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 101100108136 Drosophila melanogaster Adck1 gene Proteins 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/52—Multiprotocol routers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
-
- 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/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/14—Multichannel or multilink protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Un procedimiento para establecer una conexión multi-trayecto a través de múltiples trayectos de comunicación entre dos equipos (C, S), primero y segundo, dentro de al menos una red (N) de comunicación, en el que los dos equipos son compatibles con un protocolo multi-trayecto, que comprende: - enviar (E1), desde el primer equipo (C), solicitudes (1) de establecimiento de conexión principal a través de al menos dos trayectos de comunicación entre dichos equipos (C, S) primero y segundo; - recibir (E2), desde el segundo equipo (S), al menos un mensaje (2) de acuse de recibo a través de uno de dichos trayectos de comunicación; - determinar (E3), en el primer equipo (C), como un trayecto de comunicación principal, el trayecto de comunicación mediante el que el primero de dichos al menos un mensaje (2) de acuse de recibo desde el segundo equipo (S) ha sido recibido por el primer equipo (C), con el fin de establecer la conexión principal de dicha conexión multi-trayecto a través de dicho trayecto de comunicación principal; - enviar (E5), desde el primer equipo (C), una solicitud (RST) de reinicio a través de cada uno de los trayectos de comunicación auxiliares, que difieren del trayecto de comunicación principal determinado, para anular la conexión a lo largo de esos trayectos de comunicación auxiliares.
Description
5
10
15
20
25
30
35
40
45
50
DESCRIPCION
Procedimiento y equipo con multiples conexiones ffsicas (“multi-homed”) para establecer una conexion multi-trayecto
La presente invention se refiere a la transmision de paquetes de datos entre unos equipos con multiples conexiones ffsicas (“multi-homed”), primero y segundo, a traves de una o mas redes de comunicacion.
En particular, la presente invencion se refiere, aunque no exclusivamente, al establecimiento de una conexion multi- trayecto que funciona bajo el protocolo de control de transmision multi-trayecto (MultiPath Transmission Control Protocol, MPTCP) sobre el protocolo de Internet (Internet Protocol, IP) entre un primer equipo “multi-homed” y un segundo equipo “multi-homed” remoto. El protocolo MPTCP se define en el proyecto "TCP Extensions for Multipath Operation with Multiple Addresses” (A. Ford et. Al.), publicado el 25 de Abril de 2012 por el grupo de trabajo de ingeniena de Internet (Internet Engineering Task Force).
En el marco de la presente invencion, debena entenderse por:
- "Equipo multi-homed", un equipo que comprende al menos dos interfaces de comunicacion (por cable y/o inalambricas), en el que cada interfaz tiene su propia direction de comunicacion (tal como por ejemplo una direction IP), con el fin de poder intercambiar paquetes de datos con un equipo de comunicacion remoto (posiblemente de un tipo diferente) en el modo multi-trayecto. Por consiguiente, el equipo “multi-homed” puede implicar un telefono fijo o movil (posiblemente de tipo "telefono inteligente"), un ordenador fijo o portatil, un asistente digital personal (Personal Digita Assistant, PDA), un receptor de contenidos (tal como un decodificador, una puerta de enlace residencial o un dispositivo decodificador (Set-Top Box, STB)), o un elemento de equipo de red, tal como un servidor de contenidos;
- "Trayecto de comunicacion", un trayecto que conecta dos equipos de comunicacion (posiblemente “multihomed”) gracias a dos interfaces de comunicacion (una por equipo), de manera que un trayecto de comunicacion sera identificado por el par de direcciones de comunicacion de las dos interfaces de comunicacion correspondientes; y
- "Sub-flujo", un flujo de paquetes TCP que operan sobre un solo trayecto, que forma parte de una conexion MPTCP mas grande. Un sub-flujo de este tipo es iniciado y terminado de manera similar a una conexion TCP regular.
Ademas, el protocolo MPTCP es una extension del protocolo TCP regular para proporcionar un servicio TCP multi- trayecto y, especialmente, para ser compatible con el uso concurrente de multiples direcciones IP de un equipo “multihomed”. El protocolo MPTCP permite que una conexion de transporte funcione a traves de multiples trayectos simultaneamente de una manera compatible con equipos “multi-homed”, disenados inicialmente para ser compatible con una conexion TCP de un unico trayecto.
Una conexion MPTCP entre un primer equipo “multi-homed” y un segundo equipo “multi-homed” se compone normalmente de una conexion TCP regular principal asociada con un trayecto de comunicacion principal y una o mas conexiones TCP auxiliares (vinculadas a la conexion TCP regular principal) que estan asociadas con los trayectos de comunicacion auxiliares. Dicha una conexion MPTCP sigue apareciendo como una unica conexion TCP para las aplicaciones en ambos extremos. Ademas, tal como ya se conoce, un equipo “multi-homed” (compatible con la implementation del protocolo MPTCP (denominado tambien MPTCP compatible)) tiene normalmente una interfaz de comunicacion fija asignada como la interfaz principal a ser usada para iniciar una conexion MPTCP. Con el fin de ser eficaz, esta interfaz principal debena estar conectada al trayecto de comunicacion mas rapido o mas fiable de entre los trayectos disponibles que conducen a un segundo equipo “multi-homed” remoto.
Sin embargo, si el trayecto principal entre el primer equipo y el segundo equipo se interrumpe temporalmente o es inusualmente lento cuando se inicia la conexion MPTCP, el retraso para establecer dicha una conexion MPTCP sera largo, con los inconvenientes de retrasar el establecimiento de la conexion MPTCP o conduciendo, en el peor de los casos, a un fallo de esta ultima. Ademas, podrfa retrasar tambien el establecimiento de las conexiones auxiliares, ya que los requisitos del protocolo MPTCP especifican que la conexion TCP principal estara en un estado establecido antes de iniciar las conexiones auxiliares.
La presente invencion propone una solucion para superar al menos algunas de las desventajas indicadas anteriormente. Las soluciones conocidas en la tecnica son:
El documento de la tecnica anterior “Improvement of SCTP Performance during Handshake Process” (Cheng-feng Tai, Lin-huang Chang y Ting-wei Hou. 22a Conference on Advanced Information Networking and Applications - AINA 2008, IEEE Workshops) presenta el establecimiento de una conexion multi-trayecto entre dos dispositivos que son compatibles con un protocolo multi-trayecto mediante el envfo de solicitudes de establecimiento de conexion principal a traves de al
5
10
15
20
25
30
35
40
45
menos dos trayectos de comunicacion y mediante la determinacion como el trayecto de comunicacion principal, el primero que envfa un mensaje de acuse de recibo de vuelta a dicha solicitud.
De manera similar, en el documento “Evaluation of Concurrent Multipath Transfer over Dissimilar Paths” (Hakim Adhari. Thomas Dreibholz, Martin Becke, Erwin P. Rathgeb, AINA 2011, IEEE Workshops) se muestra un analisis con relacion al transporte multi-trayecto en el establecimiento de un trayecto disimilar en el mundo real por medio de los protocolos SCTP y MPTCP para dispositivos con varias direcciones IP, en las que se selecciona un primer trayecto y todos los demas trayectos permanecen como respaldo y solo se usan en caso de fallos.
Ademas, en un contexto similar de conexiones multi-trayecto entre dos dispositivos que son compatibles con un protocolo multi-trayecto, el documento US2007005787 (Gareshi Ken, Saito y Kentaro Ochi Daisuke, NTT DOCOMO, 2007) presenta el envfo de solicitudes de reserva de cancelacion para aquellos trayectos desde los que no se ha recibido ninguna senal de acuse de recibo y que cumplen una determinada condicion de orden de secuencia.
La invention se refiere a un procedimiento para establecer una conexion multi-trayecto a traves de multiples trayectos de comunicacion entre un primer equipo y un segundo equipo (por ejemplo, “multi-homed”) dentro de al menos una red de comunicacion, en el que ambos equipos son compatibles con un protocolo multi-trayecto.
Segun la presente invencion, dicho procedimiento es resenable en el sentido de que comprende las etapas sucesivas de:
- enviar, desde el primer equipo, solicitudes de establecimiento de conexion principal a traves de al menos dos trayectos de comunicacion entre dicho primer equipo y dicho segundo equipo;
- recibir, desde el segundo equipo, al menos un mensaje de acuse de recibo a traves de uno de dichos trayectos de comunicacion; y
- determinar, en el primer equipo, como un trayecto de comunicacion principal, el trayecto de comunicacion mediante el cual el primer mensaje de dichos al menos un mensaje de acuse de recibo desde el segundo equipo ha sido recibido por el primer equipo, con el fin de establecer la conexion principal de dicha conexion multi- trayecto a traves de dicho trayecto de comunicacion principal.
De esta manera, gracias a la presente invencion, el primer equipo “multi-homed” es capaz de descubrir (preferiblemente de manera automatica) el trayecto mas rapido disponible en el momento del establecimiento de conexion multi-trayecto para considerarlo como el trayecto principal para la conexion multi-trayecto. Entonces, puede reducirse el tiempo necesario para establecer una conexion multi-trayecto.
En una realization preferida, el procedimiento comprende ademas las etapas de:
- enviar, desde el primer equipo, un mensaje de acuse de recibo junto con un primer mensaje de datos a traves de dicho trayecto de comunicacion principal determinado; y
- recibir, desde el segundo equipo, un mensaje de acuse de recibo de establecimiento para establecer la conexion principal de dicha conexion multi-trayecto entre el primer equipo y el segundo equipo.
En un primer aspecto, dicho procedimiento puede comprender ademas la etapa de enviar, desde el primer equipo, una solicitud de reinicio a traves de cada uno de los trayectos de comunicacion auxiliares, que difieren del trayecto de comunicacion principal determinado, para anular la conexion a lo largo de esos trayectos de comunicacion auxiliares.
En un segundo aspecto, dicho procedimiento puede comprender ademas las etapas de:
- enviar, desde el primer equipo, una solicitud de establecimiento de conexion auxiliar a traves de al menos uno de los trayectos de comunicacion auxiliares;
- recibir, desde el segundo equipo, al menos un mensaje de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar; y
- enviar, desde el primer equipo, un mensaje de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar, de manera que se establezca una conexion auxiliar de dicha conexion multi-trayecto entre el primer equipo y el segundo equipo a traves de dicho trayecto de comunicacion auxiliar.
En un tercer aspecto, dicho procedimiento puede comprender ademas las etapas de:
- enviar, desde el primer equipo, un mensaje de information representativo de los posibles trayectos de comunicacion auxiliares del primer equipo, a traves de dicho trayecto de comunicacion principal;
- recibir, desde el segundo equipo, una solicitud de establecimiento de conexion auxiliar a traves de al menos uno
5
10
15
20
25
30
35
40
45
de los trayectos de comunicacion auxiliares;
- recibir, desde el primer equipo, al menos un mensaje de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar; y
- enviar, desde el segundo equipo, un mensaje de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar, de manera que se establezca una conexion auxiliar de dicha conexion multi-trayecto entre el primer equipo y el segundo equipo a traves de dicho trayecto de comunicacion auxiliar.
De manera ventajosa, dichas solicitudes de establecimiento de conexion principal pueden ser enviadas de manera esencialmente simultanea por el primer equipo.
Preferiblemente, el protocolo multi-trayecto es el protocolo de control de transmision multi-trayecto sobre el protocolo de Internet.
En otro aspecto, dicho procedimiento puede comprender la etapa de enumerar los trayectos de comunicacion entre el primer equipo y el segundo equipo, segun al menos un criterio de rendimiento.
La presente invention se refiere tambien a un primer equipo (por ejemplo, “multi-homed”) adaptado para establecer una conexion multi-trayecto a traves de multiples trayectos de comunicacion entre dicho primer equipo “multi-homed” y un segundo equipo “multi-homed” dentro de al menos una red de comunicacion, en el que ambos equipos son compatibles con un protocolo multi-trayecto.
Segun la presente invencion, dicho equipo comprende:
- un emisor configurado para enviar al segundo equipo, solicitudes de establecimiento de conexion principal a traves de al menos dos trayectos de comunicacion entre dichos equipos;
- un receptor configurado para recibir desde el segundo equipo, al menos un mensaje de acuse de recibo a traves de uno de dichos trayectos de comunicacion conocidos;
- un estimador configurado para determinar como un trayecto de comunicacion principal, el trayecto de comunicacion de manera que el primero de dichos al menos un mensaje de acuse de recibo desde el segundo equipo ha sido recibido por dicho primer equipo, con el fin de establecer la conexion principal de dicha conexion multi-trayecto a traves de dicho trayecto de comunicacion principal.
Ademas, el emisor puede estar configurado ademas para enviar al segundo equipo una solicitud de reinicio a traves de cada uno de los trayectos de comunicacion auxiliares, que difiere del trayecto de comunicacion principal determinado, para anular la conexion a lo largo de esos trayectos de comunicacion.
A continuation, se describen ciertos aspectos que corresponden al alcance de las realizaciones. Deberfa entenderse que estos aspectos se presentan meramente para proporcionar al lector un breve resumen de ciertas formas que podrfa adoptar la invencion y que estos aspectos no pretenden limitar el alcance de la invencion.
La invencion se comprendera mejor y se ilustrara por medio de la realization y los ejemplos de ejecucion siguientes, en modo alguno restrictivos, con referencia a las figuras adjuntas entre las que:
- La Figura 1 es un diagrama esquematico de un ejemplo de una red de comunicacion en la que podrfa implementarse la presente invencion;
- La Figura 2 representa esquematicamente las etapas habituales implementadas para establecer una conexion TCP regular entre un equipo cliente y un servidor dentro de la red de comunicacion de la Figura 1;
- Las Figuras 3A y 3B es un diagrama de flujo que ilustra las etapas habituales implementadas para iniciar una conexion MPTCP entre un equipo cliente y un servidor dentro de una red de comunicacion, segun una manera implfcita (Figura 3A) y una manera explfcita (Figura 3B), respectivamente;
- La Figura 4A ilustra las etapas de una realizacion preferida del procedimiento para establecer una conexion multi-trayecto, segun la presente invencion;
- La Figura 4B es un diagrama de flujo del procedimiento segun dicha realizacion preferida; y
- La Figura 5 es un diagrama de bloques de un dispositivo conforme a la presente invencion, que es capaz de implementar el procedimiento tal como se ha descrito en la Figura 4.
Siempre que sea posible, se usaran los mismos numeros de referencia a lo largo de todas las figuras para hacer
5
10
15
20
25
30
35
40
45
50
referencia a las mismas partes o a partes similares.
Segun una realization preferida, la presente invention se representa con respecto al protocolo MPTCP multi-trayecto sobre el protocolo de Internet. Naturalmente, la invencion no se limita a dicha una realizacion particular y, por supuesto, podrfan considerarse e implementarse otros protocolos multi-trayecto.
En la realizacion preferida, se consideran dos equipos “multi-homed” y multi-direction (respectivamente, un cliente C y un servidor S) que se comunican entre sf a traves de una red N de comunicacion (representados en la Figura 1).
Cada equipo C o S es compatible con MPTCP y comprende varias interfaces de conexion identificadas por su direction IP. En el ejemplo particular de las Figuras 1 a 4, el cliente C y el servidor S tienen dos interfaces a las que se hace referencia, respectivamente, como A1, A2 y B1, B2: por lo tanto, hay hasta cuatro trayectos diferentes entre el cliente C y el servidor S, concretamente A1-B1, A1-B2, A2-B1 y A2-B2. Obviamente, en una variante, el numero de interfaces podrfa ser diferente.
En el ejemplo de la Figura 1, el cliente C puede alcanzar el servidor S remoto a traves de Internet a traves de una red de acceso celular y una red de acceso ADSL. La red de acceso celular (por ejemplo, 3G y/o 4G) es accesible directamente por el cliente C, mientras que la red de acceso ADSL es accesible por el cliente C a traves de una puerta de enlace. El cliente C puede comunicarse con dicha una puerta de enlace a traves de interfaces inalambricas y/o por cable (tal como por ejemplo Wi-Fi, Ethernet, etc.).
Tal como se muestra en la Figura 2, el establecimiento de una conexion TCP de trayecto unico entre el cliente C y el servidor S se define generalmente por un protocolo de conexion de tres estados (denominado frecuentemente protocolo de intercambio de tres vfas):
- en un primer estado, el cliente C envfa (flecha 1 en la Figura 2) un paquete (SYN) de sincronizacion (correspondiente a una solicitud de establecimiento de conexion) al servidor S que especifica el numero de puerto del servidor S al cual desea conectarse el cliente C y el numero de secuencia inicial (Initital Sequence Number, ISN) del cliente. Entonces, el cliente C esta en un estado embrionario o inicial (SYN_SENT) y espera una respuesta desde el servidor S. Se representan dos interfaces A1, A2 y B1, B2 de comunicacion para cada equipo S, C;
- en el segundo estado, el servidor S responde (flecha 2) con un paquete (SYN/ACK) de acuse de recibo del primer tipo que contiene el numero de secuencia inicial (ISN) del servidor y un paquete (ACK) de acuse de recibo para el paquete SYN del cliente (que comprende el ISN del cliente mas uno, en el que el paquete SYN consume un numero de secuencia). En este segundo estado, el servidor S esta tambien en un estado embrionario o inicial (SYN_RCVD); y
- en un tercer estado, el cliente C debe enviar (flecha 3) un paquete (ACK) de acuse de recibo del segundo tipo con el ISN del servidor mas uno, para reconocer la reception del paquete SYN desde el servidor S. En este tercer estado, el cliente C entra en un estado de conexion establecida y, tras la recepcion del paquete ACK desde el cliente C, el servidor S entra tambien a un estado de conexion establecida. Entonces, una conexion TCP (A2-B1 en la Figura 2) esta completamente abierta.
Las Figuras 3A y 3B ilustran el establecimiento de una conexion MPTCP entre el cliente C “multi-homed” y compatible con MPTCP y el servidor S “multi-homed” y compatible con MPTCP. Tal como ya se conoce, dicho establecimiento se compone de las tres fases siguientes:
- en una primera fase (representada por las flechas 1 a 3 en las Figuras 3A y 3B), el cliente C inicia una conexion TCP regular, pero los paquetes SYN, SYN/ACK y ACK + DATA enviados transportan ademas una option compatible con multi-trayecto (MP_CAPABLE). Esta opcion permite que el cliente C y el servidor S intercambien cierta information usada para autenticar el establecimiento de conexiones TCP auxiliares (o sub-flujos) y para comprobar si el servidor S remoto es compatible o no con el protocolo MPTCP;
- en una segunda fase (flecha 4), el servidor S compatible con MPTCP debe responder al paquete ACK+DATA de segundo tipo desde el cliente C con un paquete ACK de establecimiento, que puede contener datos o no si no tiene datos a ser enviados inmediatamente. Si el cliente C no recibe dicho un paquete ACK de establecimiento dentro del tiempo de retransmision (Retransmission Timeout, RTO), volvera a enviar el paquete ACK de establecimiento que contiene la opcion MP_CAPABLE. La conexion MPTCP en el lado del cliente esta en un estado pre-establecido (PRE_ESTABLISHED), mientras espera este paquete ACK de establecimiento. Preferiblemente, tras la recepcion del paquete ACK de establecimiento desde el servidor S, el cliente C cambiara a un estado establecido (ESTABLISHED); y
- en una tercera fase (representada respectivamente por las flechas 5A, 6A, 7A en la Figura 3A y por las flechas
5
10
15
20
25
30
35
40
45
50
5B, 6B, 7B, 8 en la Figura 3B), una nueva conexion TCP o varias conexiones TCP nuevas se crean y se vinculan a la conexion TCP principal establecida al final de la primera fase. Basicamente, hay dos procedimientos principales para establecer estas conexiones TCP auxiliares:
• un procedimiento implfcito (Figura 3A), en el que el cliente C inicia (flechas 5A, 6A y 7A) una nueva conexion TCP auxiliar desde una segunda direccion A2 IP a la direccion B1 IP del servidor conocido; y
• un procedimiento explfcito (Figura 3B), en el que el cliente C proporciona (flecha 8) al servidor S las direcciones IP disponibles (en el ejemplo A2) para la conexion MPTCP, de manera que el servidor S inicia (flecha 5B, 6B y 7B) una nueva conexion TCP auxiliar con una de estas direcciones IP disponibles.
En ambos casos (implfcito y explfcito), los paquetes SYN, SYN/ACK y ACK (representados respectivamente por las flechas 5A, 6A y 7A en la Figura 3A y las flechas 5B, 6B y 7B en la Figura 3B) transportan ademas una opcion de union (MP_JOIN).
Ademas, el diagrama de flujo representado en la Figura 4B describe las diversas etapas del procedimiento para establecer una conexion MPTCP entre el cliente C y el servidor S, segun la realizacion preferida de la presente invencion.
En particular, en una etapa E0 preliminar, el cliente C puede obtener los diversos trayectos de comunicacion existentes entre este y el servidor S. En una alternativa, puede imaginarse que el cliente C podrfa conocer ya los trayectos de comunicacion.
En una primera etapa E1, el cliente C envfa de manera esencialmente simultanea paquetes 1 SYN sincronizacion (correspondientes a las solicitudes de establecimiento de conexion) que transportan la opcion MP_CAPABLE al servidor S a traves de todos los trayectos de comunicacion conocidos entre el cliente C y el servidor S. En otras palabras, un paquete SYN que incluye la opcion MP_CAPABLE es transmitido desde el cliente C al servidor S a traves de cada trayecto de comunicacion conocido (A1-B1, A1-B2, A2-B1 y A2-B2 en el ejemplo). En aras de la claridad, solo se ha ilustrado un paquete 1 SYN (MP_CAPABLE) en la Figura 4A.
Obviamente, como una variante, los paquetes SYN podrfan ser enviados a traves de solo algunos de los trayectos de comunicacion conocidos.
En una etapa E2 adicional, el cliente C (que esta en un estado de espera) recibe al menos un paquete 2 SYN/ACK de acuse de recibo de primer tipo que transporta la opcion MP_CAPABLE desde el servidor S a traves de uno de dichos trayectos de comunicacion conocidos.
Tras la recepcion de dicho un paquete 2 SYN/ACK, el cliente C determina, en una etapa E3 adicional, el trayecto mediante el cual el paquete 2 SYN/ACK ha sido recibido primero por el cliente C, como un trayecto de comunicacion principal de la conexion multi-trayecto a establecer.
En una etapa E4 adicional, el cliente C transmite un paquete 3 ADCK+DATA de acuse de recibo de segundo tipo que transporta la opcion MP_CAPABLE al servidor S a traves de dicho transporte de comunicacion principal determinado. Entonces, el cliente se encuentra en un estado preestablecido (PRE-ESTABLISHED).
En una etapa E5 opcional adicional, el cliente C envfa al servidor S una solicitud RST de reinicio a traves de cada uno de los trayectos de comunicacion auxiliares (que no han sido determinados como el trayecto de comunicacion principal de la comunicacion MPTCP multi-trayecto) para cancelar la conexion a lo largo de esos trayectos auxiliares.
En una etapa E6 adicional, el cliente C recibe un paquete 4 ACK de acuse de recibo de establecimiento (enviado por el servidor S tras la recepcion del paquete ACK (MP_CAPABLE) de segundo tipo (para establecer la conexion principal de dicha conexion MPTCP multi-trayecto). Entonces, el cliente C se encuentra en un estado establecido (ESTABLISHED).
En las etapas adicionales (solo representas en la Figura 4A), las conexiones TCP auxiliares (vinculadas a la conexion MPTCP multi-trayecto establecida) podnan ser establecidas segun uno de los dos procedimientos (implfcito o explfcito) descritos anteriormente con referencia a la Figura 3A (flechas 5A, 6A y 7A) y la Figura 3B (flechas 5B, 6B, 7B y 8). El procedimiento implfcito solo se representa en la Figura 4A.
Ademas, podrfa crearse una lista de rendimientos de los trayectos de comunicacion conocidos entre el cliente C y el servidor S, en una etapa E7 adicional, en la que los trayectos de comunicacion conocidos se clasifican segun uno o varios criterios, por ejemplo, la fiabilidad y/o la velocidad de cada trayecto. La lista de rendimientos podrfa ser actualizada periodicamente midiendo el tiempo de ida y vuelta (Round-Trip Time, RTT) y la tasa de error de paquete (Packet Error Rate, PER) de cada trayecto de comunicacion (trayectos principal y auxiliares).
Gracias a dicha lista de rendimientos, el cliente C es capaz de enviar o solicitar datos en un trayecto de comunicacion preferido con el fin de optimizar el intercambio de datos con el servidor S.
5
10
15
20
25
30
35
40
45
Ademas, el diagrama de bloques mostrado en la Figura 5 representa un dispositivo compatible con la presente invencion y que corresponde al cliente C, que es capaz de implementar el procedimiento tal como se ha descrito anteriormente con referencia a las Figuras 4A y 4B.
En particular, el cliente C comprende:
- interfaces A1 y A2 de comunicacion (por cable y/o inalambricas), en el que cada interfaz tiene su propia direccion IP;
- un modulo M1, denominado tambien emisor, configurado para enviar al servidor S al menos:
• solicitudes 1 SYN de establecimiento de conexion principal que transportan la opcion MP_CAPABLE a traves de al menos algunos de los trayectos de comunicacion conocidos, en el que de manera ventajosa dichas solicitudes son enviadas simultaneamente;
• un mensaje 3 ACK+DATA de acuse de recibo de segundo tipo que transporta la opcion MP_CAPABLE a traves del trayecto principal determinado;
• una solicitud RST de reinicio a traves de cada uno de los trayectos de comunicacion auxiliares para anular la conexion a lo largo de esos trayectos de comunicacion auxiliares;
• una solicitud 5A SYN de establecimiento de conexion que transporta la opcion MP_JOIN a traves de un trayecto de comunicacion auxiliar;
• un mensaje 6B SYN/ACK de acuse de recibo que transporta la opcion MP_JOIN a traves de un trayecto de comunicacion auxiliar;
• un mensaje 7A ACK de acuse de recibo de segundo tipo que transporta la opcion MP_JOIN a traves de un trayecto auxiliar;
• un mensaje 8 de informacion representativo de los posibles trayectos de comunicacion auxiliares.
- un modulo M2, denominado tambien receptor, configurado para recibir desde el servidor S al menos:
• un mensaje 2 SYN/ACK de acuse de recibo de primer tipo que transporta la opcion MP_CAPABLE a traves de uno de dichos trayectos de comunicacion conocidos;
• un paquete 4 ACK de acuse de recibo de establecimiento para establecer una conexion principal de dicha conexion MPTCP multi-trayecto;
• una solicitud 5B SYN de establecimiento de conexion que transporta la opcion MP_JOIN a traves de un trayecto de comunicacion auxiliar;
• un mensaje 6A SYN/ACK de acuse de recibo de primer tipo que transporta la opcion MP_JOIN a traves de un trayecto de comunicacion auxiliar;
• un mensaje 7B ACK de acuse de recibo de segundo tipo que transporta la opcion MP_JOIN a traves de un trayecto auxiliar;
- un modulo M3, denominado tambien estimador, configurado para determinar como un trayecto de comunicacion
principal, el trayecto mediante el cual un mensaje SYN/ACK de acuse de recibo de primer tipo desde el servidor
S ha sido recibido primero por el cliente C; y
- un modulo M4, denominado tambien calculador, configurado para establecer la lista de rendimientos.
Los bloques M1 a M4 representados en la Figura 5 son unidades puramente funcionales, que no corresponden necesariamente a unidades ffsicas separadas. Concretamente, podnan ser desarrolladas en forma de software, o podnan ser implementadas en uno o varios circuitos integrados que comprenden uno o mas procesadores.
El diagrama de flujo y/o los diagramas de bloques en las Figuras 1 a 5 ilustran la configuracion, el funcionamiento y la funcionalidad de posibles implementaciones de sistemas, procedimientos y productos de programas de ordenador segun diversas realizaciones de la presente invencion. En este sentido, cada bloque en el diagrama de flujo o en los diagramas de bloques puede representar un modulo, segmento o parte de codigo, que comprende una o mas instrucciones ejecutables para implementar la funcion logica o las funciones logicas especificadas. Cabe senalar tambien que, en algunas implementaciones alternativas, las funciones indicadas en el bloque pueden realizarse en un orden distinto al indicado en las figuras. Por ejemplo, dos bloques mostrados en sucesion pueden ser ejecutados, de hecho, de manera
sustancialmente concurrente, o algunas veces los bloques pueden ser ejecutados en el orden inverso, o los bloques pueden ser ejecutados en un orden alternativo, dependiendo de la funcionalidad implicada. Cabe senalar tambien que cada bloque de los diagramas de bloques y/o la ilustracion de diagrama de flujo, y combinaciones de los bloques en los diagramas de bloques y/o la ilustracion de diagrama de flujo, puede ser implementado por sistemas de proposito especial 5 basados en hardware (por ejemplo, que comprenden uno o mas procesadores) que realizan las funciones o acciones especificadas, o combinaciones de hardware de proposito especial e instrucciones de ordenador.
Claims (13)
- 51015202530354045REIVINDICACIONES1. Un procedimiento para establecer una conexion multi-trayecto a traves de multiples trayectos de comunicacion entre dos equipos (C, S), primero y segundo, dentro de al menos una red (N) de comunicacion, en el que los dos equipos son compatibles con un protocolo multi-trayecto, que comprende:- enviar (E1), desde el primer equipo (C), solicitudes (1) de establecimiento de conexion principal a traves de al menos dos trayectos de comunicacion entre dichos equipos (C, S) primero y segundo;- recibir (E2), desde el segundo equipo (S), al menos un mensaje (2) de acuse de recibo a traves de uno de dichos trayectos de comunicacion;- determinar (E3), en el primer equipo (C), como un trayecto de comunicacion principal, el trayecto de comunicacion mediante el que el primero de dichos al menos un mensaje (2) de acuse de recibo desde el segundo equipo (S) ha sido recibido por el primer equipo (C), con el fin de establecer la conexion principal de dicha conexion multi-trayecto a traves de dicho trayecto de comunicacion principal;- enviar (E5), desde el primer equipo (C), una solicitud (RST) de reinicio a traves de cada uno de los trayectos de comunicacion auxiliares, que difieren del trayecto de comunicacion principal determinado, para anular la conexion a lo largo de esos trayectos de comunicacion auxiliares.
- 2. Procedimiento segun la reivindicacion 1, que comprende ademas:- enviar (E4), desde el primer equipo (C), un acuse de recibo con un primer mensaje (3) de datos a traves de dicho trayecto de comunicacion principal determinado; y- recibir (E6), desde el segundo equipo (S), un mensaje (4) de acuse de recibo de establecimiento para establecer la conexion principal de dicha conexion multi-trayecto entre los equipos (C, S) primero y segundo.
- 3. Procedimiento segun la reivindicacion 2, que comprende ademas:- enviar, desde el primer equipo (C), una solicitud (5A) de establecimiento de conexion auxiliar a traves de al menos uno de los trayectos de comunicacion auxiliares;- recibir, desde el segundo equipo (S), al menos un mensaje (6A) de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar; y- enviar, desde el primer equipo (C), un mensaje (7A) de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar, de manera que se establezca una conexion auxiliar de dicha conexion multi- trayecto entre el primer equipo (C) y el segundo equipo (S) a traves de dicho trayecto de comunicacion auxiliar.
- 4. Procedimiento segun la reivindicacion 2, que comprende ademas:- enviar, desde el primer equipo (C), un mensaje (8) de informacion representativo de los posibles trayectos de comunicacion auxiliares del primer equipo (C), a traves de dicho trayecto de comunicacion principal;- recibir, desde el segundo equipo (S), una solicitud (5B) de establecimiento de conexion auxiliar a traves de al menos uno de los trayectos de comunicacion auxiliares;- recibir, desde el primer equipo (C), al menos un mensaje (6B) de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar; y- enviar, desde el segundo equipo (S), un mensaje (7B) de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar, de manera que se establezca una conexion auxiliar de dicha conexion multi- trayecto entre el primer equipo (C) y el segundo equipo (S) a traves de dicho trayecto de comunicacion auxiliar.
- 5. Procedimiento segun cualquiera de las reivindicaciones 1 a 4, en el que dichas solicitudes (1) de establecimiento de conexion principal son enviadas de manera esencialmente simultanea desde el primer equipo (C).
- 6. Procedimiento segun cualquiera de las reivindicaciones 1 a 5, en el que el protocolo multi-trayecto es el protocolo de control de transmision multi-trayecto (MultiPath Transmission Control Protocol) sobre el protocolo de Internet.51015202530354045
- 7. Procedimiento segun cualquiera de las reivindicaciones 1 a 6, que comprende ademas enumerar (E7) los trayectos de comunicacion entre el primer equipo (C) y el segundo equipo (S), segun al menos un criterio de rendimiento.
- 8. Un primer equipo adaptado para establecer una conexion multi-trayecto a traves de multiples trayectos de comunicacion entre dicho primer equipo (C) “multi-homed” y un segundo equipo (S) “multi-homed” dentro de al menos una red (N) de comunicacion; en el que ambos equipos (C, S) son compatibles con un protocolo multi- trayecto, que comprende:- un emisor (M1) configurado para enviar al segundo equipo (S), solicitudes (1) de establecimiento de conexion principal a traves de al menos dos trayectos de comunicacion entre dichos equipos (C, S);- un receptor (M2) configurado para recibir desde el segundo equipo (S), al menos un mensaje (2) de acuse de recibo a traves de uno de dichos trayectos de comunicacion conocidos;- un estimador (M3) configurado para determinar como un trayecto de comunicacion principal, el trayecto de comunicacion mediante el que el primero de dichos al menos un mensaje (2) de acuse de recibo desde el segundo equipo (S) ha sido recibido por dicho primer equipo (C), con el fin de establecer la conexion principal de dicha conexion multi-trayecto a traves de dicho trayecto de comunicacion principal,en el que el emisor (M1) esta configurado ademas para enviar al segundo equipo (S) una solicitud de reinicio a traves de cada uno de los trayectos de comunicacion auxiliares, que difieren del trayecto de comunicacion principal determinado, para anular la conexion a lo largo de esos trayectos de comunicacion.
- 9. Un primer equipo segun la reivindicacion 8, en el que:- el emisor (M1) esta configurado ademas para enviar, desde el primer equipo (C), un acuse de recibo con un primer mensaje (3) de datos a traves de dicho trayecto de comunicacion principal determinado; y- el receptor (M2) esta configurado ademas para recibir, desde el segundo equipo (S), un mensaje (4) de acuse de recibo de establecimiento para establecer la conexion principal de dicha conexion multi-trayecto entre los equipos (C, S) primero y segundo.
- 10. Primer equipo segun la reivindicacion 9, en el que:- el emisor (M1) esta configurado ademas para enviar, desde el primer equipo (C), una solicitud (5A) de establecimiento de conexion auxiliar a traves de al menos uno de los trayectos de comunicacion auxiliares;- el receptor (M2) esta configurado ademas para recibir, desde el segundo equipo (S), al menos un mensaje (6A) de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar; y- el emisor (M1) esta configurado ademas para enviar, desde el primer equipo (C), un mensaje (7A) de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar, de manera que se establezca una conexion auxiliar de dicha conexion multi-trayecto entre el primer equipo (C) y el segundo equipo (S) a traves de dicho trayecto de comunicacion auxiliar.
- 11. Primer equipo segun la reivindicacion 9, en el que:- el emisor (M1) esta configurado ademas para enviar, desde el primer equipo (C), un mensaje (8) de informacion representativo de los posibles trayectos de comunicacion auxiliares del primer equipo (C), a traves de dicho trayecto de comunicacion principal;- el receptor (M2) esta configurado ademas para recibir, desde el segundo equipo (S), una solicitud (5B) de establecimiento de conexion auxiliar a traves de al menos uno de los trayectos de comunicacion auxiliares;- el receptor (M2) esta configurado ademas para recibir, desde el primer equipo (C), al menos un mensaje (6B) de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar; y- el emisor (M1) esta configurado ademas para enviar, desde el segundo equipo (S), un mensaje (7B) de acuse de recibo a traves de dicho trayecto de comunicacion auxiliar, de manera que se establezca una conexion auxiliar de dicha conexion multi-trayecto entre el primer equipo (C) y el segundo equipo (S) a traves de dicho trayecto de comunicacion auxiliar.
- 12. Primer equipo segun cualquiera de las reivindicaciones 8 a 11, en el que el emisor (M1) esta configuradoademas para enviar de manera esencialmente simultanea dichas solicitudes (1) de establecimiento de conexion principal.
- 13. Primer equipo segun cualquiera de las reivindicaciones 8 a 12, en el que el protocolo multi-trayecto es el protocolo de control de transmision multi-trayecto sobre el protocolo de Internet.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP12306499.0A EP2738995A1 (en) | 2012-11-30 | 2012-11-30 | Method and multi-homed equipment for establishing a multipath connection |
| EP12306499 | 2012-11-30 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2587913T3 true ES2587913T3 (es) | 2016-10-27 |
Family
ID=47458799
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES13193319.4T Active ES2587913T3 (es) | 2012-11-30 | 2013-11-18 | Procedimiento y equipo con múltiples conexiones físicas ("multi-homed") para establecer una conexión multi-trayecto |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US9225630B2 (es) |
| EP (2) | EP2738995A1 (es) |
| JP (1) | JP6324038B2 (es) |
| KR (1) | KR102156687B1 (es) |
| CN (1) | CN103856934B (es) |
| ES (1) | ES2587913T3 (es) |
| HK (1) | HK1198402A1 (es) |
| TW (1) | TWI624165B (es) |
| ZA (1) | ZA201308500B (es) |
Families Citing this family (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2738995A1 (en) * | 2012-11-30 | 2014-06-04 | Thomson Licensing | Method and multi-homed equipment for establishing a multipath connection |
| US10362148B2 (en) * | 2014-01-27 | 2019-07-23 | International Business Machines Corporation | Path selection using TCP handshake in a multipath environment |
| KR20170018057A (ko) * | 2014-06-25 | 2017-02-15 | 후아웨이 테크놀러지 컴퍼니 리미티드 | 데이터 전송 방법 및 디바이스 |
| WO2016011582A1 (zh) | 2014-07-21 | 2016-01-28 | 华为技术有限公司 | 链路控制节点、链路控制方法及通信系统 |
| FR3025962A1 (fr) * | 2014-09-12 | 2016-03-18 | Worldcast Systems | Passerelle pour donnes sur multi-reseaux ip |
| FR3027478B1 (fr) * | 2014-10-20 | 2016-12-09 | Sagemcom Broadband Sas | Procede de creation d'un sous flux de paquets de donnees. |
| US10397379B2 (en) * | 2015-03-06 | 2019-08-27 | Apple Inc. | Robust multipath TCP stateless connection establishment |
| WO2016155826A1 (en) * | 2015-04-01 | 2016-10-06 | Telefonaktiebolaget Lm Ericsson (Publ) | System, apparatus and method for load balancing |
| FR3038475A1 (fr) * | 2015-07-01 | 2017-01-06 | Orange | Procede d' optimisation de la charge d' un concentrateur de connexions reseau |
| KR101726357B1 (ko) * | 2015-07-08 | 2017-04-12 | 주식회사 엘지유플러스 | 다중 경로 패킷 데이터 서비스를 위한 응용 리스트 갱신 방법 및 장치 |
| GB2543347A (en) | 2015-10-16 | 2017-04-19 | Virtuosys Ltd | Dynamic router functionality in cellular networks |
| GB2543349A (en) | 2015-10-16 | 2017-04-19 | Virtuosys Ltd | Application server for dynamic edge router functionality in cellular networks |
| GB2543348A (en) | 2015-10-16 | 2017-04-19 | Virtuosys Ltd | Dynamic router functionality in cellular networks |
| GB2543346A (en) | 2015-10-16 | 2017-04-19 | Virtuosys Ltd | Dynamic router functionality in cellular networks |
| KR102314382B1 (ko) * | 2015-12-02 | 2021-10-18 | 주식회사 엘지유플러스 | 다중 경로 패킷 데이터 서비스 제공 방법 및 장치 |
| US10129372B2 (en) | 2015-12-08 | 2018-11-13 | Nicira, Inc. | Transferring multiple data sets using a multipath connection |
| US10097465B2 (en) * | 2015-12-08 | 2018-10-09 | Nicira Inc. | Data transfer between endpoints using a multipath connection |
| US10200277B2 (en) | 2015-12-08 | 2019-02-05 | Nicira, Inc. | Influencing path selection during a multipath connection |
| EP3482547B1 (en) * | 2016-07-08 | 2023-11-08 | Alcatel Lucent | Flow aggregation and routing for multi-connectivity client devices |
| JP6724641B2 (ja) | 2016-08-03 | 2020-07-15 | 富士通株式会社 | 管理装置、通信システム及び割当方法 |
| US10193795B2 (en) * | 2016-12-21 | 2019-01-29 | Sony Corporation | Robust data routing in wireless networks with directional transmissions |
| DE102016225892A1 (de) * | 2016-12-21 | 2018-06-21 | Robert Bosch Gmbh | Verfahren zum Übertragen von Daten |
| KR102021177B1 (ko) * | 2017-01-17 | 2019-09-11 | 인제대학교 산학협력단 | 동적 분리 채널에서의 메시지 인증코드 전송을 통한 위변조 검증 방법 및 시스템 |
| JP7031842B2 (ja) * | 2017-07-04 | 2022-03-08 | 国立研究開発法人情報通信研究機構 | 無線通信システム及び方法 |
| CN111372329B (zh) * | 2018-12-25 | 2022-08-19 | 华为技术有限公司 | 一种连接建立方法及终端设备 |
| TWI793399B (zh) | 2020-02-14 | 2023-02-21 | 緯創資通股份有限公司 | 使用者裝置及資料流量傳遞之排程方法 |
| CN115733703A (zh) * | 2021-08-27 | 2023-03-03 | 华为技术有限公司 | 一种多设备同步播放方法及装置 |
| EP4333385A1 (en) | 2022-08-31 | 2024-03-06 | Link2net s.c. | Method, data processing device, computer program and computer-readable medium for routing packets in a packet-switched network |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4952930A (en) | 1988-11-18 | 1990-08-28 | International Business Machines Corp. | Multipath hierarchical network |
| CN1155198A (zh) * | 1995-09-12 | 1997-07-23 | 美国电报电话公司 | 提供双向宽带通信的网络设备和方法 |
| EP1309133A1 (de) | 2001-10-31 | 2003-05-07 | Siemens Aktiengesellschaft | Verfahren, Empfangseinrichtung und Sendeeinrichtung zur Bestimmung des schnellsten Nachrichtenpfades ohne Uhrensynchronisation |
| KR100565316B1 (ko) | 2003-11-28 | 2006-03-30 | 엘지전자 주식회사 | 다중경로에서 휴대단말기의 동기 경로 결정방법 |
| US7443801B2 (en) | 2004-10-28 | 2008-10-28 | Telcordia Technologies, Inc. | Remote estimation of round-trip delays in a data network |
| KR100784419B1 (ko) * | 2005-06-29 | 2007-12-11 | 가부시키가이샤 엔.티.티.도코모 | 통신 단말기 및 통신 방법 |
| JP4800067B2 (ja) * | 2006-02-21 | 2011-10-26 | 株式会社エヌ・ティ・ティ・ドコモ | 通信ノード及びルーティング方法 |
| WO2007114049A1 (ja) * | 2006-03-29 | 2007-10-11 | Matsushita Electric Industrial Co., Ltd. | 無線伝送システム並びにそれに用いられる無線局及び方法 |
| KR101276835B1 (ko) * | 2006-09-28 | 2013-06-18 | 엘지전자 주식회사 | Ａｃｋ/ｎａｃｋ 신호 송신 방법 및 신호 송신 설정 방법 |
| KR101350086B1 (ko) | 2007-01-18 | 2014-01-09 | 톰슨 라이센싱 | 수신된 디지털 신호의 심볼 동기화 방법 및 이 방법을 이용하는 디지털 신호 수신기 |
| EP2537301B1 (en) * | 2010-02-19 | 2014-04-02 | Thomson Licensing | Control of packet transfer through a multipath session comprising a single congestion window |
| US8862178B2 (en) * | 2010-02-24 | 2014-10-14 | Qualcomm Incorporated | Methods and systems for managing participation in multiple wireless networks |
| CN101841463B (zh) | 2010-03-05 | 2012-05-16 | 清华大学 | 基于sctp的多路径并发传输方法 |
| WO2011153415A1 (en) * | 2010-06-04 | 2011-12-08 | Interdigital Patent Holdings, Inc. | Mptcp and mobil ip interworking |
| CN102404077B (zh) * | 2011-11-30 | 2013-11-27 | 清华大学 | 基于喷泉码的多径传输控制方法 |
| US8817797B2 (en) * | 2012-01-31 | 2014-08-26 | Alcatel Lucent | Method and apparatus for multipath protocol packet relay |
| US9185166B2 (en) * | 2012-02-28 | 2015-11-10 | International Business Machines Corporation | Disjoint multi-pathing for a data center network |
| EP2738995A1 (en) * | 2012-11-30 | 2014-06-04 | Thomson Licensing | Method and multi-homed equipment for establishing a multipath connection |
-
2012
- 2012-11-30 EP EP12306499.0A patent/EP2738995A1/en not_active Withdrawn
-
2013
- 2013-11-12 ZA ZA2013/08500A patent/ZA201308500B/en unknown
- 2013-11-15 TW TW102141550A patent/TWI624165B/zh not_active IP Right Cessation
- 2013-11-18 ES ES13193319.4T patent/ES2587913T3/es active Active
- 2013-11-18 EP EP13193319.4A patent/EP2739001B1/en active Active
- 2013-11-25 CN CN201310601585.8A patent/CN103856934B/zh active Active
- 2013-11-27 KR KR1020130145602A patent/KR102156687B1/ko active IP Right Grant
- 2013-11-28 JP JP2013246221A patent/JP6324038B2/ja active Active
- 2013-11-30 US US14/093,459 patent/US9225630B2/en active Active
-
2014
- 2014-11-25 HK HK14111903A patent/HK1198402A1/xx not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| KR20140070426A (ko) | 2014-06-10 |
| TWI624165B (zh) | 2018-05-11 |
| US9225630B2 (en) | 2015-12-29 |
| KR102156687B1 (ko) | 2020-10-23 |
| CN103856934A (zh) | 2014-06-11 |
| EP2739001B1 (en) | 2016-07-27 |
| EP2739001A1 (en) | 2014-06-04 |
| CN103856934B (zh) | 2019-08-20 |
| HK1198402A1 (en) | 2015-04-17 |
| US20140153583A1 (en) | 2014-06-05 |
| ZA201308500B (en) | 2014-07-30 |
| JP2014110639A (ja) | 2014-06-12 |
| TW201421949A (zh) | 2014-06-01 |
| EP2738995A1 (en) | 2014-06-04 |
| JP6324038B2 (ja) | 2018-05-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2587913T3 (es) | Procedimiento y equipo con múltiples conexiones físicas ("multi-homed") para establecer una conexión multi-trayecto | |
| CN112019395B (zh) | 用于网络的测量的方法、网络设备和系统 | |
| EP2741463B1 (en) | Data packet transmission method | |
| US10530644B2 (en) | Techniques for establishing a communication connection between two network entities via different network flows | |
| WO2017054547A1 (zh) | 双向转发检测的方法和装置 | |
| US11159420B2 (en) | Method and apparatus of automatic route optimization in a private virtual network for client devices of a local network | |
| JP2015070616A (ja) | 接続方法及び中継モジュール | |
| US8468225B2 (en) | Roaming TCP connections between changing physical networks | |
| WO2016050177A1 (zh) | 确定隧道最大传输单元的方法、网络设备和系统 | |
| CN111385822B (zh) | 一种配置方法及控制器 | |
| KR101692654B1 (ko) | 콘텐츠 전달 방법 | |
| CN108124504B (zh) | Tfo传输方法、代理服务器和系统 | |
| WO2014161421A1 (zh) | 数据传输方法、设备及系统 | |
| JP2013255185A (ja) | オープンフロースイッチ、オープンフローコントローラ及びオープンフローネットワークシステム | |
| US8676993B1 (en) | Bundled transmission control protocol connections | |
| WO2011014145A1 (en) | Maintaining persistent connection with user level transmission control protocol | |
| WO2012051853A1 (zh) | 个人网设备代理模式的实现方法和个人网设备 |