ES2898268T3 - Protocolo de agregación de único flujo - Google Patents

Abstract

Un sistema de transmisión de datos, que comprende: un nodo de envío (110), que comprende: una primera cola de enlace (214), configurada para almacenar paquetes de datos (224) para ser transmitidos a un nodo de recepción (130) en un primer enlace de red (120.1); un primer control de congestión específico de enlace (150), asociado a la primera cola de enlace (214), estando el primer control de congestión específico de enlace (150) configurado para controlar una primera ventana de congestión (206), en donde la primera ventana de congestión (206), controlada basándose en una capacidad disponible del primer enlace de red (120.1), determina un tamaño de la primera cola de enlace (214) para los paquetes de datos (224) para ser transmitidos; una pluralidad de emisores de flujo (112), configurados para transmitir paquetes de datos (224) de una pluralidad de flujos de datos (114) a receptores de flujo (132) en el nodo de recepción (130), una pluralidad de controles de ventana de recepción específicos de flujo (160), independientes del primer control de congestión específico de enlace (150), en donde exactamente un control de ventana de recepción específico de flujo (160) está asociado a cada flujo de datos de la pluralidad de flujos de datos (114), en donde cada control de ventana de recepción específico de flujo (160) está configurado para controlar una ventana de recepción (216) del emisor de flujo asociado, basándose en una capacidad disponible del correspondiente receptor de flujo para especificar una cantidad de datos disponible con el fin de que se introduzca en la primera cola de enlace (214); una segunda cola de enlace (214), configurada para almacenar paquetes de datos (224), para ser transmitidos al nodo de recepción (130) en un segundo enlace de red (120.2); y un segundo control de congestión específico de enlace (150), asociado a la segunda cola de enlace (214), estando el segundo control de congestión específico de enlace (150) configurado para controlar una segunda ventana de congestión (206), en donde la segunda ventana de congestión (206), controlada basándose en una capacidad disponible del segundo enlace de red (120.2), determina un tamaño de la segunda cola de enlace (214) para los paquetes de datos (224) para ser transmitidos, en donde los datos, puestos a disposición por uno de la pluralidad de emisores de flujo (112) se ponen a disposición, en uno seleccionado de un grupo que consiste en los enlaces de red primero y segundo (120), de los receptores de flujo (132) en el nodo de recepción (130), en donde el segundo control de congestión específico de enlace (150) está configurado para hacer una primera determinación de que la segunda ventana de congestión (206) no permite el envío de los datos, en donde el primer control de congestión específico de enlace (150) está configurado para hacer una segunda determinación de que la primera ventana de congestión (206) permite el envío de los datos, y en donde el primer enlace de red (120.1) está configurado para permitir el envío de al menos un paquete de datos que comprende los datos basándose en la segunda determinación.

Description

DESCRIPCIÓN

Protocolo de agregación de único flujo

Antecedentes

Los protocolos de comunicación pueden usarse para intercambiar datos, por ejemplo, entre un cliente y un servidor. Pueden usarse diversas implementaciones de los protocolos de control de transmisión para controlar cómo un nodo de envío transmite uno o más flujos de datos a un nodo de recepción. Un protocolo de control de transmisión puede garantizar, por ejemplo, que los datos se entregan de manera fiable desde una aplicación que se ejecuta en un dispositivo informático a otra aplicación que se ejecuta en otro dispositivo informático, de una manera ordenada a través de una red de datos.

Un ejemplo proporcionado por la técnica anterior es RAICIU M HANDLEY D WISCHIK UNIVERSITY COLLEGE LOn Do N C, "Coupled Multipath-Aware Congestion Control"; draft-ietf-mptcp-congestion-OO.txt, COUPLED MULTIPATH-AWARE CONGESTION CONTROL; DRAFT-IETF-MPTCP-CONGESTION-OO.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH-1205 GINEBRA, SUIZA, 13 de julio de 2010, páginas 1-11, XP015070148 [A] 1-21, secciones 2 y 3. Este documento es un borrador de internet que describe un algoritmo de control de congestión que acopla los algoritmos de control de congestión que se ejecutan en diferentes subflujos vinculando sus funciones de aumento y controla dinámicamente la agresividad global del flujo de múltiples rutas. Se proporciona un ejemplo adicional por Zhou et. al en la contribución del IEEE "Goodput improvement for multipath TCP by congestion window adaptation in multiradio devices" en la 10th Annual IEEE Consumer Communications & Network Conference CCNC, 2013.

Sumario

La invención se define mediante las reivindicaciones independientes. En general, un primer aspecto se refiere a un sistema de transmisión de datos que comprende un nodo de envío, que comprende una primera cola de enlace, configurada para almacenar paquetes de datos para transmitirse a un nodo de recepción en un primer enlace de red; un primer control de congestión específico de enlace, asociado a la primera cola de enlace, el primer control de congestión específico de enlace configurado para controlar una primera ventana de congestión, en donde la primera ventana de congestión, controlada basándose en una capacidad disponible del primer enlace de red, determina un tamaño de la primera cola de enlace para los paquetes de datos para transmitirse; una pluralidad de emisores de flujo, configurados para transmitir paquetes de datos de una pluralidad de flujos de datos a receptores de flujo en el nodo de recepción, una pluralidad de controles de ventana de recepción específicos de flujo, independientes del primer control de congestión específico de enlace, en donde exactamente un control de ventana de recepción específico de flujo está asociado a cada flujo de datos de la pluralidad de flujos de datos, en donde cada control de ventana de recepción específico de flujo está configurado para controlar una ventana de recepción del emisor de flujo asociado basándose en una capacidad disponible del correspondiente receptor de flujo para especificar una cantidad de datos disponible que va a introducirse en la primera cola de enlace. El nodo de envío comprende adicionalmente una segunda cola de enlace configurada para almacenar paquetes de datos para transmitirse al nodo de recepción en un segundo enlace de red, y un segundo control de congestión específico de enlace, asociado a la segunda cola de enlace, el segundo control de congestión específico de enlace configurado para controlar una segunda ventana de congestión, en donde la segunda ventana de congestión, controlada basándose en una capacidad disponible del segundo enlace de red, determina un tamaño de la segunda cola de enlace para los paquetes de datos para transmitirse, y en donde los datos, puestos a disposición por uno de la pluralidad de emisores de flujo se ponen a disposición de uno seleccionado de un grupo que consiste en el primer y el segundo enlace de red a los receptores de flujo en el nodo de recepción. El segundo control de congestión específico de enlace está configurado para hacer una primera determinación de que la segunda ventana de congestión no permite el envío de los datos. El primer control de congestión específico de enlace está configurado para hacer una segunda determinación de que la primera ventana de congestión permite el envío de los datos. El primer enlace de red está configurado para permitir el envío de al menos un paquete de datos que comprende los datos basándose en la segunda determinación.

Un segundo aspecto se refiere a un método para transmitir datos por un nodo de envío, comprendiendo el método establecer un primer control de congestión específico de enlace asociado a una primera cola de enlace, que comprende: controlar un tamaño de la primera cola de enlace asociada a un primer enlace de red entre el nodo de envío y un nodo de recepción, estableciendo una primera ventana de congestión basándose en una capacidad disponible del primer enlace de red, en donde la primera cola de enlace está configurada para almacenar paquetes de datos para transmitirse desde el nodo de envío al nodo de recepción; y establecer una pluralidad de controles de ventana de recepción específicos de flujo que son independientes del control de congestión específico de enlace, que comprende: para cada uno de la pluralidad de controles de ventana de recepción específicos de flujo, controlar una ventana de recepción de un emisor de flujo asociado del nodo de envío basándose en una capacidad disponible de un correspondiente receptor de flujo del nodo de recepción, en donde la ventana de recepción específica de flujo especifica una cantidad de datos disponible para que se introduzca en la primera cola de enlace para su transmisión al nodo de recepción. El método comprende adicionalmente establecer un segundo control de congestión específico de enlace asociado a una segunda cola de enlace, en donde establecer un segundo control de congestión específico de enlace comprende: controlar un tamaño de la segunda cola de enlace asociada a un segundo enlace de red entre el nodo de envío y el nodo de recepción, estableciendo una segunda ventana de congestión basándose en una capacidad disponible del segundo enlace de red, en donde la segunda cola de enlace está configurada para almacenar los paquetes de datos para transmitirse del nodo de envío al nodo de recepción, y en donde los datos, que se ponen a disposición por uno de la pluralidad de emisores de flujo se ponen a disposición de uno seleccionado de un grupo que consiste en el primer y el segundo enlace de red. El método comprende adicionalmente hacer una primera determinación de que la segunda ventana de congestión no permite el envío de los datos, hacer una segunda determinación de que la primera ventana de congestión no permite el envío de los datos, y enviar al menos un paquete de datos que comprende los datos a través del primer enlace de red, basándose en la segunda determinación.

Las realizaciones del sistema de transmisión de datos y del método se definen en las reivindicaciones dependientes.

Breve descripción de los dibujos

La Figura 1 muestra flujos de datos en una red, de acuerdo con una o más realizaciones de la invención.

La Figura 2 muestra una transmisión de paquetes de datos de ejemplo de dos flujos de datos a través de dos enlaces de red, de acuerdo con una o más realizaciones de la invención.

Las Figuras 3A y 3B muestran una transmisión de paquetes de datos de ejemplo que incluye acuses de recibo de paquetes de datos recibidos, de acuerdo con una o más realizaciones de la invención.

La Figura 4 muestra una transmisión de paquetes de datos de ejemplo a través de dos enlaces de red, que incluye acuses de recibo de paquetes de datos recibidos, de acuerdo con una o más realizaciones de la invención.

Las Figuras 5A y 5B muestran métodos para transmitir paquetes de datos por un nodo de envío, de acuerdo con una o más realizaciones de la invención.

La Figura 6 muestra un método para recibir paquetes de datos por un nodo de recepción, de acuerdo con una o más realizaciones de la invención.

Las Figuras 7A y 7B muestran el uso de protocolos de agregación de único flujo para planificación de desbordamiento, de acuerdo con una o más realizaciones de la invención.

Las Figuras 8A y 8B muestran el uso de protocolos de agregación de único flujo para planificación de desbordamiento en aplicaciones de envío por flujo continuo de datos, de acuerdo con una o más realizaciones de la invención.

La Figura 9 muestra un sistema informático de acuerdo con una o más realizaciones de la invención.

Descripción detallada

A continuación, se describirán con detalle realizaciones específicas de la invención con referencia a las figuras adjuntas. Por razones de consistencia, elementos semejantes en las diversas figuras son denotados por números de referencia semejantes. Por razones de simplicidad, es posible que no se etiqueten elementos semejantes en todas las figuras.

En la siguiente descripción detallada de realizaciones de la invención, se exponen numerosos detalles específicos con el fin de proporcionar un entendimiento más completo de la invención. Sin embargo, será evidente para un experto en la materia que la invención se puede poner en práctica sin estos detalles específicos. En otros casos, no se han descrito con detalle características bien conocidas para evitar complicar de manera innecesaria la descripción.

