ES2684433T3 - Método para retransmisión de paquetes - Google Patents

Abstract

Un método para la retransmisión de paquetes entre un primer terminal y un segundo terminal en una red TCP que tiene una pluralidad de enlaces inalámbricos, soportando cada uno de dichos terminales la retransmisión TCP usando una ventana de tamaño variable, comprendiendo dicho método: establecer, en el primer terminal, un valor de incremento del tamaño de la ventana para incrementar un tamaño de ventana de dicha ventana de tamaño variable; transmitir, por el primer terminal, uno o más paquetes al segundo terminal sobre uno de la pluralidad de enlaces inalámbricos; aumentar dicho tamaño de ventana mediante dicho valor de incremento de tamaño de ventana en respuesta a la recepción de una o más confirmaciones que indican la recepción con éxito de uno o más de los paquetes transmitidos; caracterizado por cambiar dicho valor de incremento del tamaño de la ventana en respuesta a una o más de notificaciones de congestión y dichas una o más confirmaciones recibidas, en donde dicha etapa de cambio comprende aumentar dicho valor de incremento del tamaño de la ventana multiplicando dicho valor de incremento del tamaño de la ventana por un factor de multiplicación en respuesta a dichas una o más confirmaciones recibidas.

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

DESCRIPCION

Método para retransmisión de paquetes Campo de la invención

La invención se refiere en general a comunicaciones de red sobre enlaces inalámbricos que están sujetos a congestión y a la degradación que la acompaña y los protocolos que pueden usarse para el transporte eficaz y fiable de los paquetes. Más específicamente, la invención se refiere a la mejora de comunicaciones fiables entre terminales móviles que proporcionan “comunicaciones en movimiento” (COTM) y satélites geoestacionarios de tipo pasivo (transparentes) e inteligente (procesamiento integrado).

Antecedentes de la invención

Se ha desarrollado un número de protocolos para proporcionar comunicaciones fiables de paquetes entre dos entidades de usuario, especialmente cuando hay un enlace de comunicación no fiable. El Protocolo de Secuencia de Tiempos (TSP) es un protocolo de transporte de datos de alto rendimiento que es adecuado para usar como protocolo de la capa de enlace para comunicaciones de paquetes. El TSP es particularmente adecuado para su uso sobre un enlace entre dos usuarios finales en un entorno de comunicación de punto a punto en el que el enlace está sujeto a una degradación severa debido a interferencias. Dicha interferencia puede estar causada por condiciones ambientales, tales como el clima, o impedimentos físicos, tales como edificios, puentes o similares, que impiden un enlace claro entre un terminal COTM y otro terminal, ya sea de un satélite, otro terminal COTM o terminal fijo. Por ejemplo, en el sistema 100 de comunicaciones ilustrado en la Fig. 1, un satélite 101 en órbita geoestacionaria puede estar en comunicación con una pluralidad de terminales COTM, COTM1-COTM4 así como terminales FS1, FS2 de emplazamiento fijo, estando estos últimos conectados a Internet 102. Los terminales FS1 y FS2 de emplazamiento fijo se muestran con grandes antenas parabólicas porque esta es la práctica típica, aunque el experto en la técnica deberá entender que los emplazamientos fijos pueden emplear pequeñas antenas si el presupuesto del enlace lo permite. Los terminales móviles generalmente requieren antenas dirigibles para compensar el movimiento de la plataforma. Sin embargo, unos edificios B1 y B2 pueden actuar como bloqueo de uno o más de los enlaces entre el satélite 101 y los terminales COTM y crear una interrupción, como se representa mediante las líneas discontinuas. El TSP usa estrategias de retransmisión para lograr un comportamiento deseado en rendimiento y retardo donde se pierden paquetes debido a interferencias con un enlace punto a punto establecido. Sin embargo, el TSP no es aplicable a las comunicaciones de red en las que los enlaces se abren y cierran de manera controlada, ni se ocupa de la congestión en los enlaces dado que cada enlace se establece punto a punto. Además, incluso aunque las aplicaciones del punto final se comuniquen indirectamente, punto a punto, a través de la capa de enlace, el TSP no permite una comunicación directa de aplicación a aplicación.

El protocolo de control de transmisión (TCP) es un estándar bien conocido para aplicaciones de Internet y está representado por normas publicadas.

El protocolo TCP se combina con el protocolo de Internet (IP) para establecer una base general para las comunicaciones en red (TCP/IP). En un sistema basado en TCP, los usuarios finales entran y salen de la red, por ejemplo mediante la adscripción a Internet en una estación de trabajo, y los enlaces que proporcionan la comunicación entre usuarios finales pueden abrirse y cerrarse frecuentemente según se conmutan los paquetes transmitidos. Aunque dicha flexibilidad proporciona ventajas, también crea un problema con la congestión en los enlaces a medida que aumenta la demanda de capacidad.

Un ejemplo de una red basada en TCP se ilustra en Fig. 2 en la que un sistema 200 incluye un satélite 201 que se comunica de forma inalámbrica con terminales 210, 220 terrestres de satélite mediante los enlaces 202, 203 de manera que las estaciones de trabajo o servidores 230, 240 de usuario final puedan comunicarse entre sí. Los terminales 210, 220 de satélite, que pueden actuar como enrutadores IP como sabrán los expertos en la técnica, se conectan al satélite 201 mediante enlaces 202, 203 a través de una capa física 211, 221 del satélite, que a su vez conecta pares de capas IP 212, 213 y 222, 223 a una capa Ethernet respectiva 214, 224 para la comunicación a través de una red de área local. La capa Ethernet 214 puede acoplarse directamente mediante el enlace 216 a una capa similar 231 en el servidor 230 de estación de trabajo o a una capa similar 241 mediante enlaces 251, 252 a través de Internet 250. Cada estación de trabajo o servidor tiene capas IP 232, 242 apropiadas, capas TCP 233, 243 y aplicaciones 234, 244. Las aplicaciones pueden hablar directamente entre sí a través de la capa de transporte, proporcionando así una ventaja significativa sobre el sistema basado en TSP, que solo utiliza la capa de enlace para las comunicaciones. En el sistema ilustrado, el control de flujo TCP y el intercambio de mensajes de confirmación se proporcionan de extremo a extremo.

Dado que los enlaces de red se extienden necesariamente en el dominio inalámbrico, deben considerarse adecuadamente los problemas específicos creados cuando el protocolo TCP se aplica a una red inalámbrica. La aplicación de un protocolo de control de transmisión estándar directamente sobre un enlace de retardo largo, tal como los encontrados en un enlace de tierra a satélite por ejemplo, produce un rendimiento deficiente debido a muchos factores relacionados con interferencias o similares. Si un enlace de comunicación está también sujeto a degradaciones de funcionamiento, tales como interrupciones de servicios, entonces se reduce aún más el rendimiento del protocolo de red. Por ejemplo, en un sistema de comunicación de protocolo TCP que soporte terminales de COTM en vehículos móviles, ocurrirán

5

10

15

20

25

30

35

40

45

50

55

60

65

interrupciones o bloqueos cuando los vehículos pasen por debajo de puentes u otras obstrucciones. Por lo tanto, en aplicaciones de TCP en COTM, las pérdidas de paquetes tienden a ser elevadas, del orden de 15 % - 55 % dependiendo de si el entorno es abierto, rural o urbano, y conducirá a retransmisiones, causando de este modo que el protocolo basado en TCP reduzca su velocidad de transferencia. De hecho, en las aplicaciones basadas en TCP/IP, tales como acceso a la web, correo electrónico y ftp, así como otras aplicaciones relacionadas con la voz y el vídeo, no se comportan bien en canales de comunicación que enlazan terminales COTM con terminales fijos, ya sean terrestres o geoestacionarios.

