ES2837224T3 - Método y sistema para la planificación de paquetes en un escenario de agrupamiento basado en túneles TCP e información TCP nativa - Google Patents

Método y sistema para la planificación de paquetes en un escenario de agrupamiento basado en túneles TCP e información TCP nativa Download PDF

Info

Publication number
ES2837224T3
ES2837224T3 ES16719230T ES16719230T ES2837224T3 ES 2837224 T3 ES2837224 T3 ES 2837224T3 ES 16719230 T ES16719230 T ES 16719230T ES 16719230 T ES16719230 T ES 16719230T ES 2837224 T3 ES2837224 T3 ES 2837224T3
Authority
ES
Spain
Prior art keywords
module
tcp
router
planning
tunnels
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
Application number
ES16719230T
Other languages
English (en)
Inventor
Nico Bayer
Ammar Ghazzawi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Deutsche Telekom AG
Original Assignee
Deutsche Telekom AG
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Deutsche Telekom AG filed Critical Deutsche Telekom AG
Application granted granted Critical
Publication of ES2837224T3 publication Critical patent/ES2837224T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L12/5602—Bandwidth control in ATM Networks, e.g. leaky bucket
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/087—Jitter

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Sistema para planificación basada en paquetes para sesiones de protocolo de control de transmisión, TCP, o sesiones de protocolo de datagramas de usuario, UDP, donde el sistema comprende: un primer módulo de unión que comprende un primer módulo de planificación y, por lo menos, dos interfaces de acceso conectadas a, por lo menos, una red de transporte, donde el primer módulo de unión puede estar conectado a un dispositivo de usuario, donde un túnel TCP se configura por medio de cada una de las interfaces de acceso que termina en un segundo módulo de unión, y donde el primer módulo de planificación está configurado para planificar y distribuir paquetes de datos por medio de los túneles TCP hacia el segundo módulo de unión, preferentemente sobre internet; y/o comprendiendo el segundo módulo de unión un segundo módulo de planificación y por lo menos una interfaz de acceso conectada a cada una de la por lo menos una red de transporte, donde el segundo módulo de unión se puede conectar a un servidor, y donde el segundo módulo de planificación está configurado para planificar y distribuir paquetes de datos por medio de los túneles TCP hacia el primer módulo de unión, donde el primer y/o el segundo módulo de planificación está configurado para obtener la capacidad de los túneles TCP entre un primer rúter y un segundo rúter en base a información nativa procedente de los túneles TCP, y utilizar dicha capacidad para decidir acerca de la ponderación de planificación para cada uno de los túneles TCP, y donde la información nativa de los túneles TCP comprende por lo menos uno del tamaño de la ventana de congestión Ccwnd, un umbral de arranque lento TCP Sthresh, un tiempo de ida y vuelta TRTT suavizado, un número de paquetes que han sido enviados Pout, un número de paquetes que han sido acusados Psacked, un número de paquetes que han sido retransmitidos Pretrans y un número de paquetes que se consideran perdidos Plost.

Description

