Método y disposición para el control del flujo del TCP.

Disposición (124) para el control del flujo del Protocolo de Control de Transmisión (TCP) de datos desde unextremo de transmisión hasta un extremo de recepción a través de un elemento intermedio,

que comprende unamemoria intermedia de transmisión en un sistema de comunicaciones, comprendiendo la disposición unos mediospara determinar el retardo en la memoria intermedia de transmisión; y

estando caracterizada la disposición (124) porque presenta:

unos medios para modificar un tamaño de ventana de TCP anunciada, asociado al extremo de recepción,operativamente acoplados a los medios para determinar el retardo y dispuestos para modificar el tamaño de laventana de TCP en función del retardo determinado

Método y disposición para el control del flujo del TCP.

Campo de la invención La presente invención se refiere al control del flujo del TCP (Protocolo de Control de Transmisión) , y particularmente (aunque no de forma exclusiva) al control del flujo del TCP en sistemas de comunicaciones inalámbricas.

Antecedentes de la invención El TCP es un protocolo de transporte de la colección de protocolos de internet (véase, por ejemplo, la publicación de W. R. Stevens, “TCP/IP illustrated, Volume 1: The protocols”, Addison-Wesley, Reading, Massachusetts, noviembre de 1994) . El mismo se usa en aplicaciones tales como el FTP (Protocolo de Transferencia de Archivos) de telnet y el HTTP (Protocolo de Transferencia de Hipertexto) . El TCP está diseñado para redes por cable que presentan tasas de error muy bajas.

El control del flujo en el TCP se gobierna por medio de dos ventanas: la ventana de congestión (“cwnd”) del emisor y la ventana anunciada (“awnd”) del receptor. El control del flujo se basa en el mínimo de estas 2 ventanas. La “cwnd” se modifica dinámicamente para corresponderse con la capacidad de la red. Y lo más importante, se reduce siempre que se pierden paquetes puesto que esto es una indicación de congestión en la red. La “awnd” se basa en la capacidad del receptor para almacenar temporalmente datos que recibe y se puede reducir dinámicamente si el receptor no puede hacer frente a la velocidad de recepción de datos. El valor inicial de “awnd” se controla por medio de parámetros configurados en la pila de protocolos del TCP.

Como se ha mencionado anteriormente, el TCP está diseñado para redes con baja tasa de errores. Por lo tanto, cualesquiera pérdidas de paquetes que se produzcan en el TCP se consideran como debidas a una congestión de la red y, por ello, vienen seguidas por una reducción de la “cwnd” y consecuentemente de la velocidad de datos del emisor tal como se ha mencionado anteriormente. No obstante, esto no resulta apropiado para redes inalámbricas que sean inherentemente sistemas con una alta tasa de error. Por lo tanto, la norma del 3GPP (Proyecto de Asociación de 3ª Generación) proporciona funcionalidad de ARQ (Solicitud Automática de Repetición) , conocida como RLC (Control de Enlace de Radiocomunicaciones – véase, por ejemplo, la especificación técnica del 3GPP, 3GPP TS 25.322) que permite que se vuelvan a transmitir paquetes que han experimentado errores debido a una transmisión a través de la interfaz aérea. No obstante, el uso de esquemas de ARQ da como resultado que los paquetes lleguen desordenados, de modo que los mismos se deben almacenar temporalmente antes de que se puedan trasladar al TCP. El uso de almacenamiento temporal introduce un aumento del retardo y esto puede dar como resultado un aumento del RTT (Tiempo de Ida y Vuelta) .

Suponiendo que los servicios de velocidad más alta se proporcionan en el enlace descendente, esto significa que es probable que se requiera un gran almacenamiento temporal en el nodo de red, es decir, el RNC (Controlador de Red de Radiocomunicaciones) en el caso de sistemas 3GPP. Lo siguiente considera este problema del enlace descendente (DL) . No obstante, la presente invención también es apropiada para controlar flujos de TCP de enlace ascendente.