Según el protocolo TCP convencional, cuando se pierden paquetes, se requieren retransmisiones de acuerdo con ciertas reglas y hacen que el TCP reduzca su velocidad de transferencia. Además, el TCP utiliza un esquema de administración de ventana para impedir la congestión en la red y gestionar el rendimiento. El rendimiento se define como el tamaño de ventana “W” dividido por el tiempo de ida y vuelta (“RTT”). Por lo tanto, en el arranque, se fija un tamaño de ventana inicial “W” para que sea pequeño, igual a uno o dos paquetes, y para un determinado RTT el rendimiento será pequeño. El tamaño de ventana W se aumenta exponencialmente (p. ej., un 50 %) con cada tiempo de ida y vuelta dado que aumenta la confianza en la capacidad del enlace, y el rendimiento aumenta correspondientemente. Sin embargo, si se pierde un paquete, W se reduce exponencialmente (p. ej., en un 50 %) y después se aumenta linealmente (p. ej., en 0,5 paquetes) cada tiempo de ida y vuelta, de manera que el rendimiento se reduce y después se aumenta lentamente. Después de múltiples pérdidas de paquetes, W se puede reducir a un mínimo de 1 paquete y luego aumentar exponencialmente cada tiempo de ida y vuelta hasta que la ventana sea igual a un porcentaje de la ventana original, y luego se incrementa en forma lineal cada tiempo de ida y vuelta. Para un canal COTM con pérdidas periódicas cada 1-4 segundos, el rendimiento instantáneo es bajo dado que W se ajusta a 1. En la Figura 3 se ilustra un ejemplo del rendimiento de TCP convencional sobre un enlace por satélite. El tiempo fluye hacia abajo por la página, y el terminal de origen se designa por Tx (a la izquierda) y el terminal de recepción está a la derecha (Rx). Aquí una ventana de 8 kbytes y un RTT de 500 ms producen un rendimiento de 128 kbps, dado el hecho de que los ocho paquetes de 1 kbytes de datos requieren una confirmación (ACK). El rendimiento se limita de manera importante, aunque se usa un canal de 2 Mbps.

En la industria, las interrupciones de las señales se compensan con frecuencia mediante el uso de técnicas ARQ (solicitud de Retransmisión Automática). El ARQ-S de la capa de enlace proporciona la retransmisión de los paquetes perdidos entre el terminal COTM y la carga útil, p. ej., una carga útil de satélite de TCM. En tal caso, la carga útil debe mantener una sesión de ARQ separada con cada terminal COTM y el terminal COTM debe mantener una sesión ARQ con la carga útil. El ARQ-T de la capa de enlace requiere retransmisión de paquetes perdidos entre el terminal COTM y un terminal COTM fijo u otros. En aRQ-T, el ARQ debe estar incluido en la capa IP terminal, de manera que la carga útil pueda enrutar paquetes ARQ. El terminal fijo debe mantener una sesión ARQ separada con cada terminal COTM de destino y cada terminal COTM debe mantener una sesión de ARQ separada para cada uno de sus terminales de destino.

A pesar de las ventajas potenciales de las técnicas ARQ, ARQ interactúa deficientemente con los protocolos TCP de extremo a extremo, e incluso con proxis. El ARQ provoca que los paquetes se retrasen y hace que el TCP espere, reduzca los tamaños de ventana e invoque sus propias retransmisiones. Esta interacción desfavorable se agrava cuando se emplea a través de enlaces de retardo largo, debido al tiempo de retardo necesario para cada retransmisión. Más aún, el ARQ no fijará las limitaciones TCP de extremo a extremo tales como ventanas TCP pequeñas, ventanas iniciales pequeñas, incrementos lentos de las ventanas, y carencia de apoyo para ECN (Notificación de Congestión Explícita), que es un estándar TCP/IP que usa dos bits en el encabezado IP.

El estándar TCP-ECN, especialmente como se detalla en RFC3168 (ver Ramakrishnan y col., The Addition of ECN to IP, septiembre de 2001), especifica el uso de dos bits en el encabezado IP de paquetes de datos para la señalización entre enrutadores y los puntos finales de conexión con respecto a la existencia de congestión. La congestión en una red TCP provoca la pérdida de paquetes. Con el fin de identificar la congestión como una causa de la pérdida de paquetes, un terminal TCP remitente puede establecer un bit con capacidad ECN en el encabezado IP de paquetes de datos, y los enrutadores intermedios pueden establecer el bit ECN en el encabezado IP cuando experimenten congestión mientras envían un paquete transmitido. Si se establece el bit ECN, el terminal TCP receptor extrae el bit ECN y lo envía al terminal TCP remitente en el encabezamiento TCP de un paquete de ACK posterior. El terminal TCP remitente utiliza esa información para ralentizar la velocidad de transmisión.

El número de paquetes de datos sin confirmación que se permiten permanecer en cualquier momento dado, antes de establecer una condición de congestión o fallo, se especifica por un valor CWND. El valor CWND sirve como una ventana de congestión y se disminuye bajo ciertas condiciones, tales como la recepción de un bit ECN. Según el estándar TCP, el uso de ECN siempre se combina con protocolos de retransmisión que se acoplan para superar bloqueos e interferencias. Sin embargo, la incompatibilidad de ECN con ARQ plantea la necesidad de una solución al problema de la congestión e interferencia combinadas.

La corrección de error de envío también se puede emplear para simplemente 'codificar' cualquier longitud de interrupción con la selección apropiada de código, longitud de código y técnica de intercalado. Esta técnica no es aceptable debido al retraso inherente y a la reducción en la velocidad del tráfico requeridos para compensar las pérdidas debidas a largos períodos de degradación. Por ejemplo, en un sistema sometido a degradaciones de una duración variable, el diseñador del sistema necesitaría seleccionar una técnica de codificación suficientemente robusta como para compensar el período de degradación más largo. Esta codificación, sin embargo, dará como resultado un retraso innecesario y/o una velocidad reducida de datos durante los tiempos en los que solo se producen cortos períodos de degradación.

5

10

15

20

25

30

35

40

45

50

55

60

65

Una solución a los problemas anteriores se encuentra en una técnica basada en TCP que tiene un proxy de mejora del rendimiento (PEP) que sirve para aumentar el rendimiento de los protocolos de red sobre enlaces de comunicación degradados. Ese TCP-PEP usa un protocolo de retransmisión efectivo que está integrado en un proxy de mejora del rendimiento para compensar los enlaces de comunicación degradados. La técnica de retransmisión TCP-PEP se modifica y complementa con características adicionales relacionadas con el control de congestión, tamaño de ventana, negociación de la conexión y establecimiento acelerado.

US-6697331 B1 describe un esquema de confirmación de la capa de enlace para comunicaciones celulares.

Sumario de la invención

La invención se define en la reivindicación 1.

La invención se refiere a la integración de un protocolo de retransmisión mejorado en un proxy de mejora del rendimiento (PEP) para los enlaces de comunicación degradados. Diversas realizaciones de la invención incluyen control de la congestión, algoritmos de tamaño de ventana, negociación de conexión y aceleración del establecimiento de la conexión.

Especialmente, la invención se refiere a un método para implementar un protocolo de retransmisión en una red TCP que tiene una pluralidad de enlaces inalámbricos, que incluye al menos un enlace entre un primer terminal y un segundo terminal, en el que cada uno de dichos terminales soporta un primer protocolo de retransmisión TCP y al menos uno de dichos primer y segundo terminales también soporta un segundo protocolo de retransmisión TCP que es diferente del primer protocolo de retransmisión. El método comprende, en cada estación, realizar una primera determinación de si el primer protocolo está soportado, y en cada estación que soporte el primer protocolo, realizar una segunda determinación de si dicho segundo protocolo ha de utilizarse. Luego, en cada estación, se inserta al menos información con respecto a la primera determinación en un paquete de configuración de llamada. En cada uno del primer y segundo terminales, el paquete de configuración de llamada se transmite al otro de dichos primer y segundo terminales y, en la otra primera y segunda estación, se realiza una tercera determinación de si el segundo protocolo de retransmisión TCP está soportado tanto por el primer como por el segundo terminal. Finalmente, en respuesta a la tercera determinación, se implementa uno de entre el primer y el segundo protocolos TCP.