De principio a fin de la solicitud, se pueden usar números ordinales (por ejemplo, primero, segundo, tercero, etc.) como un adjetivo para un elemento (es decir, cualquier sustantivo en la solicitud). El uso de números ordinales no implica ni crea una forma particular de ordenar los elementos, ni limita que elemento alguno sea solo un único elemento a menos que se divulgue expresamente, tal como mediante el uso de los términos "antes", "después", "único" y otras terminologías de este tipo. Además, el uso de números ordinales tiene como fin distinguir entre los elementos. A modo de ejemplo, un primer elemento es distinto de un segundo elemento, y el primer elemento puede abarcar más de un elemento y suceder (o preceder) al segundo elemento en una forma de ordenar los elementos.

En la siguiente descripción de las Figuras 1-9, cualquier componente descrito con respecto a una figura, en diversas realizaciones de la invención, puede ser equivalente a uno o más componentes de nombre semejante descritos con respecto a cualquier otra figura. Por brevedad, las descripciones de estos componentes no se repetirán con respecto a cada figura. De este modo, todas y cada una de las realizaciones de los componentes de cada figura se incorporan como referencia y se supone que están opcionalmente presentes dentro de cada una de las otras figuras que tengan uno o más componentes de nombre semejante. Adicionalmente, de acuerdo con varias realizaciones de la invención, cualquier descripción de los componentes de una figura se ha de interpretar como una realización opcional que se puede implementar además de, junto con o en lugar de las realizaciones descritas, con respecto a un componente de nombre semejante correspondiente, en cualquier otra figura.

Se ha de entender que las formas singulares "un", "una" y "el/la" incluyen referentes plurales, a menos que el contexto indique claramente otra cosa. Por lo tanto, por ejemplo, la referencia a "un haz horizontal" incluye la referencia a una o más de tales haces.

Términos tales como "aproximadamente", "sustancialmente", etc., pretenden indicar que no es necesario lograr con exactitud la característica, parámetro o valor indicado, sino que pueden tener lugar desviaciones o variaciones, incluyendo, por ejemplo, tolerancias, error de medición, limitaciones de exactitud de medición y otros factores conocidos por los expertos en la materia, en unas cantidades que no excluyen el efecto que la característica tenía por objeto proporcionar.

Se ha de entender que, una o más de las etapas mostradas en los diagramas de flujo se pueden omitir, repetir y/o realizar en un orden diferente al orden mostrado. En consecuencia, no se debería considerar que el alcance de la invención esté limitado a la disposición específica de etapas mostrada en los diagramas de flujo.

Aunque no se presentan múltiples reivindicaciones dependientes, será evidente para un experto en la materia que la materia objeto de las reivindicaciones dependientes de una o más realizaciones se puede combinar con otras reivindicaciones dependientes.

En una o más realizaciones de la invención, se usa un único protocolo de agregación de flujo para transmisiones de datos, como se describe posteriormente. La Figura 1 muestra transmisiones de datos en una red, de acuerdo con una o más realizaciones de la invención.

La Figura 1 muestra una red (100) de acuerdo con una o más realizaciones de la invención. La red (100) puede establecer una conexión física o virtual entre un nodo de envío (110) y un nodo de recepción (130). En una o más realizaciones de la invención, la conexión está formada por uno o más enlaces de red (120.1-120.M). Uno o más segmentos de estos enlaces de red pueden ser parte de una red de área extensa (WAN) (por ejemplo, Internet), mientras que otros segmentos pueden ser parte de una red de área local (LAN). En una o más realizaciones de la invención, un enlace de red (120.1-120.M) incluye una conexión de red física, por ejemplo, un medio físico que puede ser óptico o eléctrico, o una combinación de los mismos, es decir, que incluye segmentos eléctricos y ópticos. La conexión de red física puede incluir adicionalmente segmentos inalámbricos, sin alejarse de la invención. Cada enlace de red puede incluir múltiples segmentos con saltos intermedios a través de dispositivos de red tales como, por ejemplo, encaminadores, conmutadores, conmutadores de múltiples capas y/u otros tipos de dispositivos informáticos o de red (no mostrados).

Puede implementarse una o más capas de protocolo en la parte superior de la conexión de red física (capa 1). Estas capas pueden incluir una capa de enlace de datos (capa 2, tal como una capa de control de acceso al medio (MAC)), una capa de red (capa 3, tal como el protocolo de internet), y/u otras capas, tales como una capa de transporte (capa 4, para transmisión de segmentos de TCP y/o datagramas de UDP).

Cuando se confía en múltiples enlaces de red (120.1-120.M) para la comunicación entre el nodo de envío (110) y el nodo de recepción (130), algunos segmentos de estos múltiples enlaces de red pueden usar la misma infraestructura de red, mientras que otros segmentos pueden usar diferente infraestructura de red. Por ejemplo, considérese un escenario en el que una aplicación de software en un teléfono inteligente necesita comunicarse con un servidor remoto. Supóngase que el teléfono inteligente corresponde al nodo de envío (110) y que el servidor remoto corresponde al nodo de recepción (130). La aplicación de software, para aumentar el caudal de datos, usa la interfaz (por ejemplo, una interfaz Wi-Fi) de la red de área local inalámbrica (W-LAN) del teléfono inteligente y la interfaz de red celular del teléfono inteligente (por ejemplo, una interfaz LTE o una 3G) en paralelo. Por consiguiente, puede usarse un primer enlace de red (120.1) para transmitir datos al servidor remoto mediante la interfaz W-LAN del teléfono inteligente, y puede usarse un segundo enlace de red (120.2) para transmitir datos al servidor remoto mediante la interfaz celular del teléfono inteligente, usando de esta manera diferente infraestructura de red (es decir, los componentes de red en los que se basa la interfaz LAN y por la interfaz de red celular son diferentes). Supóngase adicionalmente que el servidor remoto usa una única interfaz de red para conectarse a internet. Por consiguiente, ambos enlaces de red incluyen también segmentos que usan la misma infraestructura de red (la interfaz de internet al servidor remoto), cuando se transmiten datos al servidor remoto. En el ejemplo descrito, otros segmentos de los dos enlaces de red pueden usar o no idéntica infraestructura de red. Por ejemplo, si los servicios de red de WLAN y celulares se operan por diferentes proveedores, es probable que los enlaces de red incluyan segmentos que no son idénticos, puesto que se operan por diferentes proveedores, cada uno basándose en su propia infraestructura. Los enlaces de red pueden tener adicionalmente diferentes capacidades. Por ejemplo, el ancho de banda de un enlace de red basado en Wi-Fi puede ser más alto que el ancho de banda de una interfaz 3G. Además, cualquier enlace de red puede tener uno o más cuellos de botella específicos a ese enlace de red. Por ejemplo, en conexiones de W-LAN, el cuello de botella puede estar provocado por el segmento entre el dispositivo con la interfaz WLAN y el proveedor de servicio de internet (ISP), por ejemplo, debido a que está limitada la tasa de datos proporcionada por el ISP. De manera similar, en conexiones celulares, el cuello de botella puede estar provocado por el enlace de red inalámbrica entre el dispositivo portátil y la estación base transceptora debido a limitaciones de ancho debanda de la norma de comunicación celular usada, la intensidad de señal y/u otros factores. Los expertos en la materia apreciarán que la invención no está limitada a una combinación de un enlace de red basado en W-LAN y un enlace basado en red celular. Por ejemplo, las realizaciones de la invención son igualmente aplicables a escenarios en los que un dispositivo usa un enlace de red basado en W-LAN únicamente o un enlace basado en red celular únicamente, los enlaces de red del mismo tipo que pueden ser alámbricos o inalámbricos, etc.

Continuando con el análisis de la Figura 1, el nodo de envío (110), de acuerdo con una o más realizaciones de la invención, puede ser cualquier tipo de dispositivo informático que se comunica mediante un enlace de red (120.1-120.M). El nodo de envío (110) puede ser un dispositivo móvil o no móvil, similar al dispositivo informático descrito con referencia a la Figura 9. En una o más realizaciones, el nodo de envío (110) puede incluir uno o más emisores de flujo (112.A-112.N). Un emisor de flujo puede ser, por ejemplo, una aplicación o un servicio que se ejecuta en el nodo de envío (110). Cada uno de estos emisores de flujo puede transmitir un flujo de datos (114.A-114.N) a un correspondiente receptor de flujo (132.A-132.N) de un nodo de recepción (130), como se describe adicionalmente a continuación. La transmisión de un flujo puede iniciarse, por ejemplo, como resultado de las acciones por un usuario que opera el nodo de envío (110), o por cualquier otra razón. Los flujos pueden transmitirse mediante uno o más de los enlaces de red (120.1-120.M). Un flujo, de acuerdo con una o más realizaciones de la invención, incluye una secuencia de porciones de datos (por ejemplo, bits, bytes, o porciones de datos de cualquier otra longitud), que pueden agruparse en paquetes de datos como se describe adicionalmente a continuación.

El nodo de recepción (130), de acuerdo con una o más realizaciones de la invención, puede ser cualquier tipo de dispositivo informático que se comunique mediante uno o más de los enlaces de red (120.1-120.M). El nodo de recepción (130) puede ser un dispositivo móvil o no móvil, similar al dispositivo informático descrito con referencia a la Figura 9.