La velocidad de DL máxima especificada en la especificación técnica del 3GPP, 3GPP TS 34.108, es 2 Mbps. Suponiendo que no es posible modificar la pila de protocolos del TCP en el receptor (es decir, el UE) , es necesario por tanto que el UE anuncie una ventana que sea por lo menos igual al producto del ancho de banda por el retardo, apropiado para el servicio de 2 Mbps. Si el UE va a soportar la velocidad máxima de 2 Mbps, entonces la ventana anunciada debe ser extremadamente grande. Si en ese caso se proporciona al UE una velocidad menor (debido, por ejemplo, al hecho de que muchos UE están solicitando servicio al mismo tiempo) , entonces se podría producir un desbordamiento de la memoria intermedia. Si no se produce un desbordamiento de la memoria intermedia, el tiempo de ida y vuelta (RTT) será muy alto puesto que los datos pasarán mucho tiempo almacenados temporalmente en el nodo de red.

Un RTT elevado tendrá un impacto negativo sobre el rendimiento percibido por el usuario. Esto es así particularmente en el caso de que el usuario desee continuar navegando por la web mientras está descargando un archivo grande a través de FTP; la sesión de navegación web parecerá extremadamente lenta. Por lo tanto, se desea proporcionar una técnica de control de flujo con el fin de mantener un RTT objetivo para cualquier velocidad proporcionada por la red al mismo tiempo que se mantiene la capacidad de descargar datos a velocidades de hasta la velocidad máxima de 2 Mbps.

Tal como se ha mencionado previamente, el control del flujo lo proporcionan la “cwnd” del emisor y la “awnd” del receptor. Puesto que el control de la “cwnd” del emisor reside en el servidor, la misma puede estar ubicada de forma remota y no es en modo alguno controlable. Por lo tanto, es necesario que el control del flujo lo proporcione la “awnd”.

Se han sugerido varias esquemas (que se describen brevemente más adelante) para el control de flujo para TCP a través de sistemas inalámbricos 3G. No obstante, la cuestión de la que se ocupan la mayoría de ellos es evitar que la memoria intermedia en el nodo de red se desborde (es decir, el nodo emisor en el caso de descarga de datos) .

En la publicación de Koga, Kawahara y Oie, “TCP flow control using link layer information in mobile networks”, Proceedings of SPIE Conference of Internet Performance and Control of Network Systems III, Boston, Massachusetts 7, 2002, se propone que el receptor, es decir, el UE en el caso más probable de descarga de archivos, modifique la ventana del TCP que es anunciada por el mismo, basándose no en la capacidad de las memorias intermedias del receptor tal como se realiza convencionalmente sino en medidas obtenidas a partir del RLC. Este planteamiento es extremadamente problemático puesto que significa una modificación de la pila de protocolos de TCP en el UE y puede que no sea posible obtener control de esta pila. Esto es particularmente verdad en el caso en el que un PC (Ordenador Personal) esté conectado a un UE (que actúa efectivamente como un módem) y la pila de protocolos del TCP resida en el PC.

La publicación de Seok, Joo y Kang, “A-TCP: A mechanism for improving TCP performance in wireless environments”, IEEE broadband wireless summit, mayo de 2001, sugiere un esquema por medio del cual se realizan dos conexiones completamente divididas, una entre el servidor y el nodo de red y otra entre el nodo de red y el UE. Esto requiere una complejidad adicional considerable y puede que no produzca ningún beneficio para transferencias que usen el UDP (Protocolo de Datagrama de Usuario) . La publicación de Bakre y Badrinth, “I-TCP: indirect TCP for mobile hosts”, Proceedings of the 15th International conference on distributed computer systems, mayo de 1995, sugiere modificar el tamaño de la ventana del TCP en ACKs (paquetes de acuse de recibo) TCP. No obstante, en esta publicación, el objetivo es simplemente modificar el tamaño de la ventana del TCP al tamaño de memoria intermedia disponible en el nodo de red. La limitación de la ocupación de la memoria intermedia, como en esta publicación, no garantiza un RTT especificado.

Por lo tanto, existe una necesidad de un método y una disposición para un flujo del control del TCP, en donde se pueda (n) mitigar la (s) desventaja (s) antes mencionada (s) .

Jiang et al, en “TCP Reno and Vegas Performance in Wireless Ad Hoc Networks” ICC 2001, IEEE International Conference on Communications, Helsinki, Finlandia, 11 a 14 de junio, 2001, vol. 1 de 10, 11 de junio de 2001, páginas 132 a 136, usa un método de simulación para analizar el rendimiento del TCP en redes ad hoc. Se determina una ventana de congestión para un transmisor a partir de un tiempo de ida y vuelta (RTT) para paquetes TCP. Al transmisor se le proporciona información sobre retardos en memorias intermedias de nodos intermedios y el mismo usa esto en su determinación del RTT.