La invención también incluye un método para implementar un protocolo de retransmisión en una red TCP que tiene una pluralidad de enlaces inalámbricos que incluyen al menos un enlace entre un primer terminal y un segundo terminal, en el que cada terminal soporta un protocolo de retransmisión TCP que tiene una ventana de tamaño variable. El tamaño de la ventana se varía según un protocolo de variación de tamaño. El método comprende establecer un valor de incremento del tamaño de la ventana y cambiar el valor de incremento basándose en la congestión detectada y en indicios de transmisión y recepción satisfactorias de los paquetes.

Según otras características adicionales de la invención, el método comprende aumentar o disminuir uno o ambos de entre el tamaño de ventana y el valor de incremento basándose en el histórico de transmisión.

Según aún otra característica de la invención, el método comprende el uso de un conteo de reordenación que permite que un número especificado de paquetes desordenados continúe antes de que se lleve a cabo una acción correctiva, que incluye la retransmisión y ajuste del tamaño de ventana y el valor de incremento.

Breve descripción de los dibujos

La presente invención se ilustra a modo de ejemplo, especialmente el mejor modo de realización preferida, y no de forma excluyente. Otros objetos, características y ventajas de la presente invención serán más evidentes a partir de la siguiente descripción detallada de una realización preferida y el mejor modo de implementar la invención, como se muestra en las figuras de los dibujos adjuntos, en los que números de referencia similares se refieren a elementos similares, y en los que:

La Figura 1 es una ilustración de un sistema de comunicaciones inalámbrico al que es aplicable la invención.

La Figura 2 es una ilustración de un sistema convencional de comunicación TCP/IP por satélite.

La Figura 3 es una ilustración de flujos de señal involucrados en la transmisión y confirmación de paquetes para un enlace de comunicaciones inalámbrico por satélite.

La Figura 4 es una ilustración de una red de comunicación TCP/IP por satélite ilustrativa, que tiene múltiples terminales satélite que están en comunicación con un satélite a través de enlaces inalámbricos y se adaptan para usar técnicas de proxy de mejora del rendimiento.

La Figura 5 es una ilustración del flujo de señales entre transmisores y receptores en estaciones de trabajo y terminales de satélite en un sistema de comunicación TCP/IP por satélite utilizando técnicas de proxy de mejora del rendimiento.

5

10

15

20

25

30

35

40

45

50

55

60

65

La Figura 6 es un diagrama de secuencias de tiempo que ilustra el flujo de señales en una red TCP convencional utilizando una técnica de retransmisión convencional para paquetes perdidos.

La Figura 7 es un diagrama de secuencias de tiempo que ilustra el flujo de señales en una red TCP mejorada utilizando una técnica de retransmisión mejorada para paquetes perdidos según la presente invención.

La Figura 8 ilustra un diagrama de flujo para un proceso que ajusta el tamaño de ventana CWND utilizando la estrategia de TCP mejorada.

La Figura 9 es un gráfico que ilustra el aumento del CWND según la presente invención.

La Figura 10A es una ilustración de un paquete TCP SYN utilizado durante la configuración de la conexión y la Figura 10B es una ilustración de un diagrama de flujo para determinar si se utilizará el protocolo TCP mejorado o convencional.

La Figura 11 es una ilustración de otra red de comunicación TCP/IP por satélite ilustrativa, que tiene múltiples terminales satélite que están en comunicación con un satélite que tiene un equipo proxy de mejora del rendimiento integrado.

La Figura 12 es una ilustración de aún otra red de comunicación TCP/IP por satélite ilustrativa, que tiene múltiples terminales satélite que están en comunicación con un satélite a través de enlaces inalámbricos y al menos uno está acoplado a un huésped que tiene un equipo proxy de mejora del rendimiento.

La Figura 13 ilustra un huésped TCP-PEP con características mejoradas según la presente invención.

Descripción de realizaciones ilustrativas de la invención

En la siguiente descripción, para facilitar la explicación, se exponen numerosos detalles específicos con el fin de proporcionar una comprensión exhaustiva de los aspectos más amplios de la presente invención, así como para apreciar las ventajas de los detalles específicos propios según los aspectos más concretos de la presente invención. Es evidente, sin embargo, para el experto en la técnica, que los aspectos más amplios de la presente invención pueden ponerse en práctica sin estos detalles específicos o con equivalentes explícitamente determinados en la presente memoria o de acuerdo con las guías expuestas en la presente memoria. Las estructuras y dispositivos bien conocidos se muestran en forma de diagrama de bloques para evitar oscurecer innecesariamente la presente invención con detalles innecesarios.

La presente invención también tiene la capacidad de adoptar otras y diferentes realizaciones, y sus diversos detalles pueden modificarse en varios aspectos, todo ello sin abandonar el ámbito de la presente invención. El dibujo y la descripción son ilustrativos y no restrictivos. En la siguiente descripción de las realizaciones ilustrativas, se pueden utilizar los mismos números o caracteres de referencia en diferentes figuras donde las estructuras o características son iguales y una descripción común de dichas estructuras o características sería aplicable a todas. Sin embargo, el uso de diferentes números para una estructura o característica similar en una figura no significa necesariamente que sea diferente de una estructura o característica similar en otra figura.

La presente invención es apropiada para una amplia gama de protocolos de red y canales degradados, pero con el propósito de proporcionar una realización ilustrativa y actualmente aplicable, se describirá con respecto al protocolo de control de transmisión de Internet (TCP). La realización ilustrativa supone la existencia de un sistema del tipo ilustrado en la Figura 1 en el que hay uno o más enlaces de comunicación inalámbrica degradados que dependen de un enlace por satélite a través de un satélite geoestacionario. La degradación de señal ilustrativa serán interrupciones debidas al uso de terminales de comunicación en movimiento (COTM), pero no es necesario que se limite a tales interrupciones, ya que pueden ser el resultado de condiciones meteorológicas e interferencias de RF u otras. Las características de la interrupción en los distintos tipos de entornos (abiertos y urbanos) se describen en “EHF Satellite Communications-on-the-Move Blockage Channel Modeling” H. a Yao, MIT Lincoln Laboratory Technical Report 1098, 2 de noviembre de 2004. Aunque se representa un único satélite para mayor claridad, también se contempla la aplicación de la invención a un sistema con múltiples satélites y enlaces entre satélites. Los satélites pueden ser simples repetidores (transparentes) o satélites de procesamiento más complejo.

La Figura 4 ilustra una red IP 400 inalámbrica ilustrativa, que proporciona comunicación a través de satélite 401 entre terminales 410, 420, 430 de satélite mediante enlaces 402, 403, 404, respectivamente. Cada terminal 410, 420, 430 de satélite está acoplado a una estación de trabajo o servidor 440, 450, 460 de usuario representativa, respectivamente, para permitir que las estaciones de trabajo y los servidores en una red se comuniquen entre sí directamente o a través de Internet 470. Una red tal como se ilustra puede soportar múltiples combinaciones terminal de satélite/terminal de usuario, como se indica mediante la ilustración de la combinación del terminal 430 de satélite y la estación de trabajo/servidor 460 de usuario con una línea punteada. Al igual que con los terminales ilustrados en la Figura 2, las aplicaciones de usuario se comunican bidireccionalmente a través de las aplicaciones de red a servidor a través de conexiones de red en capas. Los terminales de satélite usan la capa IP para la interfaz de la capa física del satélite con la capa física Ethernet. Específicamente, los terminales 410, 420, 430 de satélite tienen capas físicas 411, 421, 431 del satélite que se acoplan a un enlace 402-404 respectivo, capas IP 412, 422, 432 que se acoplan a las capas físicas del satélite, y capas IP 413, 423, 433 que se acoplan a las capas Ethernet 416, 426,