DESCRIPCIÓN
Método y sistema para la planificación de paquetes en un escenario de agrupamiento basado en túneles TCP e información TCP nativa
ANTECEDENTES
La presente invención se refiere a un método y un sistema para agrupamiento de recursos utilizando planificación basada en paquetes para sesiones de protocolo de control de transmisión (TCP, Transmission Control Protocol) o sesiones de protocolo de datagramas de usuario (UDP, User Datagram Protocol).
En el pasado se ha realizado un gran esfuerzo en enfoques para el agrupamiento de recursos, que se puede agrupar en términos generales en: enfoques de las capas de sesión/aplicación, de transporte, de red y de enlace. En lo que sigue se explicarán brevemente los ejemplos más importantes de cada uno de estos grupos.
La solicitud de intervalo HTTP es una característica de la capa de sesión/aplicación que se puede utilizar asimismo para llevar a cabo agrupamiento de recursos. Esta característica divide el contenido a descargar en segmentos que se descargan a continuación en sesiones TCP independientes sobre interfaces diferentes. Esta característica se implementa en el Samsung Galaxy S5 y se denomina "Network Booster" (S. E. Corporation, "Network booster - for enhanced data performance," Techpaper).
El ejemplo más destacado de una solución en la capa de transporte es Multipath TCP (MPTCP), especificado por el Grupo de trabajo de ingeniería de internet (IETF, Internet Engineering Task Force) en la petición de comentarios (RFC, Request for Comment) 6824 (A. Ford, C. Raiciu, M. Handley y O. Bonaventure, "Tcp extensions for multipath operation with multiple addresses," RFC, núm. 6824, enero de 2013). MPTCP se puede considerar una extensión de TCP que permite la utilización simultánea de múltiples trayectorias entre homólogos, transparente para la aplicación. MPTCP se utiliza ya actualmente en productos comerciales tales como el iPhone. El servicio Siri, por ejemplo, utiliza MPTCP para aumentar la fiabilidad. En caso de que la iPhone tenga una conexión celular y una WiFi, Siri inicia dos sesiones una sobre WiFi y otra sobre la red celular. Si una de las sesiones deja estar disponible o de ser fiable, la conexión de respaldo está disponible inmediatamente.
Otro ejemplo de la capa de transporte es el protocolo de transmisión de control de flujo (SCTP, Stream Control Transmission Protocol) (R. Stewart et al., "Stream Control Transmission Protocol," RFC 2960 (Proposed Standard), Grupo de trabajo de ingeniería de internet, octubre de 2000, sustituido por RFC 4960, actualizado por RFC 3309). Una de las ventajas de SCTP es su característica de multiconexión que, en principio, permite asimismo el agrupamiento de enlaces.
En principio, se puede decir que los enfoques de la capa de sesión/aplicación así como los enfoques de la capa de transporte son adecuados para escenarios extremo a extremo (E2E, end-to-end), dado que el agrupamiento es realizado por los dispositivos finales sin ninguna involucración especial de la red. El inconveniente de los enfoques E2E es el esfuerzo de introducir la tecnología dado que esta tiene que ser soportada por los dispositivos de usuario así como por los servidores de internet.
Los enfoques de la capa de red son la solución preferida para los operadores de red, dado que se pueden implementar fácilmente sin necesidad de cambiar los dispositivos finales. Se utilizan en cambio servidores intermediarios, que están bajo el control del operador y que llevan a cabo el agrupamiento de forma transparente para los dispositivos finales.
Los agrupamientos de la capa de enlace se refieren al agrupamiento de múltiples canales de igual tecnología. Son ejemplos el agrupamiento de enlaces Ethernet definidos en IEEE 802.3ad (WO 2009/019258 A1) y el agrupamiento de canales WiFi, por ejemplo, implementado en el modo Atheros SuperG. La solución SmartAP propuesta en (E. G. Llairo y D. Giustiniano, "Smartap: Practical wlan backhaul aggregation." en Wireless Days. IEEE, 2013, páginas 1 a 7) trata la agregación de red de retorno de redes de área local inalámbrica (WLAN, Wireless Local Area Network) utilizando visualización multicanal de radio simple. Esto permite conexiones con múltiples puntos de acceso (AP, Access Points) vecinos, incluso si se utilizan canales diferentes. D. Giustiniano, E. Goma, A. Lopez Toledo, I. Dangerfield, J. Morillo y P. Rodriguez, en el documento "Fair wlan backhaul aggregation," Proceedings de la Decimosexta conferencia internacional anual sobre informática interconexión móvil, ser. MobiCom '10. Nueva York, NY, USA: ACM, 2010, páginas 269-280, investigan la equidad en el sistema descrito. El documento US 8699490 B2 da a conocer un método para enviar datos sobre múltiples túneles.
SUMARIO
El objetivo de la presente invención es dar a conocer un método y un sistema para planificación basada en paquetes para sesiones de protocolo de control de transmisión (TCP) o sesiones de protocolo de datagramas de usuario (UDP), que tengan un rendimiento mejorado. El objetivo se consigue con las características de las reivindicaciones independientes. Las reivindicaciones dependientes se refieren a aspectos adicionales de la invención.
La presente invención propone una arquitectura de agrupamiento genérica, adecuada preferentemente para operadores de red. Sin embargo, la presente invención es asimismo adecuada para escenarios de contenido de transmisión libre (OTT, Over-the-top). En contraste con otros enfoques, el presente enfoque utiliza túneles TCP para reducir la complejidad del sistema y proporcionar altas ganancias de agrupamiento. No se requieren monitores de trayectoria, tal como en las soluciones de agrupamiento tradicionales. En su lugar, se utiliza información nativa procedente de los túneles TCP, como entrada para planificadores de paquetes, con el objeto de decidir sobre la planificación de paquetes más eficiente. Es decir, se describe una solución innovadora que puede determinar las ponderaciones para el enfoque de planificación con el fin de maximizar la ganancia del agrupamiento. En otras palabras, los túneles TCP y, en particular, la información nativa de los túneles TCP, se pueden utilizar para estimar el ancho de banda disponible a través de cada túnel. Esta información es adecuada para un mapeo eficiente de paquetes de datos a los túneles disponibles. De acuerdo con la presente invención, diferentes túneles pueden ir sobre diferentes interfaces de red, por ejemplo WiFi y 3GPP, donde el ancho de banda disponible a través de cada túnel puede ser significativamente diferente. La presente invención da a conocer una agregación de ancho de banda eficiente considerando el ancho de banda disponible a través de cada uno de los túneles.
De acuerdo con un primer aspecto de la presente invención, se da a conocer un sistema para planificación basada en paquetes para sesiones de protocolo de control de transmisión, TCP, o sesiones de protocolo de datagramas de usuario, UDP. El sistema comprende un primer módulo de unión que comprende un primer módulo de planificación y por lo menos dos interfaces de acceso conectadas a, por lo menos, una red de transporte, donde el primer módulo de unión puede estar conectado a un dispositivo de usuario, donde el túnel TCP está configurado por medio de cada una de las interfaces de acceso que terminan en un segundo módulo de unión, y donde el primer módulo de planificación está configurado para planificar y distribuir paquetes de datos por medio de los túneles TCP hacia el segundo módulo de unión, preferentemente sobre internet. El sistema puede comprender además, por separado o en combinación, el segundo módulo de unión que comprende un segundo módulo de planificación y por lo menos una interfaz de acceso conectada a cada una de las por lo menos una red de transporte, donde el segundo módulo de unión puede estar conectado a un servidor, y donde el segundo módulo de planificación está configurado para planificar y distribuir paquetes de datos a través de túneles TCP hacia el primer módulo de unión.
Es preferible que los paquetes de datos estén distribuidos sobre la capa de red (capa 3). Esto permite hacer uso de protocolos TCP estándar. Por consiguiente, pueden no ser necesarios nuevos protocolos TCP.
El sistema puede comprender además un primer rúter conectado al primer módulo de unión a través de una conexión cableada o inalámbrica, donde preferentemente el primer rúter está configurado para recibir y enviar datos desde/hacia el dispositivo de usuario.
El sistema puede comprender asimismo un segundo rúter conectado al segundo módulo de unión a través de una conexión cableada o inalámbrica, donde preferentemente el segundo rúter comprende un módulo de traducción de direcciones de red que está configurado preferentemente para recibir y enviar datos desde/hacia el servidor.
El primer rúter puede ser multiconexión, lo que significa que el primer rúter está conectado a internet a través de, por lo menos, dos interfaces. Ambos rúteres (primer y segundo rúter) pueden pertenecer a diferentes redes y están conectados entre sí a través de los túneles TCP. El número de túneles TCP entre ambos rúteres se basa en el número de interfaces con las que el primer rúter está conectado a internet. A través de cada una de estas interfaces se utiliza un túnel.
Se reconoce que el término "conectado" puede significar asimismo que un determinado módulo es parte del módulo respectivo al que está conectado, es decir, los módulos pueden estar conectados internamente. Por ejemplo, el primer y/o el segundo módulo de unión puede ser una parte integral del dispositivo de usuario y/o del servidor, respectivamente. Como otro ejemplo, el primer y/o el segundo módulo de unión puede ser una parte integral del primer y/o el segundo rúter, respectivamente.
Preferentemente, el primer y/o el segundo módulo de planificación está configurado para obtener la capacidad de los túneles TCP entre el primer rúter y el segundo rúter en base a información nativa procedente de los túneles TCP. Esta información se utiliza para decidir acerca de la ponderación de planificación para cada uno de los túneles TCP. Además, la información nativa de los túneles TCP puede comprender por lo menos uno de los siguientes: tamaño de la ventana de congestión Ccwnd, umbral de arranque lento TCP Sthresh, tiempo de vuelta TRTT suavizado, número de paquetes que han sido enviados Pout, número de paquetes que han sido acusados Psacked, número de paquetes que han sido retransmitidos Pretrans y número de paquetes que se consideran perdidos Plost. Alternativa o adicionalmente, se puede tener en cuenta como un parámetro adicional un tamaño de cola del emisor de las interfaces de túnel TCP.
De acuerdo con otro aspecto de la presente invención, el primer y/o el segundo módulo de planificación está configurado para obtener para cada túnel un número de paquetes que viajan actualmente desde el primer rúter hasta el segundo rúter, como Pfly = Pout - Psacked + Pretrans - Plost.
Más preferentemente, el primer y/o el segundo módulo de planificación está configurado para obtener una capacidad restante como Cleft = Ccwnd - Pfly.
Aún más preferentemente, el primer y/o el segundo módulo de planificación está configurado para obtener cambios de la capacidad restante ACleft dentro de un intervalo definido.
Sin embargo, se debe entender que la lista anterior de parámetros no es exhaustiva dado que se pueden obtener y utilizar otros parámetros para obtener los mismos resultados de la presente invención, lo que comprenderá un experto en la materia.
De acuerdo con otro aspecto de la presente invención, el primer y/o el segundo módulo de planificación está configurado para utilizar un algoritmo de planificación para calcular ponderaciones de planificación para los túneles TCP entre el primer rúter y el segundo rúter.
Preferentemente, las ponderaciones de planificación comprenden la proporción de los paquetes enviados sobre cada uno de los túneles y/o la cantidad de paquetes enviados sobre cada uno de los túneles consecutivamente. Además, el primer y/o el segundo módulo de planificación se puede configurar para adaptar ponderaciones de planificación continuamente y/o en intervalos de tiempo.
Preferentemente, el primer y/o el segundo módulo de planificación se puede configurar para adaptar ponderaciones de planificación de un subsiguiente intervalo de tiempo en base a parámetros reunidos durante un intervalo de tiempo anterior.
De acuerdo con un segundo aspecto de la presente invención, se da a conocer un método para planificación basada en paquetes para sesiones de protocolo de control de transmisión, utilizando preferentemente un sistema tal como se ha descrito anteriormente. El método comprende las etapas de: (a) conectar un primer módulo de unión que comprende un primer módulo de planificación y por lo menos dos interfaces de acceso conectadas a por lo menos una red de transporte, donde el primer módulo de unión puede estar conectado a un dispositivo de usuario; (b) configurar un túnel TCP a través de cada una de las interfaces de acceso que termina en un segundo módulo de unión; (c) planificar y distribuir paquetes de datos a través de los túneles TCP y de la por lo menos una red de transporte desde el primer módulo de unión hacia el segundo módulo de unión; y/o (b) conectar el segundo módulo de unión que comprende un segundo módulo de planificación y por lo menos una interfaz de acceso a cada una de la por lo menos una red de transporte, donde el segundo módulo de unión puede estar conectado a un servidor; y (e) planificar y distribuir paquetes de datos por medio de los túneles TCP desde el segundo módulo de unión hacia el primer módulo de unión.
El método puede comprender además una etapa de conectar un primer rúter al primer módulo de unión a través de una conexión cableada o inalámbrica, donde preferentemente el primer rúter está configurado para recibir y enviar datos desde/hacia el dispositivo de usuario.
El método puede comprender asimismo una etapa de conectar un segundo rúter al segundo módulo de unión a través de una conexión cableada o inalámbrica, donde preferentemente el segundo rúter comprende un módulo de traducción de direcciones de red que está configurado preferentemente para recibir y enviar datos desde/hacia el servidor.
De nuevo, es evidente que conectar puede significar conectar dos dispositivos/módulos independientes o puede significar conectar un primer dispositivo/módulo a un segundo dispositivo/módulo internamente, es decir, el segundo dispositivo/módulo puede estar integrado en el primer dispositivo/módulo.
Preferentemente, el método comprende una etapa de obtener capacidades de cada uno de los por lo menos dos túneles TCP entre el primer rúter y el segundo rúter en base a información nativa desde los túneles TCP.
Además, planificar y distribuir paquetes de datos se puede basar en un algoritmo de planificación para obtener ponderaciones de planificación para los túneles TCP entre el primer rúter y el segundo rúter.
Las ponderaciones de planificación pueden comprender la proporción de paquetes enviados sobre cada uno de los túneles y/o la cantidad de paquetes enviados sobre cada uno de los túneles consecutivamente.
Preferentemente, las ponderaciones de planificación son adaptadas continuamente y/o en intervalos de tiempo. Aún más preferentemente, las ponderaciones de planificación de un subsiguiente intervalo de tiempo se pueden basar en parámetros reunidos durante un intervalo de tiempo anterior.
Lo que es común a la totalidad de las presentes soluciones es el reto de planificar paquetes sobre los enlaces disponibles. Agrupar los recursos de diferentes redes de acceso es una medida para mejorar el caudal y la resiliencia a un fallo de red. Sin embargo, el agrupamiento de recursos de redes de acceso es una tarea complicada, especialmente en el caso de tráfico TCP. En particular, los retos cuando se realiza agrupamiento de recursos de acceso son:
• El primer reto se origina en el hecho de que los protocolos de transmisión más populares utilizados en las redes actuales son el protocolo de control de transmisión (TCP) y el protocolo de datagramas de usuario (UDP), y que estos protocolos no han sido diseñados para funcionar sobre múltiples enlaces. Estos protocolos asumen que los paquetes que pertenecen a la misma sesión se reciben solamente desde una dirección de protocolo de internet (IP, Internet Protocol). Sin embargo, si se utilizan múltiples enlaces de acceso, cada interfaz obtendrá una dirección IP diferente. Para superar este problema, se ha introducido una caja adicional que realiza traducción de direcciones de red (NAT, Network Address Translation) en nombre de todos los enlaces de acceso utilizados por el terminal.
• El segundo reto está relacionado con la planificación de los paquetes sobre los enlaces disponibles. En primer lugar, se puede distinguir entre dos tipos básicos de enfoques de planificación: basada en sesión y basada en paquetes. Cuando se realiza planificación basada en sesión, los paquetes de una sesión específica serán enviados siempre sobre el mismo enlace mientras que las sesiones se distribuyen sobre los enlaces disponibles. Por ejemplo, los paquetes de una sesión A son enviados sobre el enlace L1 , mientras que los paquetes de la sesión B son enviados sobre el enlace L2. El enfoque basado en sesión tiene varios inconvenientes. Por ejemplo, una única sesión no se puede beneficiar de múltiples enlaces disponibles. Incluso en el caso de múltiples sesiones hacia/desde el mismo terminal, no se puede garantizar una ganancia de agrupamiento si el rendimiento de los diferentes enlaces es significativamente diferente. El objetivo de esta invención está en el enfoque de planificación basada en paquetes, en el que se distribuyen paquetes de una única sesión sobre los enlaces disponibles. Dado que los diferentes enlaces pueden tener características diferentes en términos de ancho de banda disponible (B), retardo (D), fluctuación del retardo (J) y pérdida de paquetes (L), puede no ser suficiente llevar a cabo planificación Round-Robin en la que los paquetes se distribuyen homogéneamente sobre los enlaces disponibles. En cambio, es preferible una planificación ponderada. Especialmente para sesiones TCP, estas ponderaciones tienen una influencia significativa sobre el rendimiento extremo a extremo y, por lo tanto, estas ponderaciones se determinan cuidadosamente, preferentemente.
• Finalmente, el reto de reordenar paquetes tiene lugar cuando se aplica planificación basada en paquetes. Debido a las diferentes características de los diferentes enlaces, y debido al hecho de que los paquetes pueden viajar a través de rutas completamente diferentes por internet, los paquetes pueden llegar al destino en orden incorrecto. Dependiendo de la aplicación, esto puede provocar una reducción de la calidad de servicio.
A continuación se describen algunas realizaciones preferidas haciendo referencia a los dibujos. Con fines explicativos, se exponen varios detalles específicos, sin apartarse del alcance de la presente invención tal como se reivindica.
BREVE INTRODUCCIÓN DE LOS DIBUJOS
La figura 1 muestra un ejemplo de un terminal multiconexión, según la técnica anterior.
Las figuras 2(a) a (d) muestran cuatro realizaciones preferidas de la presente invención.
La figura 3 muestra adaptación de la ponderación de planificación en intervalos, de acuerdo con una realización de la presente invención.
La figura 4 muestra un algoritmo de planificación de ejemplo, según una realización de la presente invención.
DESCRIPCIÓN DETALLADA DE REALIZACIONES PREFERIDAS
En principio, el agrupamiento de recursos para denominados terminales de multiconexión 10, que son terminales 10 que están conectados a un servidor 12 en internet 11 se realiza utilizando dos enlaces independientes o diferentes (L1, L2,...,Ln). Se muestra un ejemplo en la figura 1.
El terminal 10 está conectado a internet 11 con múltiples líneas (L1, L2,...,Ln). Los terminales actuales 10 utilizan normalmente una de las líneas para la comunicación con un servidor 12 en internet 11. Usualmente, la selección de interfaces a utilizar se basa en una política jerárquica. Los teléfonos inteligentes, por ejemplo, pueden preferir la interfaz WiFi a la interfaz 3GPP, mientras que los portátiles pueden preferir la interfaz Ethernet a la interfaz WiFi. Como resultado, el ancho de banda máximo percibido por el terminal se limita al ancho de banda disponible mediante la interfaz de red seleccionada, incluso si existen otros enlaces hacia internet 11. Suponiendo la posibilidad de utilización simultánea de todas las interfaces disponibles (N), el ancho de banda percibido por terminal 10 puede aumentar significativamente. En un caso ideal, el ancho de banda global por terminal 10 (BWideal) es simplemente la suma del ancho de banda proporcionado por cada interfaz (BWi). Sin embargo, en implementaciones reales esto es algo más difícil y es casi imposible conseguir una eficiencia de agrupamiento (E) del 100 %. De este modo, el ancho de banda percibido por un terminal 10 (BW) se puede expresar como sigue:
Figure imgf000006_0001
En lo que sigue, se presenta una arquitectura para agrupamiento de recursos de acceso que proporciona una solución a uno o más de los retos mencionados anteriormente. Además, se presenta una solución innovadora que puede determinar las ponderaciones para el enfoque de planificación con el fin de maximizar la ganancia de agrupamiento. En primer lugar, se describe la arquitectura global propuesta, seguida por detalles del reto principal, la planificación ponderada de paquetes en base a información TCP nativa.
En la figura 2(a) se muestra una visión general de la solución de acuerdo con una realización preferida de la presente invención. El nodo de la izquierda (C) representa el dispositivo de usuario 100, por ejemplo un teléfono inteligente o un portátil, mientras que el dispositivo a la derecha (S) es un servidor 108 en internet (I) 107, por ejemplo, un servidor de aplicaciones. El dispositivo de usuario 100 y el servidor 108 son dispositivos estándar. La inteligencia de unión se implementa de manera transparente a estos, en un primer rúter (R1) 101 y un segundo rúter (R2) 104. El primer rúter 101 es la pasarela a internet 107 para el dispositivo de usuario 100 (por ejemplo, rúter DSL) y tiene varias interfaces de acceso (en este caso, se muestra con fines ilustrativos con dos interfaces de acceso L1 y L2). El segundo rúter 104 representa un rúter dentro de una o varias redes de transporte 103 del operador de red. Ambos rúteres 101, 104 conectan entre sí a través de la red de transporte (TR) 103 del operador de red. Por medio de cada una de las interfaces de acceso L1, L2 utilizadas por el primer rúter 101, este configura un respectivo túnel TCP (tun1 y tun2) hacía el segundo rúter 104 para cada una de las interfaces de acceso L1, L2.
El propósito de estos túneles tum, tun2 es transportar los paquetes de datos entre el dispositivo de usuario 100 y el servidor 108. Cada uno de los rúteres 101, 104 tiene asimismo un respectivo módulo de planificación (SC) 102, 105 implementado. Se debe observar que cada uno de los módulos de planificación 102, 105 se puede integrar (conectar internamente) en el respectivo rúter 101,104 para obtener acceso a toda la información relevante en tiempo real. Sin embargo, el módulo de planificación puede asimismo construirse como un módulo externo estando simplemente acoplado (conectado externamente) al rúter por medio de una conexión cableada o inalámbrica. En lo que sigue, el término "conectado" se utiliza para conectado internamente (o integrado) y/o conectado externamente (o acoplado a). En otras palabras, aunque la figura 2(a) muestra que los módulos de planificación 102, 105 están integrados en el primer y el segundo rúter 101, 104 respectivamente, es posible asimismo disponer estos módulos 102, 105 como dispositivos independientes (no mostrado). Los módulos de planificación 102, 105 son responsables de la planificación y distribución de paquetes por medio de las diferentes interfaces de túnel tum, tun2. Finalmente, el segundo rúter 104 está utilizando un módulo NAT 106 en la interfaz hacia internet 107. La combinación de cada uno de los módulos de planificación 102, 105 y las correspondientes interfaces se puede denominar un respectivo módulo de unión.
Las figuras 2(b) a (d) muestran otras soluciones alternativas de acuerdo con la presente invención. Los componentes se identifican con signos de referencia correspondientes, según los de la figura 2(a).
En este caso, la figura 2(b) muestra una realización alternativa, donde se omiten el primer y el segundo rúteres 101, 104 Es decir, los módulos de planificación 102, 105 están integrados en el (conectados al) dispositivo de usuario 100 y el servidor 108, respectivamente. En esta configuración, el primer agrupamiento ya no se ejecuta en el primer rúter 101 sino que se ejecuta directamente en el dispositivo de usuario 100 del usuario, que comprende varias trayectorias a internet. Además, el segundo agrupamiento ya no se ejecuta en el segundo rúter 104 sino que se ejecuta directamente en el servidor 108 en internet.
Las figuras 2(c) y (d) muestran variaciones adicionales de las realizaciones mostradas por las figuras 2(a) y (b). En particular, en la figura 2(c) se omite solamente el segundo rúter 104 y en la figura 2(b) se omite solamente el primer rúter 101, en comparación con la realización de la figura 2(a). Se debe entender que el primer y el segundo módulos de planificación 102, 105 se pueden integrar en el dispositivo de usuario 100 y el servidor 108, respectivamente, o disponer como dispositivos externos independientes (no mostrados).
Comparada con los enfoques conocidos tales como, por ejemplo, el presentado en el documento de D. Kaspar, "Multipath aggregation of heterogeneous access networks," SIGMultimedia Rec., volumen 4, núm. 1, páginas 27 a 28, marzo de 2012, la presente invención según la realización de la figura 1 tiene dos simplificaciones significativas. En primer lugar, no se utiliza una memoria tampón de eliminación de la fluctuación, que es responsable de reordenar los paquetes. En cambio, el reordenamiento de paquetes se deja al algoritmo de reordenamiento nativo de TCP. Es decir, el reordenamiento es realizado por el dispositivo de usuario 100 o el servidor de internet 108. De este modo, el sistema se beneficia del reordenamiento realizado por el dispositivo de usuario 100 o el servidor de internet 108, dado que no requiere un módulo de reordenamiento adicional. Esto simplifica el sistema en comparación con otras soluciones. En segundo lugar, no se requiere el módulo monitor de trayectorias, que es responsable de la determinación de las capacidades de enlace, debido al hecho de que se utilizan túneles TCP tum, tun2 entre el primer rúter 101 y el segundo rúter 104. En base a la información de estos túneles tum, tun2 se puede estimar la capacidad de los enlaces L1, L2.
Por lo tanto, la presente invención puede proporcionar una solución a uno o varios de los retos mencionados anteriormente. La NAT se realiza en el segundo rúter 104 lo que garantiza, junto con la utilización de los túneles tun1, tun2 , que el servidor 108 ve siempre la misma dirección IP del cliente, independientemente de la trayectoria a través de la cual se ha transmitido el paquete. La dirección IP del dispositivo de usuario 100 vista por el servidor 108 es la dirección IP pública del segundo rúter 104. De este modo, los paquetes que van del servidor 108 al dispositivo de usuario 100 estarán siempre destinados al segundo rúter 104. La utilización de los túneles TCP tum, tun2 evita los requisitos de un módulo monitor de trayectorias y, al mismo tiempo, proporciona información requerida por el proceso de planificación. Se aprovecha aquí el hecho de que TCP siempre intenta maximizar la utilización del ancho de banda en cada túnel tum, tum en base a la adaptación de la ventana de congestión (Ccwnd). Son ejemplos de información disponible a partir de los túneles TCP tum, tum:
• La capacidad del enlace en términos del tamaño de la Ccwnd.
• El umbral de arranque lento TCP (Sthresh).
• El tiempo de ida y vuelta (Trtt) suavizado, que es el RTT determinado/calculado por TCP.
• Pout, que es el número de paquetes que han sido enviados.
• Psacked, que es el número de paquetes que han sido acusados.
• Pretrans, que es el número de paquetes que han sido retransmitidos.
• Plost, que es el número de paquetes que se consideran perdidos.
Basándose en estos parámetros básicos, se pueden obtener parámetros adicionales, por ejemplo:
• Paquetes en marcha (P%), que son los paquetes enviados por el emisor pero que aún no han sido acusados. Por lo tanto, estos paquetes están viajando actualmente del emisor al receptor:
P f l y ^oixí ^sactceú ^ ^ r e tr a r.s ^ lo st
• Capacidad restante (Cleft), que es simplemente Ccwnd - Pfly y expresa el número de paquetes que se pueden enviar en el enlace sin esperar otro acuse hasta que se alcanza su capacidad.
• Cambios de la capacidad restante (Aaeft) dentro de un intervalo definido.
Las ponderaciones de planificación (SW, scheduling weights) se expresan generalmente en relaciones, por ejemplo (A:B:C:D). En el siguiente ejemplo con cuatro enlaces disponibles, el primer enlace tiene una ponderación de A, que significa que se envían A paquetes sobre este enlace antes de enviar paquetes del siguiente enlace, se envían B paquetes sobre el segundo enlace, se envían C paquetes sobre el tercer enlace y, finalmente, se envían D paquetes sobre el cuarto enlace. Después de eso, se planifica de nuevo el primer enlace, y así sucesivamente. Las ponderaciones de planificación (SW) tienen dos características.
• La proporción de ponderación (Wr), que expresa la proporción de paquetes enviados entre los enlaces. Por ejemplo, en el caso de dos enlaces, una proporción de 2 significa que se envían dos veces más paquetes sobre el enlace 1 que sobre el enlace 2.
• La altura de ponderación (Wh), que expresa la cantidad de paquetes enviados sobre un enlace consecutivamente. Una altura de 10 significa que se envían 10 paquetes consecutivamente sobre el enlace 1.
Ejemplo: Wr=2, Wh=10 ^ SW=(10:5).
Por razones de rendimiento, las adaptaciones de las ponderaciones de planificación pueden no realizarse continuamente sino en intervalos de tiempo (por ejemplo, intervalo n, intervalo n+1, intervalo n+2), tal como se muestra en la figura 3. La duración de estos intervalos de tiempo es un parámetro (DT). El conjunto de parámetros reunidos durante un intervalo de tiempo (Xn) se utiliza como entrada para el algoritmo de planificación (SWn+1=f(Xn)) para el siguiente intervalo de tiempo Xn+1. Es decir, en base a estos parámetros (parámetros reunidos durante un intervalo de tiempo) así como a parámetros opcionales de entrada o de configuración, el algoritmo de planificación calcula las ponderaciones de planificación para el siguiente intervalo, y así sucesivamente.
En la figura 4 se muestra un ejemplo de algoritmo de planificación de acuerdo con la presente invención. En este, con fines ilustrativos, están disponibles dos túneles (túnel a y túnel b). El algoritmo de planificación comienza en la etapa S10 con reposo Dt , es decir, espera el tiempo del intervalo Dt . Si se va a enviar un paquete, el algoritmo de planificación comprueba en la etapa S11 si la capacidad restante de un túnel a Cleft.a es igual o mayor que un valor umbral predeterminado (THR). Si la capacidad restante del túnel Cleft.a es igual o mayor que el valor umbral predeterminado, el algoritmo de planificación enviará el paquete a través de un túnel en la etapa S12 que, en este ejemplo, tiene una ponderación de planificación de SW(1:0), y vuelve al punto inicial (etapa S10) y el método se repite para otro intervalo. En este caso, SW(1:0) significa que se envía un paquete a través del túnel a y no se envía ningún paquete a través del túnel b. Es decir, solamente se envían paquetes a través del túnel a y, para este ejemplo, WR es infinito y WH es 1. Sin embargo, si la capacidad restante del túnel a Cleft,a no es igual o mayor que el valor umbral predeterminado, el algoritmo de planificación determinará si la capacidad restante del túnel b Cieft,b no es igual o mayor que el valor umbral predeterminado (THR) en la etapa S13. Se apreciará que los valores umbral para un túnel a y el túnel b no tienen necesariamente que ser iguales sino que pueden asimismo ser valores umbral diferentes.
Si la capacidad restante del túnel b Clett.b es igual o mayor que el valor umbral predeterminado, el algoritmo de planificación enviará el paquete a través del túnel b en la etapa S14 que, en este ejemplo, tiene una ponderación de planificación de SW(0:1), y vuelve al punto inicial (etapa S10), y el método se repite para otro intervalo. Sin embargo, si la capacidad restante del túnel b Cleft,b no es igual o mayor que el valor umbral predeterminado, el algoritmo de planificación determinará que ninguno de los túneles tiene capacidad restante, el algoritmo de planificación enviará el paquete en la etapa 15 que, en este ejemplo, tiene una ponderación de planificación de SW(1:1), y vuelve al punto inicial en la etapa S10, y el método se repite para otro intervalo.
En otras palabras, el túnel a es el túnel prioritario y, en caso de que tenga capacidad libre, los paquetes se envían solamente sobre este túnel a. En caso de que el túnel a no tenga capacidad libre, los paquetes se envían sobre el túnel b en caso de que el túnel b tenga capacidad libre. En caso de que ambos enlaces no tengan capacidad libre, se realiza planificación Round Robin
Aunque se describa dentro del contexto del enfoque de capa de red, el experto en la materia apreciará que la presente invención puede asimismo aplicarse en otros enfoques de agrupamiento, por ejemplo MPTCP. Sin embargo, utilizando el enfoque de capa de red descrito (capa 3) puede no requerirse ningún protocolo TCP nuevo. Por lo tanto, se pueden utilizar protocolos TCP estándar.
Dado que la presente invención se puede realizar de varias formas sin apartarse del alcance ni de las características esenciales de la misma, se deberá entender que las realizaciones descritas anteriormente no están limitadas por ninguno de los detalles de las descripciones anteriores, salvo que se especifique lo contrario, sino que se deberá considerar en general dentro del alcance según se define en las reivindicaciones adjuntas, y por lo tanto se prevé que todos los cambios y modificaciones que quedan dentro de la presente invención estén de ese modo abarcados por las reivindicaciones adjuntas.
Además, en las reivindicaciones, la expresión "comprende" no excluye otros elementos o etapas, y el artículo indefinido "un" o "una" no excluye una pluralidad. Una sola unidad puede cumplir las funciones de varias características enunciadas en las reivindicaciones. Las expresiones "esencialmente", "en torno a", "aproximadamente" y similares, en relación con un atributo o un valor, en concreto definen asimismo exactamente el atributo o exactamente el valor, respectivamente. No se deberá considerar que ningún signo de referencia en las reivindicaciones limita el alcance.