Igarashi et al, en “Mobility Aware TCP Congestion Control” IEEE, vol. 2, 27 de octubre de 2002 () , páginas 338 a 342, describe el rendimiento del TCP sobre redes inalámbricas que usan un traspaso post-registro. De acuerdo con el esquema propuesto se usan funciones o bien de control del flujo de TCP o bien de control de la congestión de acuerdo con un número de paquetes perdidos.

Sumario de la invención De... [Seguir leyendo]

1. Disposición (124) para el control del flujo del Protocolo de Control de Transmisión (TCP) de datos desde un extremo de transmisión hasta un extremo de recepción a través de un elemento intermedio, que comprende una memoria intermedia de transmisión en un sistema de comunicaciones, comprendiendo la disposición unos medios para determinar el retardo en la memoria intermedia de transmisión; y

estando caracterizada la disposición (124) porque presenta:

unos medios para modificar un tamaño de ventana de TCP anunciada, asociado al extremo de recepción, operativamente acoplados a los medios para determinar el retardo y dispuestos para modificar el tamaño de la ventana de TCP en función del retardo determinado.

2. Disposición (124) según la reivindicación 1, en la que los medios para modificar el tamaño de la ventana de TCP comprenden: unos medios para enviar una indicación de tamaño de ventana de TCP modificado al extremo de transmisión del sistema de comunicaciones.

3. Disposición (124) según la reivindicación 2, en la que el extremo de transmisión del sistema de comunicaciones es un servidor de TCP (140) .

4. Disposición (124) según la reivindicación 2 ó la reivindicación 3, en la que los medios para enviar una indicación de tamaño de ventana de TCP modificado están configurados para enviar la indicación de tamaño de ventana de TCP modificado en un paquete de acuse de recibo (310) .

5. Disposición (124) según cualquiera de las reivindicaciones anteriores, en la que los medios para modificar el tamaño de la ventana de TCP modifican el tamaño de la ventana de TCP en función del retardo determinado de la memoria intermedia de transmisión y de un retardo objetivo de la memoria intermedia de transmisión.

6. Disposición (124) según cualquiera de las reivindicaciones anteriores, en la que los medios para modificar el tamaño de la ventana de TCP modifican el tamaño de la ventana de TCP en función del retardo determinado de la memoria intermedia de transmisión y de un tamaño de ventana de TCP determinado previamente.

7. Disposición (124) según cualquiera de las reivindicaciones anteriores, en la que los medios para modificar el tamaño de la ventana de TCP modifican el tamaño de la ventana de TCP en función del retardo determinado de la memoria intermedia de transmisión y en función de la ganancia del bucle de control.

8. Disposición (124) según cualquiera de las reivindicaciones anteriores, en la que los medios para modificar el tamaño de la ventana de TCP comprenden unos medios para determinar un número de paquetes de acuse de recibo recibidos.

9. Disposición (124) según la reivindicación 8, en la que los medios para modificar el tamaño de la ventana de TCP están dispuestos para modificar adicionalmente el tamaño de la ventana de TCP como respuesta a la determinación, por parte de los medios para determinar un número de paquetes de acuse de recibo recibidos (310) , de un número de paquetes de acuse de recibo igual a la mitad de un número actual de unidades de datos en el sistema.

10. Disposición (124) según cualquiera de las reivindicaciones anteriores, en la que los medios para determinar el retardo en la memoria intermedia de transmisión del elemento intermedio comprenden: unos medios para determinar el retardo medio de la memoria intermedia de una pluralidad de unidades de datos que pasan a través de la memoria intermedia de transmisión y los medios para modificar el tamaño de la ventana de TCP modifican el tamaño de la ventana de TCP en función del retardo medio de la memoria intermedia.

11. Disposición (124) según la reivindicación 10, en la que los medios para modificar el tamaño de la ventana de TCP están dispuestos para modificar el tamaño de la ventana de TCP si el retardo medio de la memoria intermedia está dentro de un intervalo predeterminado en torno a un retardo objetivo, en una cantidad relacionada con una diferencia entre el retardo medio de la memoria intermedia y el retardo objetivo.