5

10

15

20

25

30

35

40

45

50

55

60

65

436. Las estaciones de trabajo 440, 450, 460 tienen de forma similar capas Ethernet 231, 241, 251, capas IP 232, 242, 252, capas TCP 233, 243, 253 y capas 234, 244, 254 de aplicación. Dentro del terminal de satélite, sin embargo, entre las capas IP, se enlaza una capa 425A, 435A, 445A TCP de satélite y una capa 425B, 435B, 445B TCP terrestre mediante una capa 425C, 435C, 445C del proxy de mejora del rendimiento (PEP) TCP.

La característica TCP-PEP puede instalarse en un centro para satélites, integrarse en el terminal tal como se muestra, o implementarse por separado entre el terminal de satélite e Internet y conectarse a un enrutador. La característica TCP-PEP reemplaza el ARQ-T o ARQ-S convencionales y retransmite los paquetes perdidos entre los terminales, especialmente donde uno o ambos terminales son terminales COTM. La característica TCP-PEP utiliza una ventana ampliada sobre la red satelital y utiliza TCP con extensiones RFC1323 como el protocolo sobre el enlace satelital. La TCP-PEP también proporciona acuses de recibo TCP locales a la estación de trabajo o PC huésped y utiliza un protocolo TCP optimizado sobre la red de satélite. La característica TCP-PEP se usa entre cada par de terminales, COTM o fijos, y se establece dinámicamente una sesión de TCP-PEP para cada usuario.

En una operación TCP-PEP como se aplica a una red de satélite como se ilustra en la Figura 4, la conexión de extremo a extremo TCP se rompe en 3 conexiones de la capa de transporte concatenadas. Se acusa el recibo de los datos desde la instancia TCP de usuario por la instancia TCP en el terminal de satélite local. Los datos se transportan a través de la red de satélite utilizando una conexión de la capa de transporte tipo TCP separada, que utiliza típicamente una ventana que se dimensiona para el producto de retardo-ancho de banda del satélite.

El resultado de una implementación de TCP-PEP en un sistema de satélite de la Figura 4 puede entenderse a partir de la ilustración de la Figura 5, donde a diferencia del sistema estándar de la Figura 2, se logra un rendimiento de 2 Mbps TCP usando TCP-PEP, aun cuando las implementaciones TCP del usuario usen ventanas de 8 kbytes. Como en la Figura 2, las transmisiones de datos son en paquetes de 1 kbytes, transmitiéndose aproximadamente ocho paquetes en un tiempo de ida y vuelta. La columna A en la Figura 5 representa la comunicación entre la estación de trabajo y el terminal de satélite, posiblemente a través de Internet, y utiliza una ventana de 8 kbytes con un tiempo de ida y vuelta del ACK de 32 ms, proporcionando un rendimiento de 2 Mbps. La columna B en la Figura 5 representa la comunicación entre los terminales de satélite, y utiliza una ventana de 128 kbytes con un tiempo de ida y vuelta del ACK de 500 ms, como es típico para comunicaciones de satélite geoestacionario. El rendimiento es también de 2 Mbps. La columna C en la Figura 5 representa la comunicación entre el terminal de satélite y la estación de trabajo y, como en la columna A, tiene un rendimiento de 2 Mbps. De hecho, con la inserción de las funciones de TCP-PEP en el terminal de satélite, sin necesidad de cualquier cambio en el equipo o software de usuario final, el rendimiento puede ser tan elevado como la velocidad del enlace de satélite, p. ej., de hasta 100 Mbps.

La Figura 6 es un diagrama de secuencias de tiempos que ilustra la operación del TCP-PEP en un canal que experimenta una interrupción que causa la pérdida de cuatro paquetes de 1 kbyte. El tiempo fluye hacia abajo por la página, y el terminal de origen se designa por Tx (a la izquierda) y el terminal de recepción está a la derecha (Rx). El terminal de transmisión comienza la transferencia mediante el envío de paquetes de datos con números de secuencia de transmisión (txseq) 0-9. El tiempo de retardo para estos paquetes a través del enlace por satélite se ilustra por las líneas inclinadas hacia abajo, y las líneas interrumpidas para txseq=1 - txseq=4 indican que estos paquetes se pierden en la ruta hacia el terminal Rx. Debe mencionarse que el Tx continúa enviando paquetes txseq=5 hasta txseq=9, lo que implica que un valor CWND de la ventana de congestión en este punto inicial es superior que o igual a 9. Los paquetes con txseq=5 a txseq=9 tienen todos éxito (en este ejemplo ilustrativo, el deterioro del canal ha desaparecido por esta vez).

Una vez que Rx recibe txseq=0, responde con una confirmación ACK rxseq=1, lo que indica que el siguiente paquete está listo para recibir su txseq=1. La línea para este ACK de respuesta para el paquete txseq=0 alcanza el Tx, lo que indica que se ha recibido txseq=0. Sin embargo, ya que ninguno de los paquetes txseq=1 a txseq=4 genera paquetes de ACK en el Rx, basados en el protocolo TCP estándar, después de que se transmita el paquete con txseq=9, el Tx experimenta un tiempo de espera del TCP. Toma nota de la última rxseq que se recibe (rxseq=1) y por lo tanto retransmite el paquete txseq=1. El valor CWND de la ventana TCP de congestión se reduce ahora a 1 paquete, de tal manera que el Tx debe esperar a un ACK para el paquete retransmitido correspondiente a txseq=1 antes de volver a transmitir.

Mientras tanto, el Rx puede recibir paquetes txseq=5 - txseq=9 con éxito. Cada una de estas recepciones de paquetes hace que se devuelva un ACK, pero el siguiente paquete en la secuencia requerida por el Rx aún sigue siendo txseq=1, de tal manera que se transmite el mismo ACK de vuelta al Tx para cada uno de los paquetes recibidos txseq=5 a txseq=9. El Tx ignora los ACK correspondientes a los paquetes txseq=6 - txseq=9, ya que todos ellos también tienen rxseq=1. Solo después de la recepción correcta del paquete txseq=1 el Rx transmite un ACK con rxseq=2.

Como se ilustra, el paquete txseq=1 se recibe con éxito en el Rx y se genera un ACK con rxseq=2. Dado que el valor de CWND es solo 1 debido a la reducción causada por el paquete perdido, el Tx espera al ACK rxseq=2 antes de enviar cualesquiera otros paquetes. Tras la recepción del ACK rxseq=2, el valor de CWNd se aumenta a 2 y el Tx envía los siguientes dos paquetes perdidos, txseq=2 y txseq=3. Aquí se supone que estos ACK llegan dentro del periodo de tiempo de espera del TCP, de modo que se incrementa el CWND de la ventana de congestión a 3 y se transmiten posteriormente los paquetes txseq=4 y txseq=5. La figura no muestra ninguna comunicación adicional, aunque es implícito que se acusará el recibo de estos siguientes paquetes y continuará la transferencia de datos. Obsérvese que los paquetes con txseq=5 a 9 se retransmitirán todos incluso aunque se recibieran exitosamente la primera vez.

5

10

15

20

25

30

35

40

45

50

55

60

65