Claims (15)

REIVINDICACIONES
1. Sistema para planificación basada en paquetes para sesiones de protocolo de control de transmisión, TCP, o sesiones de protocolo de datagramas de usuario, UDP, donde el sistema comprende:
un primer módulo de unión que comprende un primer módulo de planificación y, por lo menos, dos interfaces de acceso conectadas a, por lo menos, una red de transporte, donde el primer módulo de unión puede estar conectado a un dispositivo de usuario, donde un túnel TCP se configura por medio de cada una de las interfaces de acceso que termina en un segundo módulo de unión, y donde el primer módulo de planificación está configurado para planificar y distribuir paquetes de datos por medio de los túneles TCP hacia el segundo módulo de unión, preferentemente sobre internet; y/o
comprendiendo el segundo módulo de unión un segundo módulo de planificación y por lo menos una interfaz de acceso conectada a cada una de la por lo menos una red de transporte, donde el segundo módulo de unión se puede conectar a un servidor, y donde el segundo módulo de planificación está configurado para planificar y distribuir paquetes de datos por medio de los túneles TCP hacia el primer módulo de unión, donde el primer y/o el segundo módulo de planificación está configurado para obtener la capacidad de los túneles TCP entre un primer rúter y un segundo rúter en base a información nativa procedente de los túneles TCP, y utilizar dicha capacidad para decidir acerca de la ponderación de planificación para cada uno de los túneles TCP, y
donde la información nativa de los túneles TCP comprende por lo menos uno del tamaño de la ventana de congestión Ccwnd, un umbral de arranque lento TCP Sthresh, un tiempo de ida y vuelta Tr tt suavizado, un número de paquetes que han sido enviados Pout, un número de paquetes que han sido acusados Psacked, un número de paquetes que han sido retransmitidos Pretrans y un número de paquetes que se consideran perdidos Plost.
2. El sistema según la reivindicación 1, que comprende además el primer rúter conectado al primer módulo de unión a través de una conexión cableada o inalámbrica, donde preferentemente el primer rúter está configurado para recibir y enviar datos desde/hacia el dispositivo de usuario.
3. El sistema según la reivindicación 1 o 2, que comprende además el segundo rúter conectado al segundo módulo de unión a través de una conexión cableada o inalámbrica, donde preferentemente el segundo rúter comprende un módulo de traducción de direcciones de red, que está configurado preferentemente para recibir y enviar datos desde/hacia el servidor.
4. El sistema según cualquiera de las reivindicaciones 1 a 3, en el que el primer y/o el segundo módulo de planificación está configurado para obtener un número de paquetes que viajan actualmente del primer rúter al segundo rúter, como Pfly = Pout - Psacked + Pretrans - Plost.
5. El sistema según la reivindicación 4, en el que el primer y/o el segundo módulo de planificación está configurado para obtener una capacidad restante, como Cleft = Ccwnd - Pfly.
6. El sistema según la reivindicación 5, en el que el primer y/o el segundo módulo de planificación está configurado para obtener cambios de la capacidad restante ACleft dentro de un intervalo definido.
7. El sistema según cualquiera de las reivindicaciones 1 a 6, en el que el primer y/o el segundo módulo de planificación está configurado para utilizar un algoritmo de planificación para obtener ponderaciones de planificación para los túneles TCP entre el primer rúter y el segundo rúter.
8. El sistema según la reivindicación 7, en el que las ponderaciones de planificación comprenden la proporción de la cantidad de paquetes enviados a través de cada uno de los túneles y/o la cantidad de paquetes enviados sobre cada uno de los túneles consecutivamente.
9. El sistema según la reivindicación 8, en el que el primer y/o el segundo módulo de planificación está configurado para adaptar ponderaciones de planificación de manera continua o en intervalos de tiempo, donde preferentemente el primer y/o el segundo módulo de planificación está configurado para adaptar ponderaciones de planificación de un subsiguiente intervalo de tiempo en base a parámetros reunidos durante un intervalo de tiempo anterior.
10. Un método para planificación basada en paquetes para sesiones de protocolo de control de transmisión, que utiliza preferentemente un sistema según cualquiera de las reivindicaciones 1 a 9, en el que el método comprende las etapas de:
(a) conectar un primer módulo de unión que comprende un primer módulo de planificación y por lo menos dos interfaces de acceso conectados a por lo menos una red de transporte, donde el primer módulo de unión se puede conectar a un dispositivo de usuario; configurar un túnel TCP por medio de cada una de las interfaces de acceso que termina en un segundo módulo de unión;
(c) planificar y distribuir paquetes de datos por medio de los túneles TCP y de la por lo menos una red de transporte desde el primer módulo de unión al segundo módulo de unión; y/o
(d) conectar el segundo módulo de unión que comprende un segundo módulo de planificación y por lo menos una interfaz de acceso a cada una de por lo menos una red de transporte, donde el segundo módulo de unión se puede conectar a un servidor; y
(e) planificar y distribuir paquetes de datos por medio de los túneles TCP, desde el segundo módulo de unión hacia el primer módulo de unión;
donde el primer y/o el segundo módulo de planificación está configurado para obtener la capacidad de los túneles TCP entre un primer rúter y un segundo rúter en base a información nativa procedente de los túneles TCP, y utilizar dicha capacidad para decidir acerca de la ponderación de planificación para cada uno de los túneles TCP, y donde la información nativa de los túneles TCP comprende por lo menos uno del tamaño de la ventana de congestión Ccwnd, un umbral de arranque lento TCP Sthresh, un tiempo de ida y vuelta Tr tt suavizado, un número de paquetes que han sido enviados Pout, un número de paquetes que han sido acusados Psacked, un número de paquetes que han sido retransmitidos Pretrans y un número de paquetes que se consideran perdidos Plost.
11. El método según la reivindicación 10, donde el método comprende una etapa de conectar el primer rúter al primer módulo de unión a través de una conexión cableada o inalámbrica, donde preferentemente el primer rúter está configurado para recibir y enviar datos desde/hacia el dispositivo de usuario.
12. El método según la reivindicación 10 u 11, donde el método comprende una etapa de conectar el segundo rúter al segundo módulo de unión a través de una conexión cableada o inalámbrica, donde preferentemente el segundo rúter comprende un módulo de traducción de direcciones de red que está configurado preferentemente para recibir y enviar datos desde/al servidor.
13. El método según cualquiera de las reivindicaciones 10 a 12, en el que planificar y distribuir paquetes de datos se basa en un algoritmo de planificación para obtener ponderaciones de planificación para los túneles TCP entre el primer rúter y el segundo rúter.
14. El método según la reivindicación 13, en el que las ponderaciones de planificación comprenden la proporción de paquetes enviados a través de cada uno de los túneles y/o la cantidad de paquetes enviados consecutivamente sobre cada uno de los túneles.
15. El método según la reivindicación 14, en el que las ponderaciones de planificación se adaptan de forma continua o en intervalos de tiempo, en el que preferentemente las ponderaciones de planificación de un subsiguiente intervalo de tiempo se basan en parámetros reunidos durante un intervalo de tiempo anterior.
ES16719230T 2015-04-10 2016-04-08 Método y sistema para la planificación de paquetes en un escenario de agrupamiento basado en túneles TCP e información TCP nativa Active ES2837224T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP15163169 2015-04-10
PCT/EP2016/057795 WO2016162501A1 (en) 2015-04-10 2016-04-08 Method and system for the scheduling of packets in a bundling scenario based on tcp tunnels and native tcp information