12. Disposición (124) según la reivindicación 10, en la que los medios para modificar el tamaño de la ventana de TCP están dispuestos para modificar el tamaño de la ventana de TCP si el retardo medio de la memoria intermedia está fuera de un intervalo predeterminado en torno a un retardo objetivo, en una cantidad relacionada con una diferencia entre un tamaño medio actual de la memoria intermedia y un valor predeterminado.

13. Disposición (124) según cualquiera de las reivindicaciones anteriores, en la que el sistema de comunicaciones es un sistema de comunicaciones inalámbricas y el elemento intermedio es un controlador de red del sistema.

14. Disposición (124) según la reivindicación 13, en la que el sistema de comunicaciones inalámbricas comprende un sistema UTRAN.

15. Método para el control del flujo del Protocolo de Control de Transmisión (TCP) de datos desde un extremo de transmisión hasta un extremo de recepción a través de un elemento intermedio, que comprende una memoria intermedia de transmisión en un sistema de comunicaciones, comprendiendo el método determinar el retardo en la

memoria intermedia de transmisión; y

caracterizado porque comprende la etapa que consiste en:

modificar un tamaño de ventana de TCP anunciada, asociado al extremo de recepción, en función del retardo 10 determinado.

16. Método según la reivindicación 15, en el que la modificación del tamaño de la ventana de TCP comprende enviar una indicación del tamaño de ventana de TCP modificado a un extremo de transmisión del sistema de comunicaciones.

17. Método según la reivindicación 15 ó la reivindicación 16, en el que el envío de una indicación del tamaño de ventana de TCP modificado se envía en un paquete de acuse de recibo (310) .

18. Método según cualquiera de las reivindicaciones anteriores 15 a 17, en el que la modificación del tamaño de

ventana de TCP comprende: determinar un tamaño de ventana de TCP nuevo en función del retardo determinado y de un retardo objetivo de la memoria intermedia de transmisión.

19. Método según cualquiera de las reivindicaciones anteriores 15 a 18, en el que la modificación del tamaño de la ventana de TCP comprende determinar un tamaño de ventana de TCP nuevo en función del retardo determinado y 25 de un tamaño de ventana de TCP determinado previamente.

20. Método según cualquiera de las reivindicaciones anteriores 15 a 19, en el que la modificación del tamaño de la ventana de TCP comprende modificar el tamaño de la ventana de TCP en función del retardo determinado de la memoria intermedia de transmisión y en función de la ganancia del bucle de control.

21. Método según cualquiera de las reivindicaciones anteriores 15 a 20, que comprende además determinar un número de paquetes de acuse de recibo (310) recibidos.

22. Método según la reivindicación 21, en el que la modificación adicional de un tamaño de ventana de TCP se

realiza como respuesta a la determinación de un número de paquetes de acuse de recibo (310) recibidos igual a la mitad de un número actual de unidades de datos en el sistema de comunicaciones.

23. Método según cualquiera de las reivindicaciones anteriores 15 a 22, en el que la determinación del retardo en la memoria intermedia de transmisión del elemento intermedio comprende determinar el retardo medio de la memoria intermedia de una pluralidad de unidades de datos que pasan a través de la memoria intermedia de transmisión y modificar el tamaño de la ventana de TCP en función del retardo medio de la memoria intermedia.

24. Método según la reivindicación 23, que comprende modificar el tamaño de la ventana de TCP si el retardo medio de la memoria intermedia está dentro de un intervalo predeterminado en torno a un retardo objetivo, en una cantidad 45 relacionada con una diferencia entre el retardo medio de la memoria intermedia y el retardo objetivo.

25. Método según la reivindicación 23, que comprende modificar el tamaño de la ventana de TCP si el retardo medio de la memoria intermedia está fuera de un intervalo predeterminado en torno a un retardo objetivo, en una cantidad relacionada con una diferencia entre un tamaño medio actual de la memoria intermedia y un valor predeterminado.

26. Método según cualquiera de las reivindicaciones anteriores 15 a 25, en el que el elemento intermedio es un controlador de red de un sistema de comunicaciones inalámbricas.

27. Método según la reivindicación 26, en el que el sistema de comunicaciones inalámbricas comprende un sistema 55 UTRAN.

28. Elemento de programa de ordenador, que comprende unos medios de programa de ordenador para ejecutar el método según cualquiera de las reivindicaciones anteriores 15 a 27.

29. Circuito integrado, que comprende la disposición (124) según cualquiera de las reivindicaciones anteriores 1 a 14.