El protocolo de retransmisión basado en TCP anterior no proporciona un nivel deseado de eficacia, dado que hay retardos claramente evidentes en la espera a los ACK devueltos y porque la ventana de congestión CWND se somete a reducción inmediata a un nivel mínimo de 1 paquete tras la detección de una pérdida y debido a que el incremento en el tamaño de la ventana es lento, realizándose únicamente en base a la finalización satisfactoria de idas y vueltas de una transmisión de paquetes y una confirmación de la recepción.

El planteamiento anterior es útil cuando existe una suposición de que no hay demasiadas pérdidas de paquetes. Esta suposición es válida cuando las conexiones de red son sobre enlaces terrestres fiables o incluso sobre enlaces por satélite donde existe poca interferencia, como con las comunicaciones de estación fija a satélite. Se pueden hacer mejoras en el rendimiento del sistema utilizando una gran ventana inicial, soportada por grandes capacidades de almacenamiento para obtener los paquetes de la secuencia, y aumentando la ventana más rápidamente cuando los paquetes del ACK se devuelven con éxito, en base a la confianza en la fiabilidad del sistema. Sin embargo, este planteamiento puede no ser adecuado cuando hay terminales móviles COTM y donde la congestión es posible.

Una mejora al protocolo de retransmisión anterior puede superar estos problemas y conseguir objetivos importantes, especialmente cuando es probable que se encuentren problemas tanto de congestión como de interferencia. Primero, el protocolo de retransmisión mejorado permite que los nodos de comunicación determinen rápidamente si los paquetes se han perdido durante el tránsito. Segundo, el protocolo de retransmisión mejorado evita las retransmisiones innecesarias para minimizar la latencia y mantener la carga del canal en un mínimo. Con el protocolo mejorado, no existen retransmisiones espurias ni ninguna retransmisión basada en el tiempo de espera de RTT. Además, las transmisiones son insensibles al retardo y a la variación del retardo, e insensibles a la capa de enlace ARQ, de haberlas. El rendimiento promedio que se puede lograr se acerca a una tasa de pérdida de 1 paquete.

Para conseguir estos objetivos, el protocolo de retransmisión utiliza señalización selectiva de ACK (confirmación positiva) y de NACK (confirmación negativa), en lugar de utilizar dicha señalización para cada paquete como en la Figura 6. También permite el uso de un gran número de señales ACK/NACK por paquete aCk. En particular, a cada paquete se le asigna un número de la secuencia de envío txseq, como en el TCP convencional, pero un valor de la secuencia de tiempo Tseq también se mantiene en el transmisor. Este número de secuencia se incrementa siempre que se transmite o retransmite un paquete, y el valor actual de la secuencia de tiempo se guarda de forma local para cada paquete siempre que se transmite o retransmite. El receptor envía paquetes de confirmación, usando las mismas reglas que el TCP convencional. Sin embargo, existen paquetes adicionales generados y transmitidos para transportar eficazmente información de transmisión y recepción.

Por ejemplo, cada N paquetes, en donde N es un número entero (p. ej., N=4), se envía un paquete STATREQ por el transmisor al receptor. El paquete STATREQ contiene (1) el número de secuencia de tiempo, el txTseq, y (2) el número de secuencia más alto enviado, txSseq más 1. El paquete STATREQ también se envía siempre que hayan transcurrido TstatReq1 segundos (p. ej., 0,1 segundos) desde que se envió el último paquete STATREQ, y algunos datos permanecen sin confirmación. El paquete STATREQ se envía también siempre que hayan transcurrido TstatReq2 segundos (p. ej., 5 segundos) desde que se envió el último paquete de STAtrEq, y ningún dato permanece sin confirmación. La información STATREQ puede transmitirse como reserva en un paquete de datos normal, cuando es posible. Por lo tanto, dentro de un tiempo ida y vuelta RTT, se pueden enviar varios paquetes STATREQ. Los valores de TstatReq1 y TstatReq2 son parámetros de diseño del sistema que se pueden fijar basándose en un tiempo de ida y vuelta y/u otros parámetros del sistema como entenderán los expertos en la técnica.

Las siguientes características se implementan como reglas para el protocolo de retransmisión.

Siempre que un terminal receptor recibe un paquete fuera de la secuencia cuyo número de secuencia es mayor que el mayor número de secuencia recibido, el terminal receptor envía un paquete USTAT al terminal de transmisión, identificando los números de secuencia de los paquetes perdidos, los números de secuencia del paquete recibido y el número de secuencia de la confirmación normal. Esta etapa puede opcionalmente ser omitida si se espera que la red reordene los paquetes.

Siempre que el terminal de recepción recibe un paquete STATREQ, envía al terminal de transmisión un paquete STAT, que contiene el número de la secuencia de tiempo recibida, el número de secuencia para todos los paquetes perdidos, los números de secuencia de todos los paquetes recibidos y el número de secuencia de la confirmación normal.

Siempre que el terminal de transmisión recibe un paquete USTAT, libera paquetes de confirmación y retransmite al terminal de recepción los paquetes perdidos identificados en el paquete USTAT.

Siempre que el terminal de transmisión recibe un paquete STAT, libera paquetes de confirmación y retransmite al terminal de recepción los paquetes perdidos identificados en el paquete STAT, si el valor de secuencia de tiempo guardado para el paquete es menor que el valor de secuencia de tiempo recibido en el paquete STAT. Si se espera que la red reordene los paquetes, entonces se realiza la última comparación con el valor de la secuencia de tiempo recibido en el paquete STAT menos un valor REORDERCOUNT, que representa el número de paquetes que pueden recibirse desordenados (y sin duda reunirse en un orden apropiado), antes de que se

5

10

15

20

25

30

35

40

45

50

55

60

65

determine que se ha producido una pérdida de paquetes y que se puede detener una transmisión adicional. Se recomienda un valor de REORDERCOUNT = 3 y es similar a la que se utiliza en el TCP estándar.

Según una realización ilustrativa de la presente invención, a cada paquete se le asigna un número de la secuencia de envío txseq, como se hace en el TCP normal. Se mantiene un contador de secuencia de tiempo txTseq en el transmisor, que se incrementa siempre que se transmite o retransmite un paquete. El número de secuencia de tiempo txTseq se iniciará en cero para el primer paquete de una transmisión y se incrementará cada vez que se transmite un paquete, tanto si ese paquete era como si no una transmisión original o una retransmisión. Por lo tanto, si no es necesario retransmitir paquetes, txTseq siempre será igual que txseq. El receptor envía paquetes de confirmación tradicionales, usando las mismas reglas que el TCP normal.

En el TCP normal, el temporizador de retransmisión está basado en el tiempo de ida y vuelta RTT y se duplica con cada tiempo de espera. Las retransmisiones se realizan siempre que expira el temporizador de retransmisión. Sin embargo, según la realización ilustrativa de la invención, el temporizador de retransmisión TCP se utiliza solamente durante la configuración de la conexión. Para retransmisiones de datos, se usan paquetes STATREQ periódicos, que no están relacionados con el tiempo de ida y vuelta.

La Figura 7 es un diagrama de secuencia de tiempos que ilustra la operación de una realización ilustrativa del aspecto de retransmisión de la presente invención para el mismo canal degradado que se usa en la Figura 6. El terminal de transmisión en este ejemplo envía una STATREQ cada 4 paquetes comenzando con el paquete txseq=4.

El terminal de transmisión Tx inicia la transmisión por el envío del paquete txseq=0 y la transmisión se recibe en el terminal receptor Rx y se confirma mediante la transmisión de un ACK y rxseq=1 al Tx. Como en la Figura 6, se envían los paquetes de datos posteriores txseq=1 a txseq=4, pero la transmisión está bloqueada por interferencia. Una diferencia es que la última transmisión de txseq=4 está acompañada por un STATREQ con txSseq=4 (indicando que el número de la secuencia de paquete txseq más alto, enviado hasta el momento es txseq=4) y txTseq=4 (indicando que han tenido lugar un total de 4 trasmisiones de paquetes —original (4 transmisiones) o retransmisiones (0 transmisiones)—).