Publications (1)

Publication Number Publication Date
ES2837224T3 true ES2837224T3 (es) 2021-06-29

Family

ID=52946348

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16719230T Active ES2837224T3 (es) 2015-04-10 2016-04-08 Método y sistema para la planificación de paquetes en un escenario de agrupamiento basado en túneles TCP e información TCP nativa

Country Status (7)

Country Link
US (1) US10673991B2 (es)
EP (1) EP3281380B1 (es)
JP (1) JP6777650B2 (es)
KR (1) KR102442083B1 (es)
CN (1) CN107438993B (es)
ES (1) ES2837224T3 (es)
WO (1) WO2016162501A1 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10257283B2 (en) * 2016-10-03 2019-04-09 International Business Machines Corporation System, method and computer program product for network function modification
CN110399578B (zh) * 2018-04-17 2023-07-14 腾讯科技（深圳）有限公司 页面访问方法及装置
ES2903241T3 (es) * 2018-06-07 2022-03-31 Deutsche Telekom Ag Un sistema de comunicación para transmitir un segmento de protocolo de control de transmisión a través de una red de comunicación mediante el uso de un protocolo de control de transmisión de múltiples rutas, procedimiento y programa informático correspondientes
US11323288B2 (en) * 2018-08-07 2022-05-03 Dh2I Company Systems and methods for server cluster network communication across the public internet
US11165891B2 (en) * 2018-08-27 2021-11-02 Dh2I Company Highly available transmission control protocol tunnels
US11575757B2 (en) 2019-06-17 2023-02-07 Dh2I Company Cloaked remote client access
EP3840303B1 (de) * 2019-12-17 2023-05-17 Hotsplots GmbH Datenübertragungseinrichtung, datenempfangseinrichtung und sendeverfahren zum übertragen von datenpaketen durch einen tunnel
US11563802B2 (en) 2020-11-06 2023-01-24 Dh2I Company Systems and methods for hierarchical failover groups

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6144639A (en) * 1996-09-03 2000-11-07 Sbc Technology Resources, Inc. Apparatus and method for congestion control in high speed networks
US20020010866A1 (en) 1999-12-16 2002-01-24 Mccullough David J. Method and apparatus for improving peer-to-peer bandwidth between remote networks by combining multiple connections which use arbitrary data paths
US7468947B2 (en) * 2003-03-31 2008-12-23 International Business Machines Corporation Controlling data packet flows by manipulating data packets according to an actual manipulation rate
JP2007243447A (ja) 2006-03-07 2007-09-20 Nippon Telegr & Teleph Corp <Ntt> パケット送信制御装置
CN101345695A (zh) * 2007-07-09 2009-01-14 鼎桥通信技术有限公司 一种分组调度方法
EP2023541B1 (en) 2007-08-07 2013-02-13 Nokia Siemens Networks Oy Method, device and communication system to avoid loops in an Ethernet Ring System with an underlying 802.3ad network
CN101686180A (zh) * 2008-09-28 2010-03-31 华为技术有限公司 数据传输方法及网络节点和数据传输系统
CN101404622B (zh) * 2008-11-07 2011-03-23 重庆邮电大学 基于多径负载均衡的无线互联网拥塞控制方法及控制器
US9584443B2 (en) * 2014-08-08 2017-02-28 Pismo Labs Technology Limited Methods and systems for transmitting data through an aggregated connection
US8923131B2 (en) 2010-02-16 2014-12-30 Broadcom Corporation Traffic management in a multi-channel system
US9455897B2 (en) * 2010-04-06 2016-09-27 Qualcomm Incorporated Cooperative bandwidth aggregation using multipath transport
KR20120065867A (ko) * 2010-12-13 2012-06-21 경희대학교 산학협력단 지연-대역폭의 곱이 큰 네트워크를 위한 단대단 에너지 절약 기법을 사용한 다중경로 ｔｃｐ 네트워크
US9106787B1 (en) * 2011-05-09 2015-08-11 Google Inc. Apparatus and method for media transmission bandwidth control using bandwidth estimation
EP2763362A1 (en) * 2013-01-31 2014-08-06 Thomson Licensing A method for connecting a multi-homed and MPTCP capable client with a regular TCP server
US9456464B2 (en) * 2013-06-06 2016-09-27 Apple Inc. Multipath TCP subflow establishment and control
JP6206009B2 (ja) 2013-09-04 2017-10-04 沖電気工業株式会社 パケット通信装置及びシステム
US9954770B2 (en) * 2014-10-07 2018-04-24 At&T Intellectual Property I, L.P. Rerouting tunnel traffic in communication networks