En una o más realizaciones de la invención, el nodo de recepción (130) es un servidor de agregación que actúa como un intermediario entre el nodo de envío (110) y una red (por ejemplo, Internet). La parte opuesta, un cliente de agregación (no mostrado), puede ejecutarse en el nodo de envío (110). El cliente de agregación puede estar operando como una interfaz de red virtual para interconectar con los emisores de flujo (112.A-112.N). Como alternativa, la combinación de emisores de flujo (112.A-112.N) puede formar el cliente de agregación. El cliente de agregación, para dar servicio a múltiples dispositivos, puede también alojarse en un encaminador al que pueden conectarse múltiples dispositivos. Por lo tanto, los flujos de datos que se originan de múltiples dispositivos diferentes pueden beneficiarse del protocolo de agregación de único flujo. Si se usa un servidor de agregación y un cliente de agregación, todos los flujos de datos se transmiten entre los mismos dos puntos terminales (los nodos de envío y de recepción (110, 130). Por consiguiente, se comparte al menos alguno de los enlaces de red (120.1-120.M), o los segmentos de los enlaces de red entre todos los flujos de datos (114.A-114.N), aunque estos flujos de datos pueden transmitirse a través de muchos enlaces de red (120.1-120.M) independientes en paralelo. Al mismo tiempo, pueden transmitirse múltiples flujos de datos (114.A-114.N) a través del mismo enlace de red.

Para regular la distribución de flujos de datos (114.A-114.N) a través de enlaces de red (120.1-120.M), pueden implementarse los controles de congestión específicos de enlace (150.1-150.M), como se describe adicionalmente a continuación. Los expertos en la materia apreciarán que, aunque la Figura 1 muestra una configuración en la que todos los flujos de datos se dirigen a los receptores de flujo (132.A-132.N) del nodo de recepción (130), en otros escenarios, uno o más de los flujos puede dirigirse a otros receptores de flujo que no son parte del nodo de recepción (130).

En una o más realizaciones de la invención, se implementa un control de congestión específico de enlace (150.1-150.M) de manera separado para cada enlace de red (120.1.-120.M). Cada control de congestión específico de enlace puede determinar la capacidad del enlace de red con el que está asociado el control de congestión específico de enlace, y puede poner a disposición esta capacidad a los flujos de datos (114.A-114.N). Por lo tanto, pueden planificarse los datos de diferentes flujos entre enlaces de red (120.1-120.M) disponibles, basándose en la capacidad de estos enlaces de red, según se determina por los controles de congestión específicos de flujo (150.1-150.M) asociados a estos enlaces de red (120.1-120.M). Se proporciona a continuación una descripción detallada de los controles de congestión específicos de flujo con referencia a la Figura 2.

En una o más realizaciones de la invención, se implementa un control de ventana de recepción específico de flujo (160.A-160.N) para cada flujo de datos (114.A-114.N). Los controles de ventana de recepción específicos de flujo (160.A-160.N) pueden garantizar, de manera separada para cada flujo de datos (114A-114.N), que se envían los datos a una tasa que los correspondientes receptores de flujo (132.A-132.N) pueden procesar. Puesto que los receptores de flujo (132.A-132.N) pueden tener diferentes tamaños de memoria intermedia y pueden aceptar paquetes de datos de entrada en flujos de datos a diferentes tasas, los controles de ventana de recepción son específicos de flujo y no se ven afectados por la elección de los enlaces de red (120.1-120.M) en los que se basa un flujo de datos. Se proporciona a continuación una descripción detallada del control de ventana de recepción específico de flujo con referencia a la Figura 2.

La Figura 2 muestra una transmisión de paquetes de datos de ejemplo de dos flujos de datos a través de dos enlaces de red, de acuerdo con una o más realizaciones de la invención. Dos emisores de flujo de datos, A y B (112.A, 112.B), transmiten datos de dos flujos de datos, A y B (114.A, 114.B), mediante los dos enlaces de red, el enlace de red 1 y el enlace de red 2 (120.1, 120.2). Los datos obtenidos de los emisores de flujo de datos pueden transmitirse como paquetes de datos que pueden incluir cualquier número de porciones de datos. En el ejemplo mostrado en la Figura 2, un paquete de datos incluye diez porciones de datos, por ejemplo, diez bytes. El flujo de datos A (114.A) se origina del emisor de flujo A (112.A) y se recibe por el receptor de flujo A (132.A). De manera similar, el flujo de datos B (114.B) se origina del emisor de flujo B (112.B) y se recibe por el receptor de flujo B (132.B). Los controles de ventana de recepción específicos de flujo (160.A, 160.B) se implementan de manera separada para los flujos de datos A y B, como se describe posteriormente. Además, los controles de congestión específicos de enlace (150.1, 150.2) se implementan de manera separada para los enlaces de red 1 y 2 (120.1, 120.2), como se describe posteriormente.

Los controles de congestión específicos de flujo (150.1, 150.2) asociados a los enlaces de red (120.1, 120.2) pueden regular el flujo de datos a través de los enlaces de red usando ventanas de congestión (206.1,206.2). Si un enlace de red se vuelve más lento o más congestionado, puede reducirse el tamaño de la ventana de congestión asociada, dando como resultado, por lo tanto, la aceptación de menos paquetes de datos de los flujos de datos. Si otros enlaces de red no se ven afectados por la ralentización, pueden asignarse más paquetes de datos de los flujos de datos a estos otros enlaces de red.

En la Figura 2, se usa un planificador (222) para controlar de manera separada la transmisión de paquetes de datos a través de los enlaces de red 1 y 2 (120.1, 120.2), implementando, por lo tanto, los controles de congestión específicos de enlace (150.1, 150.2), de acuerdo con una o más realizaciones de la invención. El planificador (222) incluye un componente planificador en el lado del nodo de envío (110) y un componente planificador en el lado del nodo de recepción (130). El planificador (222) puede monitorizar la entrega de paquetes de datos al nodo de recepción (130) pero no distingue entre paquetes de datos dirigidos a los receptores de flujo A y B (132.A, 132.B), de acuerdo con una o más realizaciones de la invención. El componente planificador en el nodo de recepción puede realizar acuse de recibo de paquetes de datos recibidos y puede realizar una reordenación de paquetes de datos recibidos en una base por flujo, si fuera necesario. A medida que se entregan los paquetes de datos (224) a través de los enlaces de red (120.1, 120.2), se vuelve disponible la capacidad, en los enlaces de red, para adaptar paquetes de datos adicionales para que se transmitan mediante los enlaces de red. El planificador (222) mantiene, de manera separada para cada enlace de red, una cola (214.1, 214.2), en la que se almacenan paquetes de datos, proporcionados por los emisores de flujo A y B (112.A, 112.B), de acuerdo con una o más realizaciones de la invención. El número de paquetes de datos que pueden transferirse de las colas (214.1, 214.2) sobre los enlaces de red (120.1, 120.2) puede controlarse por las ventanas de congestión (206.1, 206.2). Únicamente pueden transferirse paquetes de datos que se adaptan en las ventanas de congestión a los enlaces de red (120.1, 120.2).

La ventana de congestión (206.1, 206.2) de cada cola (214.1, 214.2) se regula por un componente planificador (222) del nodo de envío (110), basándose en acuses de recibo obtenidos del nodo de recepción (130). El componente planificador (222) en el lado del nodo de recepción (130) es responsable de hacer acuse de recibo de paquetes de datos recibidos como se describe adicionalmente con referencia a las Figuras 3A-6. Como alternativa, el componente planificador (222) en el lado del nodo de recepción (130) puede también establecer las ventanas de congestión (206.1, 206.2) de las colas (214.1, 214.2) en el lado del nodo de envío (110). En el escenario ilustrativo de la Figura 2, el planificador (222) en el lado del nodo de envío (110) determina que el enlace de red 1 (120.1) tiene capacidad para 40 porciones de datos (cuatro paquetes de datos). Por consiguiente, la ventana de congestión 1 (206.1) se establece a 40, y, por lo tanto, pueden transferirse 40 porciones de datos al enlace de red 1. El planificador determina adicionalmente que enlace de red 2 (120.2) tiene capacidad para 30 porciones de datos (tres paquetes de datos). Por consiguiente, la ventana de congestión 2 (206.2), en el lado del nodo de envío (110) se establece a 30, y, por lo tanto, pueden transferirse 30 porciones de datos sobre el enlace de red 2. La planificación de capacidad disponible de los enlaces de red (120.1, 120.2) se realiza independiente de si los paquetes de datos (224) se originan desde el emisor de flujo A (112.A) o el emisor de flujo B (112.B), de acuerdo con una o más realizaciones de la invención. Por consiguiente, puede transmitirse una mezcla de paquetes de datos, originándose algunos desde el emisor de flujo A y originándose algunos desde el emisor de flujo B, mediante cada uno de los enlaces de red (120.1, 120.2).

En una o más realizaciones, el planificador (222) puede mantener adicionalmente una cola de retransmisión (no mostrada). La cola de retransmisión puede ocuparse por paquetes de datos que necesitan retransmitirse, como se analiza a continuación con referencia a las Figuras 5A y 5B. A diferencia de las colas (214.1, 214.2) que son específicas de enlace, la cola de retransmisión es global, es decir, puede almacenar paquetes de datos para cualquier enlace de red, y para cualquier flujo.

En la Figura 2, se controlan de manera separada dos flujos de datos (114.A, 114.B) por los controles de ventana de recepción específicos de flujo (160.A, 160.B), de acuerdo con una o más realizaciones de la invención. Se recibe el flujo de datos A (114.A) por el receptor de flujo A (132.A), que incluye una memoria intermedia A (234.A). La memoria intermedia A está configurada para adaptar hasta 70 porciones de datos (siete paquetes de datos). Como se muestra en la Figura 2, la memoria intermedia A (234.A) actualmente está ocupada por únicamente 20 porciones de datos, teniendo por lo tanto suficiente capacidad para otras 50 porciones de datos. Por consiguiente, el tamaño de la ventana de recepción A (216.A) se establece a 50. Por lo tanto, pueden proporcionarse 50 porciones de datos por el emisor de flujo A (112.A), para que se añadan a las colas (214.1, 214.2) de los enlaces de red 1 y 2. Además, se recibe el flujo de datos B (114.B) por el receptor de flujo B (132.B), que incluye una memoria intermedia B (234.B). La memoria intermedia B está configurada para acomodar hasta 60 porciones de datos. Como se muestra en la Figura 2, la memoria intermedia B (234.B) actualmente está ocupada por únicamente 10 porciones de datos, teniendo por lo tanto suficiente capacidad para otras 60 porciones de datos. Por consiguiente, el tamaño de la ventana de recepción B (216.B) se establece a 60. Por lo tanto, pueden proporcionarse 60 porciones de datos por el emisor de flujo B (112.B), para que se añadan a las colas (214.1, 214.2) de los enlaces de red 1 y 2.

La implementación de controles de ventana de recepción específicos de flujo (160A, 160B) y los controles de congestión específicos de enlace (150.1, 150.2) se describe a continuación con referencia a las Figuras 3-6.

Las Figuras 3A y 3B muestran una transmisión de paquetes de datos de ejemplo que incluye acuses de recibo de paquetes de datos recibidos usando números de secuencia por enlace y números de secuencia por flujo, de acuerdo con una o más realizaciones de la invención. Los números de secuencia de flujo pueden usarse para propósitos específicos de flujo, mientras que los números de secuencia de enlace pueden usarse para propósitos específicos de enlace. Más específicamente, los números de secuencia de flujo pueden usarse para hacer acuse de recibo de entrega en orden de paquetes de datos. Pueden usarse adicionalmente para controlar el tamaño de la ventana de recepción, de manera separada para cada flujo. La separación de ventanas de recepción para diferentes flujos puede evitar que flujos lentos (por ejemplo, flujos con un receptor de flujo lento o con saltos de red adicionales más lentos, más allá del servidor de agregaciones) ralenticen otros flujos que de otra manera podrían operar más rápido. Sin embargo, los números de secuencia de flujo, de acuerdo con una o más realizaciones de la invención, no se usan por el control de congestión específico de enlace. En su lugar, el control de congestión específico de enlace puede basarse en los números de secuencia de enlace. En una o más realizaciones de la invención, cada paquete de datos se acompaña, por lo tanto, por un número de secuencia de flujo específico de flujo y un número de secuencia de enlace específico de enlace, como se muestra en las Figuras 3A y 3B.

Las Figuras 3A y 3B muestran la transmisión de paquetes de datos de acuerdo con una o más realizaciones de la invención, de un nodo de envío (110) a un nodo de recepción (130). La Figura 3A muestra una primera transmisión que incluye acuses de recibo de la transmisión, y la Figura 3B muestra una segunda transmisión que sigue a la primera transmisión. Las transmisiones en las Figuras 3A y 3B incluyen paquetes de datos asociados a dos diferentes flujos de datos, y las transmisiones se realizan a través de un único enlace de red. Las flechas dirigidas hacia la derecha en las Figuras 3A y 3B indican transmisiones de enlace de red (322). En la Figura 3A, se transmiten 50 porciones de datos dispuestas en paquetes de datos (224), incluyendo cada uno 10 porciones de datos que llevan una carga útil (no mostrada). Se asigna un número de secuencia de enlace (324) y números de secuencia de flujo (326) a cada paquete de datos (224). Las flechas dirigidas hacia la izquierda indican acuses de recibo de enlace de red (332) de paquetes de datos recibidos, enviados por el nodo de recepción (130), al nodo de envío (110). Cada acuse de recibo de paquete (334) incluye un acuse de recibo de secuencia de enlace (336) y un acuse de recibo de secuencia de flujo (338). Como alternativa, un acuse de recibo de paquete (334) puede incluir un acuse de recibo de secuencia de enlace (336) únicamente.

Cada porción de datos tiene asignada un número de secuencia de flujo (326). Como se ilustra en la Figura 3A, el primer conjunto de 10 porciones de datos (primer paquete de datos) tiene asignado los números de secuencia de flujo (326) 100-109. El siguiente conjunto de 10 porciones de datos (segundo paquete de datos) tiene asignado los números de secuencia de flujo (326) 110-119, etc. Estos números de secuencia de flujo (326) permanecen válidos, incluso en caso de una retransmisión, como se analiza adicionalmente a continuación.

Cada paquete de datos tiene asignado adicionalmente un número de secuencia de enlace (324). Los números de secuencia de enlace están asignados independientemente de los flujos de datos que pasan el enlace de red. Además, independientemente del tamaño de un paquete de datos, siempre se asigna un único número de secuencia de enlace a un único paquete de datos. Si necesita retransmitirse un paquete de datos (por ejemplo, debido a una pérdida de paquete o debido a un tiempo de espera), se asignará un nuevo número de secuencia de enlace al paquete retransmitido. Por consiguiente, no pueden reutilizarse números de secuencia de enlace, a menos que se haya agotado el rango de números de secuencia de enlace disponible, y tenga lugar por lo tanto un bucle de los números de secuencia de enlace.

Como se ha observado previamente, se realiza acuse de recibo de las transmisiones recibidas de porciones de datos en paquetes de datos usando acuses de recibo de paquete. Considérese la transmisión de enlace de red (322) y el acuse de recibo de enlace de red (332) en la Figura 3A. En la transmisión de enlace de red (322), se transmiten cinco paquetes de datos (224). Estos paquetes de datos tienen números de secuencia de flujo (326) 100-109, 110-119, 360­ 369, 120-129 y 130-139, identificando de manera inequívoca los números de secuencia de flujo porciones de datos en una manera específica de flujo. Únicamente puede etiquetarse la primera porción de datos de un paquete de datos. Los números de secuencia de flujo de porciones de datos posteriores en un paquete de datos pueden calcularse basándose en la ubicación de las porciones de datos en el paquete de datos. Por consiguiente, los números de secuencia de flujo que se incluyen en la transmisión de ejemplo de la Figura 3A pueden ser 100, 110, 360, 120 y 130. Supóngase que el paquete de datos con números de secuencia de flujo 360-369 pertenece al flujo de datos B (114.B) de la Figura 2, mientras que todos los otros paquetes de datos pertenecen al flujo de datos A (114.A) de la Figura 2.

Los números de secuencia de enlace (324) 31-35 consecutivos se asignan a los paquetes de datos (224) de la transmisión de enlace de red (322). El acuse de recibo de enlace de red (332), por el nodo de recepción (130), al nodo de envío (110), incluye los acuses de recibo de paquete (334) para los paquetes de datos enviados durante la transmisión de enlace de red previamente analizada. Un acuse de recibo de paquete (334) de un paquete de datos puede incluir un acuse de recibo de secuencia de flujo (338) y un acuse de recibo de secuencia de enlace (336). El acuse de recibo de secuencia de enlace incluye el número de secuencia de enlace que, en la transmisión de enlace de red (322), se asignó al paquete de datos al que se estaba haciendo acuse de recibo. El acuse de recibo de secuencia de flujo (338) puede incluir la porción de datos recibidos finalmente ordenada 1 dentro de ese flujo, indicando de esta manera la siguiente porción de datos esperada. Como alternativa, un acuse de recibo de paquete (334) puede no incluir un acuse de recibo de secuencia de flujo (338). En la Figura 3A, considérese, por ejemplo, el primer acuse de recibo en la secuencia de los acuses de recibo de enlace de red. Este acuse de recibo se proporciona por el nodo de recepción, en respuesta a la recepción del paquete de datos asociado a el número de secuencia de enlace 31 y los números de secuencia de flujo 100-109. Por consiguiente, el acuse de recibo incluye el acuse de recibo de secuencia de enlace 31 y el acuse de recibo de secuencia de flujo 110.

En el acuse de recibo de enlace de red (332), puede reducirse el volumen de datos requerido para la transmisión de acuses de recibo de diversas maneras incluyendo acuses de recibo para múltiples paquetes de datos recibidos en un único acuse de recibo de paquete. En lugar de proporcionar el número de secuencia de enlace completo de cada paquete que va a realizarse acuse de recibo, pueden proporcionarse los números de secuencia de enlace adicionales que se van a incluir en un único acuse de recibo de paquete, por ejemplo, como una lista ordenada, representada por desplazamientos del primer número de secuencia de enlace proporcionado completamente en el acuse de recibo de paquete. Estos desplazamientos pueden posibilitar una representación más compacta, en comparación con enviar los números de secuencia de enlace de todos los paquetes de datos que se van a realizar acuse de recibo. Como alternativa, un acuse de recibo de secuencia de enlace puede incluir un primer número de secuencia de enlace y un último número de secuencia de enlace, que indican una secuencia de paquetes de datos recibidos consecutivamente asociados a el primer número de secuencia de enlace, el último número de secuencia de enlace y todos los números de secuencia de enlace entre medias. Además, un acuse de recibo de secuencia de enlace puede incluir un primer o un último número de secuencia de enlace y una serie de desplazamientos que indican paquetes de datos recibidos y no recibidos. Por ejemplo, el acuse de recibo de secuencia de enlace "1200, 10, 5, 10" puede indicar que después del número de secuencia de enlace 1200, se recibieron diez paquetes de datos, no se recibieron cinco paquetes de datos y se recibieron de nuevo diez paquetes de datos. En otras palabras, se recibieron los paquetes de datos asociados a los números de secuencia de enlace 1200-1210, no se recibieron los paquetes de datos asociados a los números de secuencia de enlace 1211-1215 y se recibieron los paquetes de datos asociados a los números de secuencia de enlace 1216-1225.

Obsérvese que, el acuse de recibo de enlace de red (332) incluye acuses de recibo de paquete (334) para únicamente cuatro paquetes de datos, aunque se enviaron cinco paquetes de datos (224) en la transmisión de enlace de red (322). Supóngase que se perdió el segundo paquete de datos transmitido (número de secuencia de enlace 32 y número de secuencia de flujo 110-119). Por consiguiente, el acuse de recibo del primer paquete de datos (acuse de recibo de secuencia de enlace "31", el acuse de recibo de secuencia de flujo "110") es seguido por un acuse de recibo del tercer paquete de datos (acuse de recibo de secuencia de enlace 33, acuse de recibo de secuencia de flujo 370), mientras que no haya acuse de recibo para el segundo paquete de datos (acuse de recibo de secuencia de enlace 32, acuse de recibo de secuencia de flujo 120). Obsérvese además que, para todos los paquetes habiendo realizado acuse de recibo posteriormente con el flujo de datos A (114.A), permanece el acuse de recibo de secuencia de flujo 110, puesto que la porción de datos con el número de secuencia de flujo 110 es la siguiente porción de datos esperada del flujo 1.

El nodo de envío (110), que recibe los acuses de recibo de enlace de red (332), por lo tanto, sabe que se recibieron satisfactoriamente todos los paquetes del flujo de datos B (114.B), mientras que se perdió el paquete con los números de secuencia de flujo 110-119 y el número de secuencia de enlace 32 del flujo A (114.A). El nodo de envío puede detectar acuses de recibo perdidos comparando los acuses de recibo de paquete recibidos contra los paquetes previamente transmitidos, por ejemplo, basándose en los acuses de recibo de secuencia de enlace recibidos (336) con números de secuencia de enlace y números de secuencia de flujo almacenados de los paquetes de datos previamente transmitidos. A pesar de la pérdida de un paquete de datos del flujo de datos 1, puede evitarse la retransmisión de paquetes de datos del flujo de datos B.

La Figura 3B muestra una segunda transmisión de enlace de red, después de la primera transmisión de primer enlace de red mostrada en la Figura 3A. Similar a la primera transmisión de enlace de red, la segunda transmisión de enlace de red (322) incluye los paquetes de datos (224), cada uno de los cuales se acompaña por un número de secuencia de enlace (324) y un número de secuencia de flujo (326). El primer paquete de datos transmitido (224) está asociado a los números de secuencia de flujo (326) 140-149, y el número de secuencia de enlace (324) 36. Sin embargo, obsérvese que el primer acuse de recibo de paquete (334) incluye el acuse de recibo de secuencia de enlace (336) 36 y el acuse de recibo de secuencia de flujo (338) 110, debido a que aún no se han proporcionado las porciones de datos con los números de secuencia de flujo 110-119.

El segundo paquete de datos transmitido (224) está asociado al número de secuencia de flujo (326) 110-119, y el número de secuencia de enlace (324) 37. Este paquete de datos (224) es una retransmisión, por el nodo de envío (110), del paquete de datos inicialmente perdido. Por consiguiente, el segundo acuse de recibo de paquete (334) incluye el acuse de recibo de secuencia de enlace (336) 37 y el acuse de recibo de secuencia de flujo (338) 150, debido a que ahora se han proporcionado las porciones de datos con los números de secuencia de flujo 110-119, y, además, también se han proporcionado ya y se ha realizado acuse de recibo de las porciones de datos con los números de secuencia de flujo 120-149. Los dos paquetes de datos posteriormente transmitidos se reciben satisfactoriamente por el nodo de recepción, y los acuses de recibo de paquete se devuelven al nodo de envío, en consecuencia.

La Figura 4 muestra una transmisión de paquetes de datos de ejemplo a través de dos enlaces de red, que incluye acuses de recibo de paquetes de datos recibidos, de acuerdo con una o más realizaciones de la invención. La Figura 2, por lo tanto, ilustra cómo las realizaciones de la invención, inicialmente analizadas para un único enlace de red con referencia a las Figuras 3A y 3B, se generalizan a escenarios de múltiples enlaces.

En la Figura 4, se transmiten dos flujos de datos (flujo 1, flujo 2) usando dos enlaces de red (enlace 1 y enlace 2). En el diagrama, el flujo 1 usa los números de secuencia que empiezan en 100, y el flujo 2 usa los números de secuencia que empiezan en 360. Estos números de secuencia, de acuerdo con una o más realizaciones de la invención, son independientes y los números de secuencia del flujo 1 pueden alcanzar o superar eventualmente los números de secuencia del flujo 2, y viceversa. El diagrama presenta el orden de operaciones que ocurren en ambos anfitriones (anfitrión de envío A, anfitrión de recepción B), progresando el tiempo en una dirección hacia abajo vertical. La misma línea temporal se aplica a las transmisiones a través de los enlaces 1 y 2.

En la transmisión ilustrativa, se envían los paquetes de datos del flujo 1, un paquete de datos con números de secuencia de flujo 100-109 a través del enlace 1, y un paquete de datos con números de secuencia de flujo 110-119 a través del enlace 2. Se pierde el siguiente paquete de datos enviado a través del enlace 1 (números de secuencia de flujo 120-129). Posteriormente, se envían los paquetes de datos del segundo flujo (números de secuencia de flujo 360-369 y 370-379) a través de los enlaces 1 y 2, respectivamente, etc.

Obsérvese que, cuando se entrega el paquete de datos con número de secuencia de enlace 61 (números de secuencia de datos 110-119) a través del enlace 2, se genera un acuse de recibo. El acuse de recibo incluye el acuse de recibo de secuencia de enlace 61, y el acuse de recibo de secuencia de flujo 100, puesto que no se ha recibido aún el paquete de datos con números de secuencia de flujo 100-109 enviado a través del enlace 1 (véase la línea horizontal discontinua más superior, que indica el tiempo en el que se envió el acuse de recibo de secuencia de flujo). Sin embargo, esto no indica necesariamente que se haya perdido un paquete de datos. De manera similar, el acuse de recibo en respuesta al paquete de datos con número de secuencia de enlace 62 únicamente realiza acuse de recibo de la entrega de paquetes de datos del segundo flujo hasta el número de secuencia de flujo 360 puesto que no se ha recibido aún el paquete de datos con números de secuencia de flujo 360-369 (véase la línea horizontal de línea discontinua central, que indica el tiempo en el que se envió el acuse de recibo de secuencia de flujo).

En el enlace 1, cuando se entrega el paquete de datos con número de secuencia de enlace 31, se genera un acuse de recibo para el número de secuencia de enlace 31, y las porciones de datos hasta 120, puesto que se recibió anteriormente el paquete de datos con las porciones de datos 110-119.

Se pierde el paquete de datos con número de secuencia de enlace 32. El anfitrión A aprende acerca del paquete de datos perdido cuando recibe un acuse de recibo para un paquete de datos con número de secuencia de enlace 33, sin ver un acuse de recibo para el paquete de datos con número de secuencia de enlace 32. El acuse de recibo de secuencia de enlace 33 confirma la entrega de porciones de datos del segundo flujo hasta el número de secuencia 380 y, por lo tanto, confirma la recepción de porciones de datos asociadas a los números de secuencia de flujo 360­ 369 a través del enlace 1 y porciones de datos asociadas a los números de secuencia de flujo 370-379 a través del enlace 2. En respuesta, el anfitrión A continúa enviando otro paquete de datos del segundo flujo (número de secuencia de enlace 37, números de secuencia de flujo 380-389). Además, el anfitrión A tiene conocimiento de la necesidad de retransmitir el paquete de datos previamente perdido (números de secuencia de flujo 120-129). El anfitrión A, por lo tanto, envía este paquete de datos a través del enlace 2, usando el número de secuencia de enlace 64. Como alternativa, el anfitrión A podría haber elegido retransmitir el paquete de datos perdido a través del enlace 1, usando, por ejemplo, el número de secuencia de enlace 38.

Cuando el anfitrión B recibe el paquete de datos asociado a un número de secuencia de enlace 64, realiza acuse de recibo del paquete de datos. Obsérvese que, se hace acuse de recibo de los paquetes de datos del flujo 1 hasta el número de secuencia de flujo 170, puesto que después de la recepción de los paquetes de datos retransmitidos 120­ 129, se han recibido todos los paquetes de datos del flujo 1 hasta el número de secuencia de flujo 170.

En el ejemplo anterior, debido al uso de una combinación de números de secuencia de flujo y números de secuencia de enlace únicos, únicamente se retransmitió el paquete de datos perdido, sin retransmitir innecesariamente otros paquetes de datos. Además, el ejemplo anterior ilustra la posibilidad de replanificación de paquete de datos espontánea a través de múltiples enlaces (aunque el paquete de datos perdido se transmitió originalmente a través del enlace 1, la retransmisión tuvo lugar a través del enlace 2 puesto que el enlace 2 resultó estar disponible para transmisión de un paquete de datos). Esta característica se posibilita por los números de secuencia de enlace únicos (es decir, números de secuencia de enlace que no se reutilizan). La disponibilidad de un enlace puede regularse por el control de congestión específico de enlace, previamente analizado con referencia a las Figuras 1 y 2. Por ejemplo, si un enlace repentinamente se vuelve más lento y empieza a descartar paquetes de datos, su ventana de congestión se comprimirá rápidamente, y los paquetes perdidos se enviarán inmediatamente a través de diferentes enlaces que no experimenten ralentización.

Las Figuras 5A-6 muestran diagramas de flujo de acuerdo con una o más realizaciones de la invención.

Aunque se presentan y describen las diversas etapas en los diagramas de flujo de manera secuencial, un experto en la materia apreciará que alguna o todas estas etapas pueden ejecutarse en diferentes órdenes, pueden combinarse u omitirse y algunas de las etapas pueden ejecutarse en paralelo. En una realización de la invención, las etapas mostradas en las Figuras 5A-6 pueden realizarse en paralelo con cualquier otra etapa mostrada en las Figuras 5A-6 sin alejarse de la invención.

La Figura 5A muestra un método para transmitir paquetes de datos por un nodo de envío, de acuerdo con una o más realizaciones de la invención. Más específicamente, el método de la Figura 5A puede usarse para ajustar, en el nodo de envío, ventanas de recepción asociadas a flujos de datos y ventanas de congestión asociadas a enlaces de red. El método de la Figura 5A puede ejecutarse repetitivamente para detectar y procesar acuses de recibo de paquete proporcionados por el nodo de recepción.

En la etapa 500, se recibe un acuse de recibo de paquete. El acuse de recibo de paquete incluye un acuse de recibo de secuencia de flujo específico de flujo y un acuse de recibo de secuencia de enlace específico de enlace, como se ha analizado anteriormente con referencia a las Figuras 3A, 3B y 4. Como alternativa, el acuse de recibo de paquete puede incluir un acuse de recibo de secuencia de enlace específico de enlace únicamente. El acuse de recibo de paquete puede haberse enviado por un nodo de recepción, como se describe en la etapa 608 de la Figura 6.

En la etapa 502, se retira el paquete de datos habiendo realizado acuse de recibo, basándose en el acuse de recibo de paquete, de la cola de enlace que se usó para transmitir el paquete de datos. Además, si se determina que hay otros paquetes de datos que no se ha realizado acuse de recibo en la cola de enlace (o alguna de las colas de enlace), el paquete que no se ha realizado acuse de recibo puede moverse a la cola de retransmisión. Un paquete de datos puede considerarse perdido, basándose en diversos criterios. Por ejemplo, como se ha analizado anteriormente con referencia a las Figuras 3A, 3B y 4, un paquete de datos puede considerarse perdido, si se recibe un acuse de recibo de paquete para un paquete de datos enviado a través de un enlace de red, pero no se recibió acuse de recibo para un paquete de datos anterior enviado a través del enlace de red. Además, o como alternativa, puede implementarse un criterio de tiempo de espera, de manera que un paquete de datos se considera perdido si no se recibe acuse de recibo de paquete para ese paquete de datos dentro de una ventana de tiempo especificado. Las causas para paquetes de datos perdidos incluyen, pero sin limitación, cargas en enlaces de red que superan la capacidad del enlace de red y retardos de transmisión.

En la etapa 504, se ajusta la ventana de recepción del flujo de datos con el que está asociado el acuse de recibo de paquete que se recibió en la etapa 500. El ajuste puede realizarse, por ejemplo, basándose en información proporcionada por el nodo de recepción con respecto a la capacidad de la memoria intermedia del receptor de flujo. Aunque la memoria intermedia puede tener una capacidad total conocida, la memoria intermedia disponible puede ser diferente y puede comunicarse al nodo de envío para ajustar la ventana de recepción del correspondiente emisor de flujo.

En la etapa 506, se ajusta la ventana de congestión del enlace de red con el que está asociado el acuse de recibo de paquete que se recibió en la etapa 500. El ajuste se realiza independiente del ajuste de la ventana de recepción, de acuerdo con una o más realizaciones de la invención. Puede usarse un algoritmo de control de congestión para determinar el tamaño de la ventana de congestión. Pueden usarse diversos algoritmos de control de congestión, sin alejarse de la invención. Por ejemplo, puede usarse un algoritmo de control de congestión similar a un algoritmo de control de congestión de TCP o combinaciones de diferentes algoritmos de control de TCP. Además, puede implementarse una conmutación dinámica entre diferentes algoritmos de control de congestión, por ejemplo, en una manera dependiente del escenario.

La Figura 5B muestra un método para transmitir paquetes de datos por un nodo de envío, de acuerdo con una o más realizaciones de la invención. Más específicamente, puede usarse el método de la Figura 5B para enviar paquetes de datos, por el nodo de envío, al nodo de recepción. El método de la Figura 5B puede ejecutarse repetitivamente para enviar múltiples paquetes de datos. La ejecución de las etapas de la Figura 5B puede verse afectada por la ejecución de las etapas de la Figura 5A.

En la etapa 550, se realiza una determinación acerca de si la ventana de congestión del enlace de red asociada al acuse de recibo de paquete obtenido en la etapa 500 permite la transmisión de un paquete de datos a través del enlace de red. Más específicamente, una ventana de congestión de un tamaño que es distinto de cero puede permitir la transmisión de paquetes de datos. Por ejemplo, una ventana de congestión del tamaño "40" puede permitir el envío de 40 porciones de datos, es decir, cuatro paquetes de datos a través del enlace de red asociado. El tamaño de la ventana de congestión se controla como se ha descrito anteriormente con referencia a la Figura 5A.

Si se realiza una determinación de que la ventana de congestión del enlace de red permite el envío de un paquete de datos, el método puede continuar a la etapa 552. Si el enlace de red no permite el envío de un paquete de datos, el método puede continuar a la etapa 560.

En la etapa 552, se realiza una determinación acerca de si la cola de retransmisión contiene un paquete de datos. La cola de retransmisión puede contener un paquete si se ha perdido un paquete previamente enviado. Si existe un paquete de datos en la cola de retransmisión, el método puede continuar directamente a la etapa 558, omitiendo las etapas 554 y 556. Si se encuentra que la cola de retransmisión está vacía, el método puede continuar a la etapa 554. En la etapa 554, se identifica un flujo de datos que está asociado a una ventana de recepción que permite el envío de paquetes de datos. Un flujo de este tipo puede ser cualquier flujo con paquetes de datos disponibles para transmisión y una ventana de recepción con un tamaño que es distinto de cero.

En la etapa 556, se realiza una determinación acerca de si se ha identificado un flujo de datos, en la etapa 554. Si no se ha identificado un flujo de este tipo, la ejecución del método puede terminar (para repetir con el siguiente ciclo de ejecución). Si se ha identificado un flujo, el método puede continuar a la etapa 558.

En la etapa 558, se envía el paquete de datos a través del enlace de red. El paquete de datos enviado puede ser un paquete de datos obtenido de la cola de retransmisión si se ha alcanzado la etapa 558 directamente de la etapa 552, o puede ser un paquete de datos obtenido de un flujo de datos, si se alcanzó la etapa 558 desde la etapa 556. Volviendo a la etapa 550, si el enlace de red no permite el envío de un paquete de datos, el método puede continuar a la etapa 560. En la etapa 560, se realiza una determinación acerca de si la cola de retransmisión contiene un paquete de datos. Si existe un paquete de datos en la cola de retransmisión, el método puede continuar directamente a la etapa 564. Si se encuentra que la cola de retransmisión está vacía, el método puede continuar a la etapa 562.

En la etapa 562, se realiza una determinación acerca de si la ventana de recepción del flujo de datos asociada al acuse de recibo de paquete obtenido en la etapa 500 permite la transmisión de un paquete de datos. Más específicamente, una ventana de recepción de un tamaño que es distinto de cero puede permitir la transmisión de paquetes de datos. Por ejemplo, una ventana de recepción del tamaño "50" puede permitir el envío de 50 porciones de datos, es decir, cinco paquetes de datos del flujo de datos. El tamaño de la ventana de recepción se controla como se ha descrito anteriormente con referencia a la Figura 5A.

Si se realiza una determinación de que la ventana de recepción del emisor de flujo permite el envío de un paquete de datos, el método puede continuar a la etapa 564. Si la ventana de recepción del emisor de flujo no permite el envío de un paquete de datos (por ejemplo, debido a que el tamaño de la ventana de recepción es cero o debido a que actualmente no hay paquetes de datos para enviarse), el método puede terminar (para repetir con el siguiente ciclo de ejecución).

En la etapa 564, se identifica un enlace de red cuya ventana de congestión permite que se envíe el paquete de datos. Cualquier enlace de red puede ser un candidato, siempre que su ventana de congestión asociada pueda acomodar el paquete de datos.

En la etapa 566, se realiza una determinación acerca de si se identificó un enlace de red adecuado en la etapa 564. Si se identificó un enlace de red, el método puede continuar a la etapa 568. Si no se identificó enlace de red, el método puede terminar (para repetir con el siguiente ciclo de ejecución).

En la etapa 568, el paquete de datos del flujo de datos se envía a través del enlace de red, y posteriormente el método puede volver a la etapa 560.

En el diagrama de flujo de la Figura 5B, las etapas 550-558 se refieren a hacer uso de la ventana de congestión disponible del enlace de red para el que se recibió el acuse de recibo, dirigiendo paquetes de datos de todos los flujos de datos a la cola controlada por la ventana de congestión. Los paquetes de datos en la cola de retransmisión reciben tratamiento preferencial. Además, las etapas 560-570 se refieren a inspeccionar el flujo de datos para el que se recibió el acuse de recibo y para distribuir paquetes de datos disponibles de este flujo de datos a enlaces de red que están disponibles para transmisión. Los paquetes de datos en la cola de retransmisión reciben tratamiento preferencial. La Figura 6 muestra un método para recibir paquetes de datos por un nodo de recepción, de acuerdo con una o más realizaciones de la invención. El método puede ejecutarse repetitivamente para procesar paquetes de datos a medida que se reciben a través de uno o más enlaces de red.

En la etapa 600, se recibe un paquete de datos por el nodo de recepción.

En la etapa 602, se extrae el número de secuencia de enlace del paquete de datos recibido. En la etapa 604, se extrae el número de secuencia de flujo del paquete de datos recibido. En la etapa 606, se reenvía el paquete de datos recibido al receptor de flujo apropiado del nodo de recepción.

En la etapa 608, se devuelve un acuse de recibo al nodo de envío. Como se ha analizado anteriormente, el acuse de recibo incluye un acuse de recibo de secuencia de enlace y un acuse de recibo de secuencia de flujo opcional, basándose en el número de secuencia de enlace y el número de secuencia de flujo extraído del paquete de datos recibido.

Las realizaciones de la invención pueden implementarse de diversas maneras. En una realización de la invención, el protocolo de agregación de flujo único se implementa usando un enfoque de tunelización. Los túneles entre el nodo de envío y el nodo de recepción pueden proporcionarse por diversos protocolos subyacentes tales como, por ejemplo, el protocolo UDP. Usando este enfoque, ninguno de los componentes de la infraestructura de red, además del nodo de envío y el nodo de recepción, necesitan ser aptos para procesamiento del protocolo de agregación de flujo único. Como alternativa, el protocolo de agregación de flujo único puede implementarse sin basarse en túneles, por ejemplo, como un protocolo de capa de transporte. Una implementación de este tipo puede intentar que sus comunicaciones imiten a la apariencia de otros protocolos ampliamente usados tales como, por ejemplo, el protocolo de TCP, para aumentar la probabilidad de que la infraestructura de red implicada al procesar estas comunicaciones pueda manejarlas.

Las realizaciones de la invención pueden implementarse en software, una combinación de software y hardware y hardware en solitario. Las soluciones de hardware y las soluciones de hardware parciales pueden ser similares a motores de descarga de TCP/IP con las funcionalidades de protocolo que se implementan parcial o completamente en hardware, por ejemplo, en un circuito de FPGA o ASIC.

Se pretende que los escenarios de caso de uso descritos a continuación proporcionen ejemplos para aplicar el protocolo de agregación de único flujo en aplicaciones de desbordamiento en las que se usan múltiples enlaces de red para transmitir datos. Sin embargo, el protocolo de agregación de único flujo previamente descrito no está limitado a aplicaciones de desbordamiento, y puede ser universalmente aplicable a una amplia gama de aplicaciones de comunicación.

La Figura 7A muestra el uso de protocolos de agregación de único flujo para planificación de desbordamiento, de acuerdo con una o más realizaciones de la invención.

El protocolo de agregación de flujo único, o más específicamente, el algoritmo que dirige paquetes de datos a enlaces de red, puede estar configurado para tener en cuenta un caudal global requerido ("caudal objetivo"). Los enlaces de red pueden regularse según sea necesario para obtener este caudal objetivo. Por ejemplo, un enlace de red puede estar basado en su tasa de datos máxima, y si el caudal objetivo supera esta tasa de datos, pueden usarse enlaces de red adicionales también.

Considérense los escenarios ilustrativos ilustrados en la Figura 7A. Están disponibles dos enlaces de red para la transmisión de datos. El primer enlace de red es un enlace de red Wi-Fi con una capacidad de 5 MB/s, y el segundo enlace de red es un enlace de red LTE con una capacidad de 5 MB/s. Ambos enlaces de red están configurados para operar como enlaces secundarios, es decir, ambos enlaces de red se usan únicamente al nivel necesario para conseguir el caudal deseado. Supóngase que el planificador, previamente introducido con referencia a la Figura 2, está configurado para basarse principalmente en el enlace de red Wi-Fi, y para usar el enlace de red LTE únicamente si el caudal objetivo supera la capacidad del enlace de red Wi-Fi.

En un primer escenario, el caudal objetivo se establece a 4 MB/s. El enlace de red Wi-Fi en solitario es lo suficientemente rápido para enviar datos a esta tasa, y, por consiguiente, no se usa el enlace de red LTE. Puesto que el enlace de red Wi-Fi está configurado como un enlace de red secundario, está limitado a operar a un caudal de 4 MB/s.

En un segundo escenario, el caudal objetivo se eleva a 5 MB/s. El enlace de red Wi-Fi aún es suficiente, y, por consiguiente, no se usa aún el enlace de red LTE. En un tercer escenario, el caudal objetivo se eleva a 6 MB/s. El enlace de red Wi-Fi ya no es suficiente más para proporcionar el caudal necesario, y, por consiguiente, se usa también el enlace de red LTE. El enlace de red LTE contribuye 1 MB/s para alcanzar una tasa de datos de 6 MB/s. En un cuarto escenario, el caudal objetivo se eleva hasta 10 MB/s, que da como resultado que tanto los enlaces de red Wi-Fi como de LTE operen a 5 MB/s. Para cualquier rendimiento objetivo por encima de 10 MB/s, se obtendría el mismo resultado puesto que ambos enlaces de red están saturados.

La Figura 7B muestra el uso de protocolos de agregación de único flujo para planificación de desbordamiento, de acuerdo con una o más realizaciones de la invención. Similar a los escenarios en la Figura 7A, están disponibles dos enlaces de red para la transmisión de datos. El primer enlace de red es un enlace de red Wi-Fi con una capacidad de 5 MB/s, y el segundo enlace de red es un enlace de red LTE con una capacidad de 5 MB/s. En la Figura 7B, el enlace de red Wi-Fi está configurado para operar como un enlace primario, mientras que el enlace de red LTE está configurado para operar como un enlace secundario. Por consiguiente, el enlace de red Wi-Fi siempre se opera en su capacidad disponible de 5 MB/s, mientras que el enlace de red LTE se usa únicamente en el nivel necesario para conseguir el caudal deseado. El planificador está configurado para basarse principalmente en el enlace de red Wi-Fi, y para usar el enlace de red LTE únicamente si el caudal objetivo supera la capacidad del enlace de red Wi-Fi.

Similar a los escenarios descritos con referencia a la Figura 7A, los escenarios mostrados en la Figura 7B requieren caudales objetivo de 4, 5, 6 y 10 MB/s. Sin embargo, a diferencia de los escenarios de la Figura 7A, en la Figura 7B, en todos los escenarios, siempre se usa la capacidad disponible total de 5 MB/s del enlace de red Wi-Fi, mientras que únicamente se usa la capacidad necesaria adicionalmente necesaria para el enlace de red LTE.

Generalizando los escenarios de las Figuras 7A y 7B, el planificador puede estar configurado para operar cero, uno o múltiples enlaces de red primarios que siempre se usan completamente y/o una selección de redes secundarias que pueden usarse en un orden configurable. Los enlaces secundarios pueden añadirse a la agrupación de los enlaces de red según sean necesarios para obtener la tasa de caudal objetivo.

Esta funcionalidad del planificador posibilita el uso optimizado de ancho de banda de bajo coste (por ejemplo, Wi-Fi) y ancho de banda costoso (por ejemplo, LTE). El uso de los enlaces de red costosos puede estar limitado al ancho de banda que es necesario para obtener la tasa caudal objetivo. Cuando los enlaces de red de bajo coste (y potencialmente ilimitados) proporcionan el ancho de banda necesario, no pueden usarse los enlaces de red costosos. Sin embargo, cuando los enlaces de red de bajo coste no tienen suficiente capacidad para conseguir el caudal objetivo, pueden basarse en los enlaces de red costosos según sea necesario.

Puede ser posible adicionalmente configurar el planificador para tratar siempre el primer enlace secundario como ilimitado ("primario"), en caso de que no haya otros enlaces primarios disponibles. Esto permite que un dispositivo use completamente la red ilimitada, use redes costosas hasta un grado limitado únicamente para ayudar a conseguir el caudal objetivo, mientras que no se limita el uso de la red costosa (como LTE) si es la única red disponible. El comportamiento del planificador puede configurarse y cambiarse dinámicamente.

Los escenarios anteriores tienen en común que están basados en tráfico que, sin imponer un límite de tasa de datos, hubieran podido saturar los enlaces de red disponibles. Un ejemplo para tal tráfico es uno descargado de un servidor rápido. Sin embargo, puede aplicarse también la planificación de desbordamiento a escenarios que requieren la transmisión de datos en segmentos, enviados a través de intervalos de tiempo específicos, tal como puede ser necesario para envío por flujo continuo de vídeo. En tales escenarios, la planificación de desbordamiento puede posibilitar el envío por flujo continuo de datos a una tasa deseada a través de múltiples enlaces de red, en su mayoría usando enlaces de red de bajo coste y basándose en enlaces de red más costosos únicamente cuando sea necesario.

La Figura 8A muestra transferencias de datos ilustrativas realizadas por un transmisor de vídeo que descarga segmentos de vídeo, de 20 MB cada uno, durante algunos intervalos de tiempo. Ambas redes presentadas, la red rápida (mitad superior del gráfico) y la red lenta (mitad inferior del gráfico) son suficientemente rápidas para soportar la tasa de vídeo seleccionada puesto que ambas pueden transferir un único segmento de 20 MB de datos dentro de los límites de tiempo de un intervalo solicitado. Sin embargo, la red más rápida envía el segmento entero en menos tiempo, y permanece en reposo por más tiempo (antes del comienzo del siguiente intervalo de tiempo), en comparación con la red más lenta. Debido a que la transmisión de segmentos de datos está temporizada, independientemente de cuánto caudal más esté disponible a través de la red, se transfiere un segmento de datos posterior en el comienzo del siguiente intervalo solicitado. En un escenario hipotético en el que la velocidad de la red coincide con la tasa de bits del flujo de vídeo, no habría tiempo en reposo entre los segmentos. Además, si la red era demasiado lenta, el transmisor de vídeo tendría que seleccionar un flujo con una tasa de bits inferior, y transferir, por ejemplo, únicamente 10 MB a través del mismo intervalo de tiempo.

La Figura 8B muestra transferencias de datos de ejemplo realizadas por un transmisor de vídeo a través de uno o dos enlaces de red. Han de transmitirse 20 MB en intervalos de tiempo de 5 segundos. El caudal objetivo de la conexión de dos enlaces puede ser configurable. Para caudales objetivo superiores, pueden requerirse ambos enlaces de red, mientras que para caudales objetivo inferiores, el uso de un único enlace de red puede ser suficiente. Los enlaces de red son un enlace de LTE de "alto coste" y un enlace de Wi-Fi de "bajo coste". Por consiguiente, el enlace de Wi-Fi se prefiere para las transmisiones de datos.

En el primer escenario, el caudal objetivo se establece a 10 MB/s o mayor, y se obtiene una tasa de transferencia de 10 MB/s, con ambos enlaces de red usados de manera máxima. Por lo tanto, el segmento de datos de vídeo de 20 MB se transmite a 5 MB/s a través de cada uno de los enlaces de red, y el tiempo de transferencia total es de 2 segundos. Se alcanzan 3 segundos de tiempo en reposo restante hasta el límite de tiempo de 5 segundos.

En el segundo escenario, el caudal objetivo se establece a 8 MB/s. La distribución de tráfico resultante es como sigue: Puesto que el enlace de red Wi-Fi proporciona una tasa de transferencia de 5 MB/s, el enlace de red LTE necesita proporcionar unos 3 MB/s adicionales únicamente. Por consiguiente, se transfieren 7,5 MB de datos a través del enlace de red LTE, mientras que se transfieren 12,5 MB de datos a través del enlace de red Wi-Fi. El tiempo total requerido para la transmisión es de 2,5 segundos.

Cuando se reduce adicionalmente el caudal objetivo, se envían más datos a través de Wi-Fi y menos a través de móvil. Por ejemplo, en un tercer escenario, se transfieren 3,5 MB de datos a través del enlace de red LTE, mientras que se transfieren 16,5 MB de datos a través del enlace de red Wi-Fi.

En el cuarto escenario en el que el caudal objetivo se establece a 5 MB/s, el enlace de red LTE no se usa en absoluto, y todos los datos se envían a través del enlace de red Wi-Fi. La duración de la transmisión es de 4 segundos.

En el quinto escenario, el caudal objetivo se establece a 4 MB/s. El enlace de red LTE no se usa en absoluto, y todos los datos se envían a través del enlace de red Wi-Fi. Puesto que el enlace de red Wi-Fi está configurado como un enlace de red primario, la duración de la transmisión es de 4 segundos. Reducir adicionalmente el caudal objetivo no tiene efecto. En contraste, suponiendo que el enlace de red Wi-Fi se configuró como un enlace de red secundario, establecer el caudal objetivo a 4 MB/s daría como resultado un segmento de datos de vídeo de 20 MB que se envía en 5 segundos en lugar de en 4 segundos.

Los escenarios anteriores tienen en común que un único enlace de red hubiera sido suficiente para transferir los datos de envío por flujo continuo dentro de las ventanas de tiempo disponibles. Sin embargo, cuando se requieren tasas de datos superiores, por ejemplo, 30 MB de datos cada 5 segundos, son necesarios ambos enlaces de red. El caudal objetivo tendría que haberse establecido a un mínimo de 6 MB/s, con 25 MB de datos enviados a través del enlace de red Wi-Fi, y 5 m B de datos a través del enlace de red LTE. Esta configuración permitiría la entrega de, por ejemplo, vídeo de calidad superior que a través del enlace de red Wi-Fi en solitario, mientras se usa únicamente el enlace de LTE potencialmente costoso según sea necesario.

En la práctica, debido a las condiciones de red variables, los caudales y los límites raramente son precisos. Por lo tanto, puede ser razonable establecer el caudal objetivo ligeramente superior que el teóricamente necesario para garantizar transmisión fiable, incluso en presencia de, por ejemplo, paquetes de datos ocasionalmente descartados.

La planificación de desbordamiento descrita puede conseguirse de diversas maneras. En una o más realizaciones de la invención, el planificador, previamente analizado con referencia a la Figura 2, monitoriza el caudal de datos real a través de los enlaces de red, reajusta límites de caudal en enlaces de red secundarios para minimizar su uso para satisfacer un requisito de caudal objetivo configurado sin usar excesivamente los enlaces de red secundaria. Si los enlaces primarios (ilimitados) son suficientemente rápidos, los enlaces secundarios pueden limitarse a caudal cero, es decir, no se transmiten paquetes de datos a través de estos enlaces secundarios.

En una realización de la invención, la monitorización de caudal y la limitación de tasa rastrean los datos reales que se envían y pueden realizar limitación de tasa tradicional. Como alternativa, puede estimarse el caudal de datos actual a través de los enlaces de red inspeccionando ventanas de control de congestión y latencias de enlace de red conocidas. Obsérvese que este enfoque estima el caudal permitido máximo actual a través del enlace de red, en lugar de la cantidad de datos real que se envía. Este caudal estimado puede ser particularmente útil para la operación de un mecanismo de desbordamiento. Como alternativa, puede medirse la cantidad de datos real que se envía a través de los enlaces de red.

Puede aplicarse un límite de caudal usando un mecanismo de control de tasa separado, o ajustando el límite del tamaño de la ventana de congestión según sea necesario.

Usando estos mecanismos de control de tasa, pueden limitarse los enlaces secundarios a una tasa de datos deseada, ya que pueden no estar limitados, o, como alternativa, puede usarse una combinación de enlaces de datos limitados y no limitados. La configuración de los mecanismos de control de tasa puede ajustarse dinámicamente según sea necesario o se desee.

La Figura 9 muestra un sistema informático de acuerdo con una o más realizaciones de la invención. Las realizaciones de la invención se pueden implementar en un sistema informático. Se puede usar cualquier combinación de hardware móvil, de escritorio, de servidor, integrado o de otros tipos. Por ejemplo, como se muestra en la Figura 9, el sistema informático (900) puede incluir uno o más procesadores informáticos (902), memoria asociada (904) (por ejemplo, memoria de acceso aleatorio (RAM), memoria caché, memoria flash, etc.), uno o más dispositivo de almacenamiento (906) (por ejemplo, un disco duro, una unidad óptica tal como una unidad de disco compacto (CD) o una unidad de disco versátil digital (DVD), una llave de memoria flash, etc.), y numerosos otros elementos y funcionalidades. El procesador o procesadores informáticos (902) pueden ser un circuito integrado para procesar instrucciones. Por ejemplo, el procesador o procesadores informáticos pueden ser de uno o más núcleos, o micronúcleos de un procesador. El sistema informático (900) también puede incluir uno o más dispositivos de entrada (910), tales como una pantalla táctil, un teclado, un ratón, un micrófono, una almohadilla táctil, un lápiz electrónico o cualquier otro tipo de dispositivo de entrada. Además, el sistema informático (900) puede incluir uno o más dispositivos de salida (908), tales como una pantalla (por ejemplo, un visualizador de cristal líquido (LCD), un visualizador de plasma, una pantalla táctil, un monitor de tubo de rayos catódicos (CRT), un proyector u otro un dispositivo de visualización), una impresora, un almacenamiento externo o cualquier otro dispositivo de salida. Uno o más del dispositivo o dispositivos de salida pueden ser iguales o diferentes que el dispositivo o dispositivos de entrada. El sistema informático (900) se puede conectar a una red (912) (por ejemplo, una red de área local (LAN), una red de área extensa (WAN) tal como Internet, una red móvil o cualquier otro tipo de red) a través de una conexión de interfaz de red (no mostrada). Los dispositivos de entrada y de salida se pueden conectar de forma local o remota (por ejemplo, a través de la red (912)) conectada al procesador o procesadores de ordenador (902), la memoria (904) y el dispositivo o dispositivos de almacenamiento (906). Existen muchos tipos diferentes de sistemas informáticos y el dispositivo o dispositivos de entrada y de salida mencionados anteriormente pueden adoptar otras formas.

Las instrucciones de software en forma de código de programa legible por ordenador para realizar las realizaciones de la invención se pueden almacenar, en su totalidad o en parte, de forma temporal o permanente, en un medio legible por ordenador no transitorio tal como un CD, un DVD, un dispositivo de almacenamiento, un disco flexible, una cinta, una memoria flash, una memoria física o cualquier otro medio de almacenamiento legible por ordenador. Específicamente, las instrucciones de software pueden corresponder a código de programa legible por ordenador que, cuando se ejecuta por un procesador, está configurado para realizar las realizaciones de la invención.

Además, uno o más elementos del sistema informático (900) mencionado anteriormente se puede ubicar en una ubicación remota y conectarse a otros elementos a través de una red (912). Además, las realizaciones de la invención pueden implementare en un sistema distribuido que tiene una pluralidad de nodos, donde cada porción de la invención puede ubicarse en un nodo diferente dentro del sistema distribuido. En una realización de la invención, el nodo corresponde a un dispositivo informático diferenciado. Como alternativa, el nodo puede corresponder a un procesador informático con memoria física asociada. El nodo puede corresponder, como alternativa, a un procesador informático o a un micronúcleo de un procesador informático con memoria y/o recursos compartidos.

Varias realizaciones de la invención tienen una o más de las siguientes ventajas. Las realizaciones de la invención posibilitan que uno o más emisores de flujo se comuniquen a través de uno o más enlaces de red. El uso de números de secuencia de flujo específicos de flujo y números de secuencia de enlace específicos de enlace proporciona diversas ventajas. Un paquete de datos, en cualquier momento, puede estar asociado de manera inequívoca con un flujo particular. Cuando se pierde un paquete de datos, el nodo de envío puede identificar, por lo tanto, a qué flujo pertenece un paquete perdido. Por consiguiente, puede retransmitirse únicamente el paquete de datos perdido, mientras que se evita la retransmisión innecesaria de otros paquetes de datos. Además, debido a la eliminación de ambigüedades con respecto a qué paquete de datos activó un acuse de recibo particular, puede medirse de manera precisa el tiempo de ida y vuelta.

Las realizaciones de la invención posibilitan adicionalmente el uso eficaz de la capacidad disponible de múltiples enlaces de red por múltiples flujos de datos, incluso si estos enlaces de red tienen diferentes capacidades, debido a la separación del control de ventana de recepción específico de flujo y el control de congestión específico de enlace. Si una retransmisión se vuelve necesaria, puede realizarse la retransmisión a través de cualquier enlace de red disponible. Los números de secuencia de flujo que son específicos de flujo se usan para posibilitar la restauración del orden original de paquetes de datos en el lado del nodo de recepción. Debido a que los flujos de datos se controlan usando ventanas de recepción específicas de flujo, los flujos de datos más lentos (por ejemplo, que resultan de receptores de flujo más lentos) no perjudican a otros flujos de datos.

Las realizaciones de la invención pueden usarse adicionalmente para implementar planificación de desbordamiento que puede posibilitar un uso rentable de capacidad de enlace de red disponible mientras se garantiza que está disponible la capacidad necesaria para adaptar uno o más flujos de datos.

Aunque la invención se ha descrito con respecto a un número limitado de realizaciones, los expertos en la materia, que cuenten con el beneficio de esta divulgación, apreciarán que se pueden contemplar otras realizaciones que no se aparten del alcance de la invención como se divulga en el presente documento. En consecuencia, el alcance de la invención debería estar limitado solo por las reivindicaciones adjuntas.

Claims (20)

REIVINDICACIONES

1. Un sistema de transmisión de datos, que comprende: un nodo de envío (110), que comprende:

una primera cola de enlace (214), configurada para almacenar paquetes de datos (224) para ser transmitidos a un nodo de recepción (130) en un primer enlace de red (120.1);

un primer control de congestión específico de enlace (150), asociado a la primera cola de enlace (214), estando el primer control de congestión específico de enlace (150) configurado para controlar una primera ventana de congestión (206),

en donde la primera ventana de congestión (206), controlada basándose en una capacidad disponible del primer enlace de red (120.1), determina un tamaño de la primera cola de enlace (214) para los paquetes de datos (224) para ser transmitidos;

una pluralidad de emisores de flujo (112), configurados para transmitir paquetes de datos (224) de una pluralidad de flujos de datos (114) a receptores de flujo (132) en el nodo de recepción (130),

una pluralidad de controles de ventana de recepción específicos de flujo (160), independientes del primer control de congestión específico de enlace (150),

en donde exactamente un control de ventana de recepción específico de flujo (160) está asociado a cada flujo de datos de la pluralidad de flujos de datos (114),

en donde cada control de ventana de recepción específico de flujo (160) está configurado para controlar una ventana de recepción (216) del emisor de flujo asociado, basándose en una capacidad disponible del correspondiente receptor de flujo para especificar una cantidad de datos disponible con el fin de que se introduzca en la primera cola de enlace (214);

una segunda cola de enlace (214), configurada para almacenar paquetes de datos (224), para ser transmitidos al nodo de recepción (130) en un segundo enlace de red (120.2); y

un segundo control de congestión específico de enlace (150), asociado a la segunda cola de enlace (214), estando el segundo control de congestión específico de enlace (150) configurado para controlar una segunda ventana de congestión (206),

en donde la segunda ventana de congestión (206), controlada basándose en una capacidad disponible del segundo enlace de red (120.2), determina un tamaño de la segunda cola de enlace (214) para los paquetes de datos (224) para ser transmitidos,

en donde los datos, puestos a disposición por uno de la pluralidad de emisores de flujo (112) se ponen a disposición, en uno seleccionado de un grupo que consiste en los enlaces de red primero y segundo (120), de los receptores de flujo (132) en el nodo de recepción (130),

en donde el segundo control de congestión específico de enlace (150) está configurado para hacer una primera determinación de que la segunda ventana de congestión (206) no permite el envío de los datos, en donde el primer control de congestión específico de enlace (150) está configurado para hacer una segunda determinación de que la primera ventana de congestión (206) permite el envío de los datos, y en donde el primer enlace de red (120.1) está configurado para permitir el envío de al menos un paquete de datos que comprende los datos basándose en la segunda determinación.

2. El sistema de transmisión de datos de la reivindicación 1, en el que para que los datos se pongan a disposición por uno de la pluralidad de emisores de flujo (112), se selecciona el segundo enlace de red (120.2) para la transmisión de al menos un paquete de datos, que comprende los datos basándose en la capacidad disponible del segundo enlace de red (120.2).

3. El sistema de transmisión de datos de la reivindicación 1, en el que el primer enlace de red (120.1) y el segundo enlace de red (120.1) tienen diferentes capacidades de transmisión de datos.

4. El sistema de transmisión de datos de la reivindicación 1, en el que se selecciona el primer enlace de red (120.1) y el segundo enlace de red (120.2) de un grupo que consiste en una red de área local inalámbrica y en una red celular.

5. El sistema de transmisión de datos de la reivindicación 1, configurado para realizar planificación de desbordamiento,

en el que el primer enlace de red (120.1) está configurado para dar servicio como un enlace de red primario para transmisiones de datos, y

en el que el segundo enlace de red (120.2) está configurado para dar servicio como un enlace de red secundario para las transmisiones de datos, para una parte de las transmisiones de datos que supera la capacidad disponible del primer enlace de red.

6. El sistema de transmisión de datos de la reivindicación 5, en el que se usan las ventantas primera y segunda de congestión (206) para distribuir las transmisiones de datos de los enlaces de red primero y segundo (120).

7. El sistema de transmisión de datos de la reivindicación 1, que comprende adicionalmente una cola de retransmisión, configurada para almacenar paquetes de datos (224) que requieren retransmisión al nodo de recepción (130), en donde un paquete de datos en la cola de retransmisión tiene prioridad sobre paquetes de datos (224) en la primera cola de enlace (214).

8. El sistema de transmisión de datos de la reivindicación 7, en el que la cola de retransmisión no es específica de flujo y no es específica de enlace.

9. El sistema de transmisión de datos de la reivindicación 1, que comprende adicionalmente el nodo de recepción (130), en el que el nodo de recepción (130) está configurado para operar como un servidor de agregación entre el nodo de envío (130) y una red (100).

10. El sistema de transmisión de datos de la reivindicación 9, en el que el nodo de envío (110) está configurado para operar como un cliente de agregación, alojado en un encaminador para dar servicio a una pluralidad de dispositivos que se conectan al encaminador.

11. Un método para transmitir datos por un nodo de envío (110), comprendiendo el método:

establecer un primer control de congestión específico de enlace (150), asociado a una primera cola de enlace (214), que comprende:

controlar un tamaño de la primera cola de enlace (214), asociada a un primer enlace de red entre el nodo de envío (110) y un nodo de recepción (130), estableciendo una primera ventana de congestión (206), basándose en una capacidad disponible del primer enlace de red,

en donde la primera cola de enlace (214) está configurada para almacenar paquetes de datos para ser transmitidos desde el nodo de envío (110) al nodo de recepción (130); y

establecer una pluralidad de controles de ventana de recepción específicos de flujo (160), que son independientes del control de congestión específico de enlace (150), que comprende:

para cada uno de la pluralidad de controles de ventana de recepción específicos de flujo (160), controlar una ventana de recepción (216) de un emisor de flujo asociado del nodo de envío (110), basándose en una capacidad disponible de un correspondiente receptor de flujo del nodo de recepción (130),

en donde la ventana de recepción específica de flujo (216) especifica una cantidad de datos disponible para que se introduzca en la primera cola de enlace (214) para su transmisión al nodo de recepción (130);

establecer un segundo control de congestión específico de enlace (150), asociado a una segunda cola de enlace (214), en donde establecer un segundo control de congestión específico de enlace (150) comprende: controlar un tamaño de la segunda cola de enlace (214) asociada a un segundo enlace de red entre el nodo de envío (110) y el nodo de recepción (130), estableciendo una segunda ventana de congestión (206) basándose en una capacidad disponible del segundo enlace de red,

en donde la segunda cola de enlace (214) está configurada para almacenar los paquetes de datos (224) para ser transmitidos desde el nodo de envío (110) al nodo de recepción (130), y

en donde los datos que se ponen a disposición por uno de la pluralidad de emisores de flujo (112) se ponen a disposición de uno seleccionado de un grupo que consiste en el primer y en el segundo enlace de red; hacer una primera determinación de que la segunda ventana de congestión (206) no permite el envío de los datos;

hacer una segunda determinación de que la primera ventana de congestión (206) permite el envío de los datos; y

enviar al menos un paquete de datos, que comprende los datos a través del primer enlace de red, basándose en la segunda determinación.

12. El método de la reivindicación 11, en el que los datos se ponen a disposición por el emisor de flujo basándose en los datos que están dentro del intervalo de la ventana de recepción (216) del emisor de flujo.

13. El método de la reivindicación 11, que comprende adicionalmente:

introducir al menos un paquete de datos que comprende los datos disponibles en la segunda cola de enlace (214), basándose en una determinación de que la segunda ventana de congestión (206) permite el envío del al menos un paquete de datos; y

enviar el al menos un paquete de datos en la segunda cola de enlace (214) a través del segundo enlace de red.

14. El método de la reivindicación 13, que comprende adicionalmente, antes de introducir los datos disponibles en la segunda cola de enlace (214):

hacer una determinación de que existe un paquete de datos en una cola de retransmisión del nodo de envío (110); y

enviar el paquete de datos en la cola de retransmisión a través del segundo enlace de red.

15. El método de la reivindicación 11, que comprende adicionalmente, después de hacer la primera determinación y antes de hacer la segunda determinación:

hacer una tercera determinación de que existe un paquete de datos en una cola de retransmisión del nodo de envío (110); y

enviar el paquete de datos en la cola de retransmisión a través del primer enlace de red.

16. El método de la reivindicación 11, que comprende adicionalmente implementar planificación de desbordamiento, con el primer enlace de red (120.1), que está configurado como un enlace de red primario para transmisiones de datos, y el segundo enlace de red (120.2), que está configurado como un enlace de red secundario para una parte de las transmisiones de datos que supera la capacidad disponible del primer enlace de red (120.1), en donde la segunda ventana de congestión se establece a cero, evitando de esta manera las transmisiones de datos a través del segundo enlace de red (120.2), a menos que se use toda la capacidad disponible del primer enlace de red (120.1).

17. El método de la reivindicación 11, que comprende adicionalmente:

recibir un acuse de recibo de enlace de red para un paquete de datos recibido del nodo de recepción (130); y retirar el paquete de datos habiendo realizado acuse de recibo de la primera cola de enlace (214).

18. El método de la reivindicación 11, en el que se determina la capacidad disponible del correspondiente receptor de flujo basándose en una memoria intermedia de receptor de flujo disponible (234) del receptor de flujo.

19. El método de la reivindicación 17, que comprende adicionalmente ajustar la primera ventana de congestión (206) usando un algoritmo de control de congestión.

20. El método de la reivindicación 11, que comprende adicionalmente:

hacer una determinación de que se perdió un paquete del que no se ha realizado acuse de recibo, y basándose en la determinación, mover el paquete del que no se ha realizado acuse de recibo de la primera cola de enlace (214) a una cola de retransmisión.