El terminal de transmisión Tx envía entonces paquetes de datos con números de secuencia (txseq) de transmisión 58 como en el caso anterior de la Figura 6. El paquete txseq=8 sigue al txseq=7 y ahora también contiene el STATREQ con txSseq=8 (indicando que el número de secuencia de paquetes más alto, txseq, enviado hasta el momento es txseq=8) y txTseq=8 (indicando que han tenido lugar un total de txTseq + 1=8 transmisiones de paquetes —originales o retransmisiones—). Las líneas discontinuas para txseq=1 - txseq=4 (que incluyen el STATREQ) indican que estos paquetes se pierden nuevamente en la ruta hacia el terminal Rx de recepción. No obstante la pérdida de paquetes, el terminal Tx de transmisión continúa enviando nuevos paquetes hasta txseq=11.

Una vez que Rx recibe txseq=0, responde con una confirmación ACK con rxseq=1, indicando que ha recibido exitosamente la secuencia de paquete hasta txseq=0.

El siguiente paquete exitoso en el receptor es txseq=5. Este paquete desordenado hace que el Rx envíe un paquete de UsTaT con rxseq=1 (indicando que se ha recibido exitosamente la secuencia de paquetes hasta txseq=0). También envía una lista de extensión [1, 5, 6] que, como se explicará más adelante, indica que los paquetes con txseq=1 a txseq=4 se han perdido, y el paquete con txseq=5 se ha recibido. El listado de 6 no indica que se hayan recibido 6 sino simplemente sirve como marcador para el final de la lista de extensión.

A continuación, el Rx recibe con éxito los paquetes txseq=6 y txseq=7. El próximo paquete en la secuencia requerida por el Rx aún sigue siendo txseq=1. Por lo tanto, el ACK idéntico se transmite de nuevo al Tx (con rxseq=1) en respuesta a la recepción de ambos paquetes para txseq=6 y txseq=7. A continuación, el Rx recibe el paquete de datos txseq=8 con STATREQ, txSseq=8 y txTseq=8. El Rx responde de inmediato con un mensaje STAt con la lista de extensión [1, 5, 9], indicando que ha recibido con éxito paquetes hasta txseq=8, pero todavía le faltan los paquetes con txseq=1 a txseq=4. Este mensaje STAT también tiene rxseq=1, ya que el próximo paquete en la secuencia que necesita el Rx aún sigue siendo txseq=1.

El Rx recibe a continuación paquetes con txseq=9 a txseq=11. El siguiente paquete necesario en la secuencia para el Rx aún sigue siendo txseq=1 tras la recepción de estos paquetes, por lo que de nuevo se transmite un ACK idéntico al ACK anterior (con rxseq=1) al Tx en respuesta a estas recepciones de paquetes para txseq=9 a txseq=11.

Después de que se transmita el paquete con txseq=11, el Tx recibe el USTAT identificando qué paquetes se han perdido (1 a 4). Anota el primer paquete que se ha perdido y retransmite ese paquete, txseq=1. Asimismo, txTseq es ahora 12, un múltiplo de 4, de tal manera que el Tx retransmite como reserva un STATREQ con el paquete de datos. Para este STATREQ, txSseq es 11, ya que el paquete de transmisión con el número de secuencia más alto ya transmitido tiene txseq=11.

El Tx retransmite posteriormente paquetes con txseq=2 a txseq=4. Mientras tanto, el Tx recibe e ignora los ACK correspondientes a los paquetes txseq=6 y txseq=7 (ambos tienen rxseq=1). También recibe e ignora el STAT que resulta del STATREQ del paquete con txseq=8, ya que la siguiente lista de extensión [1, 5, 9] no proporciona

5

10

15

20

25

30

35

40

45

50

55

60

65

información nueva acerca de los paquetes no exitosos. Del mismo modo, el Tx recibe e ignora los ACK correspondientes a los paquetes txseq=9 a txseq=11, ya que todos tienen rxseq=1.

Después de que el Tx haya transmitido el último de los paquetes perdidos conocidos (txseq=4), continúa transmitiendo el siguiente paquete en orden, txseq=12. Este paquete de transmisión tiene coincidentemente txTseq=16 (indicando que han tenido lugar un total de txTseq + 1 = 17 transmisiones de paquetes —original o retransmisiones—). Dado que txTseq es un múltiplo de N, donde N=4, se transmite un sTaTREQ junto con el paquete de datos txseq=12. Este STATREQ tiene txSseq=12 (indicando que el número de secuencia de paquete más alto, txseq, enviado hasta el momento es 12) y txTseq=16. El Tx acaba sus transmisiones en este ejemplo mediante el envío posterior de paquetes con txseq=13 y txseq=14, respectivamente (no mostrados).

Cuando el Rx recibe la retransmisión de paquetes de datos txseq=1 y su STATREQ con txTseq=11 y txSseq=12, anota que ahora se ha recibido completamente la secuencia de transmisión hasta txseq=1 y por tanto establecerá rxseq=2 y responderá con un STAT que contiene la lista de extensión [2, 5, 12] dado que el hueco de paquetes conocido es ahora solo desde txseq=2 a 4=txseq, y los paquetes txseq=5 a txseq=11 se han recibido con éxito. A medida que el Rx recibe los paquetes retransmitidos txseq=2 a txseq=4, responde con ACK que contienen rxseq=2 a rxseq=4, respectivamente.

Cuando Rx recibe el paquete txseq=12 y su STATREQ, anota que ahora ha recibido completamente la secuencia de transmisión hasta txseq=12 y por lo tanto fija rxseq=13 y responde con un STAT que contiene una lista de extensión []. Aunque no se muestra, responde a las últimas dos recepciones de paquetes txseq=13 y txseq=14 con ACK que contienen rxseq=14 y rxseq=15, respectivamente.

En la descripción anterior del protocolo de retransmisión que realiza un aspecto de la presente invención, se utilizó una lista de paquetes recibidos que limita los paquetes perdidos y se denominó “lista de extensión”. Las listas de extensión representan una técnica para especificar qué paquetes se han (o no se han) recibido con éxito. Si se han recibido todos los paquetes conocidos (en el receptor) que transmitir, entonces la lista de extensión será nula. Si se conoce un único hueco, entonces una lista de extensión de dos elementos [a, b] indicará que se sabe que los paquetes con txseq=a a b- 1 se han perdido. Si se agrega otro elemento a la lista de extensión, dando como resultado [a, b, c], hay aún una indicación de que se sabe que los paquetes con un txseq=a a txseq=b-1 se han perdido. Además, se afirma que los paquetes con txseq=b a txseq=c-1 se han recibido con éxito. Cada elemento añadido a la lista de extensión identificará de forma alternativa un bloque 'conocido como perdido' o un bloque 'conocido como recibido'. Si bien esta es una técnica para representar bloques perdidos o recibidos, existen muchas técnicas equivalentes tales como el envío de los números de secuencia de todos los paquetes recibidos con éxito, a pesar de que esa técnica alternativa puede dar como resultado grandes listas que podrían aumentar enormemente la sobrecarga del sistema.