Also Published As

Publication number Publication date
JP6777650B2 (ja) 2020-10-28
KR20170137088A (ko) 2017-12-12
US10673991B2 (en) 2020-06-02
EP3281380A1 (en) 2018-02-14
JP2018511275A (ja) 2018-04-19
US20180077267A1 (en) 2018-03-15
WO2016162501A1 (en) 2016-10-13
CN107438993B (zh) 2021-08-24
CN107438993A (zh) 2017-12-05
EP3281380B1 (en) 2020-10-21
KR102442083B1 (ko) 2022-09-13

Similar Documents

Publication Publication Date Title
ES2837224T3 (es) Método y sistema para la planificación de paquetes en un escenario de agrupamiento basado en túneles TCP e información TCP nativa
US20230276483A1 (en) Multipath-scheduling-based relay device
US10237153B2 (en) Packet retransmission method and apparatus
US10021034B2 (en) Application aware multihoming for data traffic acceleration in data communications networks
US20210084523A1 (en) Method for controlling data transmission by using network slices
JP6473688B2 (ja) データ転送レートを増加させるためのデータストリーム分割
EP3522479A1 (en) Techniques for efficient multipath transmission
US11824685B2 (en) Method for implementing GRE tunnel, access point and gateway
US9635148B2 (en) Partitioning data sets for transmission on multiple physical links
US11849493B2 (en) Modified methods and system of transmitting and receiving transmission control protocol segments over internet protocol packets
EP3119057A1 (en) Packet conversion device and method for allowing transparent packet-based multipath bundling
ES2972036T3 (es) Procedimiento y dispositivo de red para comunicación de múltiples rutas
CN106464567B (zh) 一种流量动态控制方法、设备及网关、融合接入汇聚点
CN109120540B (zh) 传输报文的方法、代理服务器和计算机可读存储介质
Abdelsalam et al. Analysis of bandwidth aggregation techniques for combined use of satellite and x DSL broadband links
Rico et al. A testbed for developing, simulating and experimenting multipath aggregation algorithms
CN112714506A (zh) 数据传输方法和装置
US10341225B2 (en) Bonding of satellite terminals
Tachibana et al. Implementation of a proxy-based CMT-SCTP scheme for Android smartphones
JP2012044344A (ja) ゲートウェイ装置およびｉｐトンネル選択方法
CN115065734A (zh) 一种数据处理方法、装置及芯片
KR20140002040A (ko) 라우터에서의 통신들을 관리하는 기술
Rocha Multi-Technology Bus-To-Infrastructure Wireless Networks: A Multipath Transfer Solution