Como se ha indicado anteriormente con respecto a la Figura 6, el TCP estándar utiliza una ventana CWND que es un valor retenido en el transmisor y representa el número de paquetes que pueden haberse transmitido y permanecer sin confirmación, antes de que se detenga la transmisión adicional. El tamaño de la ventana se correlaciona con el tamaño de la memoria disponible para almacenar paquetes transmitidos, ya que puede que se tengan que retransmitir esos paquetes si finalmente se determina que se han perdido. Cuando los recursos de memoria están limitados, o cuando se esperan pérdidas de paquetes debido a interferencia o congestión, el valor CWND o tamaño de ventana es inicialmente pequeño, y la reducción en el valor CWND tras la pérdida de un paquete es rápida, siendo el aumento de CWND para comunicaciones de ida y vuelta con éxito deliberadamente lento. Específicamente, el algoritmo del TCP estándar aumenta CWND solamente en un paquete cada RTT. Esto es especialmente problemático para enlaces de retardo alto, debido a que el RTT es largo debido al retardo, independientemente de cualquier retardo relacionado con la congestión. Incluso si hay un aumento exponencial en el tamaño de la ventana, lo que podría aumentar la velocidad de cualquier aumento, el resultado no sería justo, ya que se favorecería a las conexiones más antiguas sobre las conexiones más recientes.

La presente invención modifica considerablemente el planteamiento TCP estándar al aumentar el tamaño de la ventana rápidamente basándose en una determinación de que la congestión es baja. La modificación en el tamaño de la ventana se diseña para que sea justa a través de múltiples conexiones tCp. Según una realización ilustrativa para esta característica de la invención, como se ilustra con respecto al diagrama de flujo ilustrativo de la Figura 8, en la etapa S80 (START) se fija el tamaño de la ventana inicial (CWND) (p. ej., 2 u 8 paquetes). También se fija una variable del incremento de tamaño de la ventana (CWNDINC) (p. ej., 1 paquete). En la etapa S81, se realiza una determinación en un terminal de transmisión de si se ha recibido por un terminal de recepción una confirmación de un paquete transmitido (p. ej., en forma de un segmento ACK). La invención no se limita al uso de una señal ACK, y se conocen en la técnica otras maneras de determinar una recepción exitosa de un paquete en un terminal de recepción. Tras la determinación de que ha habido una recepción (SÍ) con éxito, se realiza una determinación en la etapa S82 para determinar si (1) se ha recibido un ECN en el terminal de transmisión, indicando la existencia de congestión de una manera conocida en la técnica, y si no se ha disminuido el CWND dentro del último tiempo de ida y vuelta. Si se cumplen las dos condiciones (SÍ), el proceso pasa a la etapa S85 y se reduce el tamaño de la ventana (CWND). Además, el incremento para el aumento del tamaño de la ventana (CWNDINC) se restablece o, en un planteamiento alternativo, se reduce en una cantidad predeterminada. Si el resultado de la determinación en la etapa S82 es NO, entonces se realiza una determinación en la etapa S83 de si ha transcurrido un tiempo de ida y vuelta. Si no hay congestión (etapa S82) y ha transcurrido un tiempo de ida y vuelta (etapa S83), entonces se puede justificar una operación agresiva del

5

10

15

20

25

30

35

40

45

50

55

60

65

sistema. En este caso, el CWND se incrementa aditivamente por el valor de ajuste de CWNDINC, en la etapa S84. Además, en la misma etapa, se incrementa CWNDINC de modo multiplicativo, por ejemplo, por un factor de FI (p. ej., 1,5). El proceso se repite a continuación con el valor de CWND y cambiándose el valor de CWNC cada tiempo de ida y vuelta, a menos que se encuentre congestión o un segmento de ACK no se reciba a tiempo.

Como se observa, en lugar de depender de la recepción de un paquete de ACK, estas reglas de incremento se pueden implementar también con el uso de un número de bytes en lugar de un número de paquetes. Además, las reglas pueden basarse en cálculos que se realizan en la recepción de cada paquete de ACK, en lugar de una vez por RTT. El algoritmo proporciona un aumento mucho más rápido de CWND que el algoritmo estándar de TCP. Esto es especialmente valioso para los enlaces de alto retardo. En la tabla ilustrada en la Figura 9 se proporcionan unos ejemplos de CWND para unos RTT de 0-10, con aumentos de CWND hasta que se produce una reducción debido a la existencia de un ECN, seguido de una reanudación del aumento.

Como ya se observó, la presente invención aumenta el rendimiento de la red aprovechando el hecho de que, en un entorno de canal degradado, la pérdida de paquetes puede atribuirse al deterioro del canal en lugar de ser un indicador absoluto de congestión. En cualquier momento determinado, se permite que permanezcan hasta CWND paquetes pendientes de confirmación. Debe observarse que los datos de confirmación no se cuentan en el CWND para este propósito. Cuando se retransmite un paquete, el CWND no se modifica automáticamente. Por lo tanto, se suprime una disminución de CWND con la pérdida de paquete. Sin embargo, el CWND se disminuye basándose en el ECN y otros indicadores de congestión. Opcionalmente, el CWND se puede disminuir tras la retransmisión del paquete, después de cual, no se reduce durante un tiempo de ida y vuelta.

Específicamente, dado que un transmisor o enrutador puede establecer un bit de ECN en un encabezado IP cuando se detecta la congestión, y se envía una notificación de ECN de vuelta al transmisor por el receptor para avisar de la existencia de congestión, el transmisor puede ajustar entonces el CWND según una regla que hace que disminuya por un factor F de multiplicación (p. ej., 0,5). Sin embargo, el CWND no disminuye posteriormente durante un tiempo de ida y vuelta RTT. El tamaño de la ventana también puede disminuirse mediante un factor de multiplicación F, si la congestión se detecta por otros medios, tales como un aumento en el retardo de ida y vuelta. El CWND no disminuye posteriormente durante un tiempo de ida y vuelta. El CWND se incrementa al recibir un paquete de ACK según las reglas de aumento de ventana aplicables.

Si se retransmiten múltiples paquetes, estos pueden ser “moderados” t segundos entre sí, en donde t = tiempo de ida y vuelta / CWND (en paquetes). El tiempo de ida y vuelta (RTT) se mide usando procedimientos de TCP normales (p. ej., usando la opción de marca de tiempos en cada paquete de datos). Alternativamente, si se usa el protocolo de retransmisión mejorado como se ejemplifica por la ilustración de la Figura 7 y se logra una mayor eficiencia, el tiempo de ida y vuelta se puede medir empleando paquetes de STATREQ y STAT únicamente.

Según otra característica ilustrativa de la presente invención, cada instancia del TCP mejorado (designada por la notación abreviada “TCP XL”) según la presente invención se configura con información relacionada con (1) si puede soportar las características de la invención y (2) si prefiere las características de la invención. Una ilustración de estos bits se proporciona en la Figura 10A. Estos dos bits se intercambian en paquetes de configuración de llamada (SYN) de TCP. Un algoritmo para determinar el uso de la invención, basándose en la entrada de los usuarios en cada extremo de un enlace de comunicación, se ilustra en la Figura 10B y se inicia para cada instancia, como se muestra en la etapa S100. El proceso para configurar la conexión utilizando los paquetes SYN pasa a la etapa S101 con una inserción en el paquete SYN de dos códigos de preferencia del tipo ilustrado en la Figura 10A. Los códigos se intercambian en la etapa S102 y cada usuario evalúa la información del otro usuario. En la etapa S103, se determina, en un terminal de usuario, si ambos lados de un enlace de comunicaciones soportan el protocolo de retransmisión avanzado. Si no, se usa el protocolo TCP normal en la etapa S105 y se deshabilitan las características y procedimientos del protocolo avanzado. Si ambos lados soportan el protocolo, y se determina que al menos un lado prefiere el uso del protocolo avanzado en la etapa S104, entonces se habilitan los procedimientos del protocolo avanzado en la etapa S106. Un usuario que tenga la capacidad de usar el procedimiento avanzado puede elegir no hacerlo por diversas razones. Por ejemplo, un terminal que normalmente sea móvil puede fijarse temporalmente. En este caso el terminal indicaría que no prefiere el uso de las características de TCP mejoradas durante el tiempo que estaba fijo, para minimizar el tiempo de CPU, la sobrecarga del canal, etc. Para las conexiones recientemente utilizadas, la dirección IP de destino y los resultados de la negociación sobre el uso de la invención se guardan en una memoria local. Esta información histórica puede usarse posteriormente en el inicio para implementar la configuración del protocolo avanzado y los procedimientos de conexión. Finalmente, la determinación de si se usa el primer o el segundo protocolo puede basarse en información de la congestión, determinada por la recepción de información de ECN, retardos en el tiempo de ida y vuelta u otros indicios de congestión.

En el TCP regular, la configuración de la conexión se realiza por medio de un primer terminal y un segundo terminal que intercambian paquetes SYN. Cuando se determina que se han perdido paquetes SYN, debido a la ausencia de una respuesta, los paquetes SYN perdidos se retransmiten después de un tiempo de espera. El tiempo de espera se establece en 3 segundos inicialmente, y se duplica después de cada tiempo de espera. Como resultado, el tiempo de configuración puede prolongarse sustancialmente en enlaces degradados. Dado que los paquetes de datos no pueden enviarse hasta que se complete la conexión y el establecimiento se complete, se degrada el rendimiento del sistema. El protocolo

5

10

15

20

25

30

35

avanzado utiliza un procedimiento de configuración de la conexión TCP mejorado que reduce el tiempo de configuración de la conexión ya que, si no se sabe que el destino soporta el procedimiento TCP mejorado, entonces se utiliza el procedimiento de TCP convencional. Sin embargo, si se sabe que el destino soporta el procedimiento del TCP mejorado (p. ej., basándose en el contenido de una memoria caché o basándose en la configuración), entonces el valor del tiempo de espera se establece en una pequeña duración (p. ej., 0,1 segundos) y no se cambia para cada retransmisión. Como resultado, puede haber múltiples paquetes SYN pendientes en cualquier momento dado. Si cualquiera de ellos se suministra al receptor, entonces el procedimiento de establecimiento de la conexión puede pasar a su próxima etapa.

La Figura 11 es un diagrama de bloques de otro sistema ilustrativo que puede implementar el protocolo TCP mejorado, que se implementa en terminales relevantes por un módulo designado como TCP-PEP-XL. En la Figura 11, las características del TCP mejoradas están contenidas en el terminal COTM que se comunica directamente sobre el canal que tiende a interrumpirse (es este caso, satélite). El satélite de retransmisión es en este caso un satélite de procesamiento que también contiene una implementación de las características del TCP mejoradas. El satélite se comunica con una interfaz de red en tierra que, en este caso, utiliza un TCP-PEP tradicional, ya que este terminal de interfaz de red ilustrativo es fijo y por lo tanto no está sometido a interrupciones o degradaciones del canal en su trayectoria directa al satélite.

La Figura 12 es un ejemplo de un satélite transparente o de repetición simple. De forma adicional, la característica de TCP mejorada del COTM se implementa en un huésped independiente que se comunica mediante Ethernet al terminal de satélite. En este caso, el terminal (interfaz de red) fijo debe implementar también la característica de TCP mejorada para permitir que el protocolo mejorado funcione. Aunque no se muestra, el terminal fijo podría implementar también la característica de TCP mejorada en un huésped separado tal como se ilustra en el terminal COTM de esta figura.

La Figura 13 muestra un ejemplo de implementación independiente del huésped 1300 de TCP-PEP-XL de la Figura 12. El protocolo se implementa en un ordenador huésped LINUX o UNIX 1301 con al menos dos adaptadores Ethernet, ethernet0 y ethernet1, conectados respectivamente a la red terrestre y al terminal de satélite. En la capa de Software IP 1302, los paquetes no TCP se transfieren de modo transparente mediante técnicas industriales normales. Dos túneles, tun0 y tun1, conectan el módulo 1303 de TCP-PEP-XL (que se asienta al mismo nivel que el TCP) en el nivel IP 1304 para ethernet0 y ethernet1, respectivamente.

Aunque la presente invención se ha descrito en relación con un cierto número de realizaciones, implementaciones, modificaciones y variaciones que tienen ventajas específicas para ellas, la presente invención no está necesariamente limitada a ello, sino que cubre diversas modificaciones obvias y disposiciones equivalentes de acuerdo con los aspectos más amplios, todos según el ámbito de las siguientes reivindicaciones.

Claims (8)

1. 10

   15
2. 2.

   20 (a)

   (b)

   (c)

   25
3. 3.

   30 4.
4. 5. 35
5. 6.

   40
6. 7.

   45
7. 8.
8. 9.

   50

   REIVINDICACIONES

   Un método para la retransmisión de paquetes entre un primer terminal y un segundo terminal en una red TCP que tiene una pluralidad de enlaces inalámbricos, soportando cada uno de dichos terminales la retransmisión TCP usando una ventana de tamaño variable, comprendiendo dicho método: establecer, en el primer terminal, un valor de incremento del tamaño de la ventana para incrementar un tamaño de ventana de dicha ventana de tamaño variable;

   transmitir, por el primer terminal, uno o más paquetes al segundo terminal sobre uno de la pluralidad de enlaces inalámbricos;

   aumentar dicho tamaño de ventana mediante dicho valor de incremento de tamaño de ventana en respuesta a la recepción de una o más confirmaciones que indican la recepción con éxito de uno o más de los paquetes transmitidos; caracterizado por

   cambiar dicho valor de incremento del tamaño de la ventana en respuesta a una o más de notificaciones de congestión y dichas una o más confirmaciones recibidas,

   en donde dicha etapa de cambio comprende aumentar dicho valor de incremento del tamaño de la ventana multiplicando dicho valor de incremento del tamaño de la ventana por un factor de multiplicación en respuesta a dichas una o más confirmaciones recibidas.

   El método de la reivindicación 1, que además comprende:

   establecer un tamaño de la ventana inicial y un valor de incremento inicial;

   determinar, para un paquete transmitido, que ha transcurrido un tiempo de ida y vuelta; y

   tras la recepción de un paquete de confirmación en respuesta al paquete transmitido, aumentar el

   tamaño de la ventana en la cantidad de dicho valor de incremento del tamaño de la ventana y aumentar

   dicho valor de incremento del tamaño de la ventana multiplicando el valor de incremento del tamaño de la

   ventana por el factor de multiplicación.

   Un método como se expone en la reivindicación 2, en donde las etapas (b) y (c) se repiten una pluralidad de veces.

   El método de la reivindicación 2, que además comprende: recibir una notificación de congestión; y

   disminuir el tamaño de la ventana basándose en la notificación de congestión recibida.

   El método de la reivindicación 2, que además comprende disminuir el tamaño de la ventana tras la retransmisión del paquete.

   El método de la reivindicación 2, que además comprende:

   al menos uno de entre restablecer y reducir el valor del incremento del tamaño de la ventana tras la retransmisión del paquete.

   El método de la reivindicación 2, que además comprende recibir una notificación de congestión; y

   restablecer o reducir el valor del incremento del tamaño de la ventana basándose en la notificación de congestión recibida.

   El método de la reivindicación 2, en donde el tamaño de la ventana no se reduce tras la retransmisión de paquetes.

   El método de la reivindicación 2, en donde el paquete de confirmación incluye un indicador establecido por el segundo terminal, señalando el indicador la existencia de congestión, comprendiendo además el método restablecer el valor del incremento del tamaño de la ventana al valor del incremento inicial basándose en el indicador y basándose además en la determinación de que ha transcurrido el tiempo de ida y vuelta del paquete.