ES2397629T3 - Método y disposición para el control del flujo del TCP - Google Patents

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

Info

Publication number
ES2397629T3
ES2397629T3 ES04743079T ES04743079T ES2397629T3 ES 2397629 T3 ES2397629 T3 ES 2397629T3 ES 04743079 T ES04743079 T ES 04743079T ES 04743079 T ES04743079 T ES 04743079T ES 2397629 T3 ES2397629 T3 ES 2397629T3
Authority
ES
Spain
Prior art keywords
size
delay
tcp window
tcp
arrangement
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES04743079T
Other languages
English (en)
Inventor
Timothy Speight
Nicholas Jelbert
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Application granted granted Critical
Publication of ES2397629T3 publication Critical patent/ES2397629T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/06—Transport layer protocols, e.g. TCP [Transport Control Protocol] over wireless

Landscapes

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

Abstract

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

Description

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 acuerdo con un primer aspecto de la presente invención, se proporciona una disposición para el control del flujo de TCP según la reivindicación 1.
De acuerdo con un segundo aspecto de la presente invención, se proporciona un método para el control del flujo del TCP según la reivindicación 15.
Breve descripción de los dibujos
A continuación se describirán, únicamente a título de ejemplo, un método y una disposición para el control del flujo de TCP, que incorporan la presente invención, en referencia al(a los) dibujo(s) adjunto(s), en los cuales:
la FIG. 1 muestra un diagrama esquemático de bloques que ilustra un sistema de radiocomunicaciones 3GPP en el cual se puede usar la presente invención;
la FIG. 2 muestra un diagrama esquemático de bloques que ilustra la arquitectura de protocolos para el plano U, mostrando la ubicación funcional de una función de modificación de ventanas de TCP basada en la presente invención; y
la FIG. 3 muestra un diagrama esquemático de bloques que ilustra etapas ejecutadas en el método de control del flujo de TCP entre un servidor y un terminal de cliente de equipo de usuario a través de un controlador de red de radiocomunicaciones.
Descripción de forma(s) de realización preferida(s)
La siguiente forma de realización preferida de la presente invención se describirá en el contexto de un sistema de Red de Acceso de Radiocomunicaciones UMTS (UTRAN) que funciona en el modo TDD. En referencia en primer lugar a la FIG. 1, se considera adecuadamente que un sistema convencional de Red de Acceso de Radiocomunicaciones UMTS (UTRAN) 100 comprende: un dominio de equipo terminal/de usuario 110; un dominio de Red de Acceso de Radiocomunicaciones Terrestre UMTS 120; y un dominio de Red Central 130.
En el dominio de equipo terminal/de usuario 110, el equipo terminal (TE) 112 está conectado al equipo móvil (ME) 114 a través de la interfaz R por cable o inalámbrica. El ME 114 está conectado también a un módulo de identidad de servicio de usuario (USIM) 116; el ME 114 y el USIM 116 se consideran conjuntamente como un equipo de usuario (UE) 118. El UE 118 comunica datos con un Nodo B (estación base) 122 en el dominio de red de acceso de radiocomunicaciones 120 a través de la interfaz Uu inalámbrica. Dentro del dominio de red de acceso de radiocomunicaciones 120, el Nodo B 122 se comunica con un controlador de red de radiocomunicaciones (RNC) 124 a través de la interfaz Iub. El RNC 124 se comunica con otros RNC (no mostrados) a través de la interfaz Iur. El Nodo B 122 y el RNC 124 forman conjuntamente la UTRAN 126. El RNC 124 se comunica con un nodo de servicio GPRS de servicio (SGSN) 132 en el dominio de red central 130 a través de la interfaz Iu. Dentro del dominio de red central 130, el SGSN 132 se comunica con un nodo de soporte de pasarela GPRS (GGSN) 134 a través de la interfaz Gn; el SGSN 132 y el GGSN 134 se comunican con un servidor de registro de posiciones base (HLR) 136 a través de la interfaz Gr y la interfaz Gc respectivamente. El GGSN 134 se comunica con una red pública de datos 138 a través de la interfaz Gi.
Así, los elementos RNC 124, SGSN 132 y GGSN 134 se proporcionan convencionalmente como unidades discretas e independientes (en sus propias plataformas respectivas de software/hardware) divididas entre el dominio de red de acceso de radiocomunicaciones 120 y el dominio de red central 130, tal como se muestra en la FIG. 2.
El RNC 124 es el elemento de UTRAN responsable del control y la asignación de recursos para numerosos Nodos B 122; un RNC puede controlar típicamente entre 50 y 100 Nodos B. El RNC proporciona también una entrega fiable de tráfico de usuario a través de las interfaces aéreas. Los RNCs se comunican entre sí (a través de la interfaz Iur) para soportar traspasos y macrodiversidad.
El SGSN 132 es el elemento de Red Central de UMTS responsable del Control de Sesión y la comunicación por interfaz con el HLR. El SGSN mantiene un seguimiento de la ubicación de un UE individual y ejecuta funciones de seguridad y control de acceso. El SGSN es un gran controlador centralizado para muchos RNCs.
El GGSN 134 es el elemento de Red Central de UMTS responsable de concentrar y tunelizar datos de usuario dentro de la red de paquetes central hacia el destino definitivo (por ejemplo, el proveedor de servicios de Internet – ISP).
Se describen más detalladamente un sistema UTRAN de este tipo y su funcionamiento en los documentos 3GPP de especificación técnica 3GPP TS 25.401, 3GPP TS 23.060, y documentos relacionados, disponibles en el sitio web del 3GPP en www.3gpp.org, y los mismos no necesitan ser descritos de forma más detallada en la presente.
En el presente ejemplo, toda la funcionalidad de la invención reside en el RNC 124 aunque alternativamente se puede aplicar en el UE 118.
En referencia ahora a la FIG. 2, tal como se explicará más detalladamente a continuación, con el fin de mejorar el flujo del TCP para la descarga de datos a un UE 118, se produce una modificación 210 de la ventana de TCP en el nivel del portador de radiocomunicaciones, y la misma está ubicada funcionalmente en la arquitectura de protocolos para el plano de usuario (plano U). En el RNC 124, y el Nodo B 122 de la UTRAN 126 la modificación de la ventana de TCP 210 (que se explicará de forma más detallada posteriormente) viene seguida por un procesado de PDCP (Convergencia de Datos por Paquetes) 220, un procesado de RLC (Control de Enlace de Radiocomunicaciones) 230, un procesado de MAC (Control de Acceso al Medio) 240 y un procesado de PHY (Capa Física) 250. Se entenderá que el procesado de PDCP 220, el procesado de RLC 230, el procesado de MAC 240 se realizan de acuerdo con las especificaciones 3GPP técnicas conocidas TS 25 323, TS 25 322 y TS 25 321 respectivamente. El procesado de PHY se describe en especificaciones técnicas 3GPP TS 25 2xx (por ejemplo, 221, 222, 223, 224 y 225 para el TDD). En ningún caso es necesario describir las mismas de forma más detallada en la presente.
La información procesada se comunica a través de la interfaz Uu inalámbrica al UE 118, en donde se realizan un procesado de PHY 260, un procesado de MAC 270, un procesado de RLC 280 y un procesado de PDCP 290 complementarios. Igual que antes, se entenderá que el procesado de PDCP 290, el procesado de RLC 280, el procesado de MAC 270, y el procesado de PHY 260 se realizan de acuerdo con las especificaciones técnicas 3GPP conocidas TS 25 323, TS 25 322 y TS 25 321 respectivamente. El procesado de PHY se describe en las especificaciones técnicas 3GPP TS 25 2xx (por ejemplo, 221, 222, 223, 224 y 225 para el TDD). En ningún caso hay necesidad de describir las mismas de forma más detallada en la presente.
En referencia a continuación también a la FIG. 3, la modificación de la ventana de TCP 210 se basa en las siguientes etapas:
•En 310, cuando se recibe en el RNC 124 un paquete de TCP (302) que transporta datos, desde un servidor
5 140, para su descarga al UE 118, se especifica un retardo de memoria intermedia objetivo y el mismo es conocido, y se realiza una medición del retardo dentro de la memoria intermedia de transmisión del RLC sobre el tráfico de enlace descendente. Se envía un paquete de TCP (304) que transporta datos a través de la interfaz Uu inalámbrica hacia el UE 118.
10 •En 320, en el UE 118 se calcula un valor de “awnd” basándose en la capacidad de la memoria intermedia del receptor del UE y el mismo se coloca en el campo “win” del paquete de ACK (Acuse de Recibo) (306) que se envía de vuelta al RNC 124;
•En 332 a 336, en el RNC 124 se determina un nuevo valor de “awnd” de la manera siguiente: 15
oen 332, un retardo de memoria intermedia de RLC objetivo se resta del retardo de memoria intermedia de RLC medido en la etapa 310,
oen 334, se aplica un multiplicador deseado de la ganancia de bucle de control, y 20 oen 336, se adiciona el valor de “awnd” determinado previamente en el RNC 124.
•En 340, se identifica la siguiente SDU (Unidad de Datos de Servicio) disponible que contiene un paquete ACK de TCP. El valor del campo “win” en el paquete ACK recibido se compara con el valor determinado en
25 la etapa 330. Si el valor determinado en la etapa 330 es menor que el valor de “win” en el paquete ACK recibido, entonces el valor de “win” del paquete se sustituye con el determinado en la etapa 330. No obstante, si el valor determinado en la etapa 330 es mayor que el correspondiente del paquete ACK recibido, no se realiza ningún cambio.
30 •En 350, se vuelve a calcular la suma de comprobación de TCP para tener en cuenta el ACK de TCP modificado.
•En 360, se reconstruye el paquete ACK y se envía al servidor 140 un paquete de TCP (308) con el ACK modificado.
35 No se realizan más cambios en la ventana de TCP hasta que se haya acusado el recibo de todos los datos actuales del sistema (esto se puede medir convenientemente esperando hasta que el número de ACK llegue a la mitad del número actual de SDUs en el sistema cuando la función de ACK con retardo se implementa en la pila de protocolos de TCP).
40 Se apreciará que puesto que los parámetros de retardo de la memoria intermedia de RLC se deben señalizar a través de PDCP, la capa de protocolo PDCP se podría considerar como una ubicación adecuada para que resida esta funcionalidad.
45 Se entenderá que, idealmente, resultaría deseable medir el tiempo de ida y vuelta (RTT) total para un paquete e implementar en consecuencia el control del flujo. No obstante, en la práctica, la medición del RTT basada en la numeración de ACK y SEQ puede resultar difícil puesto que en un momento cualquiera existen típicamente múltiples flujos continuos de TCP. El RTT total está constituido por los componentes mostrados en la siguiente ecuación:
50 RTT = retardo de la memoria intermedia de RLC del emisor + retardo de la interfaz aérea de emisor a receptor + retardo de la memoria intermedia del receptor + retardo de la interfaz aérea del receptor al emisor.
Los inventores de la presente invención han observado que, considerando que el volumen de datos asociados a ACK es bajo en comparación con datos enviados desde el emisor al receptor, el retardo de la memoria intermedia
55 del receptor puede verse afectado por el flujo que controla el emisor. Además, el tiempo consumido a través de la interfaz aérea (aunque es variable debido a retransmisiones, etcétera) también se puede considerar como no afectado por el control de flujo. Por lo tanto, no se necesita monitorizar más que el tiempo que una SDU pasa en la cola de transmisión de RLC.
60 Además, la simple medición del tiempo para atravesar la cola de transmisión de RLC puede ser problemática puesto que, incluso cuando no se añaden SDUs nuevas a la parte posterior de la cola, el tiempo para atravesarla será elevado para la última SDU. Por lo tanto, se usa convenientemente el siguiente método:
1. Para cada SDU en la cola de transmisión de RLC, medir: 65
a.
El tamaño actual de la memoria intermedia en el momento en el que la SDU entra en la cola de transmisión de RLC.
b.
El tiempo que pasa desde el momento en el que una SDU entra en la cola de transmisión
5 de RLC hasta el momento en el que abandona la cola de transmisión (es decir, todas las PDU que constituyen la SDU se han enviado por lo menos una vez).
2. Determinar la media de un número predeterminado de SDU más recientes para las cuales están
disponibles el tamaño de la memoria intermedia y el retardo de la memoria intermedia. 10
3. Si el retardo medio de la memoria intermedia es relativamente similar al retardo objetivo (dentro de un intervalo predeterminado en torno a este último),
Modificar la ventana “awnd” del TCP en una cantidad relacionada con (retardo de la
15 memoria intermedia objetivo - retardo medio de la memoria intermedia) * ganancia de bucle de control como en las etapas 332 a 336 de la FIG. 3. Obsérvese que se puede aplicar una “banda muerta”, centrada en el retardo objetivo deseado, en donde no se realiza ningún ajuste.
20 4. Si el retardo medio de la memoria intermedia es considerablemente mayor que (fuera de un intervalo predeterminado en torno a) el retardo objetivo,
Ajustar la ventana de TCP a la cantidad indicada por el tamaño medio actual de la memoria intermedia menos una magnitud predeterminada.
5.
Cuando se realiza una modificación en el tamaño de la ventana de TCP no se permiten más cambios en el tamaño de la ventana de TCP hasta que este cambio haya tenido efecto.
6.
Se puede configurar una ventana calculada permitida mínima, de manera que el tamaño de la
30 ventana de TCP determinado en las fases 3 y 4 anteriores no pueda situarse por debajo de este valor.
Se apreciará que el proceso para el control del flujo de TCP descrito anteriormente se llevará a cabo de forma típica en software ejecutado sobre un procesador (no mostrado), y que el software se puede proporcionar como un
35 elemento de programa de ordenador incluido en cualquier soporte de datos adecuado (no mostrado), tal como un disco de ordenador magnético u óptico. Se apreciará también que el esquema de control de flujo de TCP descrito anteriormente se puede fabricar de forma alternativa en un circuito integrado para su uso en un terminal o RNC de un sistema de comunicaciones.
40 Se apreciará que, aunque el esquema de control del flujo de TCP se ha escrito anteriormente en el contexto de una transferencia de datos de enlace descendente en un sistema TDD UTRA, la invención no se limita a una aplicación de este tipo y se puede usar en una transferencia de datos de enlace descendente y/o enlace ascendente en sistemas de comunicación en general.
45 Se entenderá que el método y la disposición para el control del flujo de TCP antes descritos proporcionan la ventaja de que se puede garantizar sustancialmente el RTT (es decir, la latencia del sistema), con independencia del caudal que tenga asignado el usuario. En comparación, debería observarse que el uso de una ocupación de memoria intermedia objetivo – como en la publicación antes mencionada de la técnica anterior “I-TCP: indirect TCP for mobile hosts” – no permite que se cumpla la condición anterior puesto que la ocupación de la memoria intermedia varía con
50 el caudal para un RTT dado.

Claims (29)

  1. REIVINDICACIONES
    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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 14.
    Disposición (124) según la reivindicación 13, en la que el sistema de comunicaciones inalámbricas comprende un sistema UTRAN.
  15. 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
    5 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. 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. 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. 18.
    Método según cualquiera de las reivindicaciones anteriores 15 a 17, en el que la modificación del tamaño de
    20 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. 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. 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. 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. 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
    35 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. 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
    40 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. 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. 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. 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. 27. Método según la reivindicación 26, en el que el sistema de comunicaciones inalámbricas comprende un sistema 55 UTRAN.
  28. 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.
    60 29. Circuito integrado, que comprende la disposición (124) según cualquiera de las reivindicaciones anteriores 1 a
  29. 14.
ES04743079T 2003-06-27 2004-06-25 Método y disposición para el control del flujo del TCP Expired - Lifetime ES2397629T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0315009 2003-06-27
GB0315009A GB2403378B (en) 2003-06-27 2003-06-27 Method and arrangement for TCP flow control
PCT/GB2004/002728 WO2005002148A1 (en) 2003-06-27 2004-06-25 Method and arrangement for tcp flow control

Publications (1)

Publication Number Publication Date
ES2397629T3 true ES2397629T3 (es) 2013-03-08

Family

ID=27637460

Family Applications (1)

Application Number Title Priority Date Filing Date
ES04743079T Expired - Lifetime ES2397629T3 (es) 2003-06-27 2004-06-25 Método y disposición para el control del flujo del TCP

Country Status (5)

Country Link
US (2) US7602719B2 (es)
EP (1) EP1642427B1 (es)
ES (1) ES2397629T3 (es)
GB (1) GB2403378B (es)
WO (1) WO2005002148A1 (es)

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7747244B2 (en) 2003-01-23 2010-06-29 Research In Motion Limited Methods and apparatus for re-establishing communication for a wireless communication device after a communication loss in a wireless communication network
WO2005107187A1 (en) * 2004-05-05 2005-11-10 Telefonaktiebolaget Lm Ericsson (Publ) Hsdpa flow control, control frames rtt measurement
US7656800B2 (en) * 2004-07-30 2010-02-02 Cisco Technology, Inc. Transmission control protocol (TCP)
US20060262738A1 (en) * 2005-05-17 2006-11-23 Lilian Fernandes Administering acknowledgment messages in the transmission control protocol
CA2624671C (en) 2005-09-30 2012-01-03 Research In Motion Limited Methods and apparatus for dynamically adjusting a data packet window size for data packet transmission in a wireless communication network
KR101354630B1 (ko) * 2006-03-22 2014-01-22 삼성전자주식회사 이동통신 시스템에서의 타이머 기반의 자원 요청 방법
US7447789B2 (en) * 2006-03-24 2008-11-04 Sun Microsystems, Inc. Method and apparatus for buffering data at a transport layer on a client
GB2440978B (en) * 2006-08-16 2012-01-04 Wireless Tech Solutions Llc Wireless communication system, apparatus for supporting data flow and methods therefor
CN101543112A (zh) 2006-11-28 2009-09-23 艾利森电话股份有限公司 蜂窝电话系统中的增强流控制
EP2103052B1 (en) 2006-12-28 2012-08-22 Research In Motion Limited Methods and apparatus for increasing data throughput by grouping data packets into maximum transmissible units
CN101162971B (zh) * 2007-10-30 2011-09-14 华为技术有限公司 数据传输的方法、设备及系统
US8369221B2 (en) * 2007-11-01 2013-02-05 Telefonaktiebolaget Lm Ericsson (Publ) Efficient flow control in a radio network controller (RNC)
EP2245793B1 (en) * 2008-02-19 2015-05-27 Telefonaktiebolaget L M Ericsson (PUBL) Uplink scheduling in wireless networks
US8015313B2 (en) * 2008-03-04 2011-09-06 Sony Corporation Method and apparatus for managing transmission of TCP data segments
US20100299349A1 (en) * 2009-05-20 2010-11-25 Microsoft Corporation Reducing Latency in Returning Online Search Results
EP2449817B1 (en) * 2009-06-30 2018-08-29 Telefonaktiebolaget LM Ericsson (publ) Method and apparatuses for moving a service or ip session from first to second access
US8774190B2 (en) * 2010-02-08 2014-07-08 Qualcomm Incorporated Enhanced resequencing of data received over a wireless communication system
US8730799B2 (en) 2010-03-03 2014-05-20 Akamai Technologies, Inc. Dynamic adjustment of receive window utilized by a transmitting device
US9019854B2 (en) * 2010-04-26 2015-04-28 Telefonaktiebolaget L M Ericsson (Publ) Method for setting and adjusting a parameter dependent on a round trip time
US8477618B2 (en) 2010-07-16 2013-07-02 Research In Motion Limited Methods and apparatus for use in communicating data packets within a data packet window having a size that is set based on quality of service (QoS) parameters
US10044489B2 (en) 2010-10-22 2018-08-07 Nokia Solutions And Networks Oy Enhanced inter-network access node scheduling coordination and signaling support for advanced receiver algorithms
US8639835B2 (en) * 2010-11-29 2014-01-28 Verizon Patent And Licensing Inc. TCP window size performance optimization in wireless networks
US9007904B2 (en) * 2011-11-17 2015-04-14 International Business Machines Corporation System to improve an ethernet network
IN2014KN01446A (es) * 2011-12-15 2015-10-23 Ericsson Telefon Ab L M
US9380635B2 (en) 2012-01-09 2016-06-28 Google Technology Holdings LLC Dynamic TCP layer optimization for real-time field performance
US20130250853A1 (en) * 2012-03-20 2013-09-26 Qualcomm Incorporated Methods and apparatuses to improve round trip time in transfer control protocol using accelerated acknowledgement messages
US9386128B2 (en) * 2012-03-23 2016-07-05 Qualcomm Incorporated Delay based active queue management for uplink traffic in user equipment
WO2013167647A1 (en) * 2012-05-11 2013-11-14 Nokia Siemens Networks Oy Mechanism for controlling buffer setting in flow control
US8948009B1 (en) 2012-05-15 2015-02-03 Google Inc. Deadline aware network protocol
US20140019591A1 (en) * 2012-07-16 2014-01-16 Nokia Siemens Networks Oy Media Prefill Performance Improvement
US8989008B2 (en) * 2012-10-26 2015-03-24 Verizon Patent And Licensing Inc. Wirespeed TCP packet window field modification for networks having radio segments
GB2527601B (en) * 2014-06-27 2017-02-22 Samsung Electronics Co Ltd Managing a multipath transmission control protocol connection
KR102350504B1 (ko) 2015-04-27 2022-01-14 삼성전자주식회사 통신 시스템에서 하향링크 전송률 제어를 위한 장치 및 방법
KR102298991B1 (ko) * 2015-05-22 2021-09-07 삼성전자 주식회사 무선 통신 시스템에서 버퍼 관리 방법 및 장치
CN105227482B (zh) * 2015-09-07 2018-07-10 北京百度网讯科技有限公司 基于tcp连接的限速方法和装置
US10004019B2 (en) 2015-09-08 2018-06-19 Parallel Wireless, Inc. RAN for multimedia delivery
US9967077B2 (en) 2015-10-22 2018-05-08 Harris Corporation Communications device serving as transmission control protocol (TCP) proxy
US20170310601A1 (en) * 2016-04-21 2017-10-26 Qualcomm Incorporated Radio-aware transmission control protocol rate control
CN108156089A (zh) * 2018-02-09 2018-06-12 福州大学 一种多租户数据中心中基于时限敏感的虚拟拥塞控制方法
US10824369B2 (en) * 2018-07-31 2020-11-03 Nutanix, Inc. Elastic method of remote direct memory access memory advertisement
US11012361B2 (en) 2019-08-29 2021-05-18 Hughes Network Systems, Llc Managing transmission control protocol (TCP) traffic
US11234159B2 (en) * 2019-10-04 2022-01-25 Verizon Patent And Licensing Inc. Systems and methods for congestion control on mobile edge networks

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0697125B2 (ja) * 1987-07-17 1994-11-30 三菱電機株式会社 マルチ冷凍サイクルの周波数制御装置
US5748901A (en) * 1996-05-21 1998-05-05 Ramot University Authority Ltd. Flow control algorithm for high speed networks
JPH1023064A (ja) 1996-07-01 1998-01-23 Nippon Telegr & Teleph Corp <Ntt> 自律分散型トラヒックフロー制御法
US6310857B1 (en) * 1997-06-16 2001-10-30 At&T Corp. Method and apparatus for smoothing and multiplexing video data flows
US6370114B1 (en) 1997-12-31 2002-04-09 Nortel Networks Limited Apparatus and method for optimizing congestion control information in a multi-protocol network
JP3315926B2 (ja) * 1998-05-25 2002-08-19 ケイディーディーアイ株式会社 Ｔｃｐ通信高速化装置
KR100296077B1 (ko) 1999-05-14 2001-07-12 이계철 비동기전송모드(ａｔｍ) 망에서 전송제어프로토콜(ｔｃｐ) 윈도우 사이즈 제어 방법
US6965943B1 (en) * 1999-06-05 2005-11-15 Lucent Technologies Inc. End-to-end internet control
US6831912B1 (en) 2000-03-09 2004-12-14 Raytheon Company Effective protocol for high-rate, long-latency, asymmetric, and bit-error prone data links
US6772375B1 (en) * 2000-12-22 2004-08-03 Network Appliance, Inc. Auto-detection of limiting factors in a TCP connection
GB0031535D0 (en) * 2000-12-22 2001-02-07 Nokia Networks Oy Traffic congestion
US6901593B2 (en) 2001-05-08 2005-05-31 Nortel Networks Limited Active queue management with flow proportional buffering
US6973030B2 (en) 2001-06-20 2005-12-06 Motorola, Inc. Method and apparatus for controlling multiple logical data flow in a variable data rate environment
WO2003049354A1 (en) 2001-12-04 2003-06-12 Nokia Corporation Method and system for dispatching multiple tcp packets from communication systems
US7343619B2 (en) 2002-03-16 2008-03-11 Trustedflow Systems, Inc. Trusted flow and operation control method
GB0215013D0 (en) * 2002-06-28 2002-08-07 Nokia Corp Communications system and method
US20040015591A1 (en) * 2002-07-18 2004-01-22 Wang Frank Xiao-Dong Collective TCP control for improved wireless network performance
US7542471B2 (en) 2002-10-30 2009-06-02 Citrix Systems, Inc. Method of determining path maximum transmission unit
US8004981B2 (en) * 2003-06-17 2011-08-23 Cisco Technology, Inc. Methods and devices for the coordination of flow control between a TCP/IP network and other networks
US20070081561A1 (en) * 2005-10-11 2007-04-12 International Business Machines Corporation Single ended solution for estimation of bandwidth delay product
US7817556B2 (en) * 2006-04-20 2010-10-19 Cisco Technology, Inc. Modification of policing methods to make them more TCP-friendly
US8125904B2 (en) 2006-05-30 2012-02-28 Broadcom Corporation Method and system for adaptive queue and buffer control based on monitoring and active congestion avoidance in a packet network switch

Also Published As

Publication number Publication date
GB2403378A (en) 2004-12-29
US7602719B2 (en) 2009-10-13
WO2005002148A1 (en) 2005-01-06
EP1642427B1 (en) 2012-11-28
GB0315009D0 (en) 2003-07-30
EP1642427A1 (en) 2006-04-05
GB2403378B (en) 2007-05-30
USRE44715E1 (en) 2014-01-21
US20060268708A1 (en) 2006-11-30

Similar Documents

Publication Publication Date Title
ES2397629T3 (es) Método y disposición para el control del flujo del TCP
EP3100420B1 (en) Buffer sizing for multi-hop networks
ES2318105T3 (es) Disposiciones y metodo para controlar la transmision de bites de datos.
US6961349B2 (en) Handling TCP protocol for connections transmitted in parallel over radio link
ES2402828T3 (es) Establecimiento de prioridades de acuses de recibo en redes inalámbricas
US9124547B2 (en) System and method for enforcing uplink wireless medium usage in wireless networks
KR20190095487A (ko) 패킷 전송 방법, 단말, 네트워크 디바이스 및 통신 시스템
US20140140209A1 (en) Buffer sizing for multi-hop networks
US9407734B2 (en) System and method for efficient frame aggregation based on aggregation limits or parameters
WO2016068308A1 (ja) ゲートウェイ装置及びゲートウェイ装置の制御方法
WO2005088917A1 (ja) 制御局装置、基地局装置、端末装置、パケット通信システム及びパケット通信方法
US20060291435A1 (en) Connection-oriented data transfer over wireless transmission paths
US20070223492A1 (en) Methods and apparatus for optimizing a TCP session for a wireless network
TWI825132B (zh) 用於多連接的方法
Abed et al. Comparative performance investigation of TCP and SCTP protocols over LTE/LTE-advanced systems
US8351328B2 (en) Method and device for transmitting TCP data over asymmetric links
US10439945B2 (en) Single stream aggregation protocol
Mathis Relentless congestion control
EP2890179B1 (en) Method, apparatus and computer program for data transfer
Xylomenos et al. Adaptive timeout policies for wireless links
CN101321120A (zh) 流媒体业务信道迁移方法及装置
Santhappan et al. Visible: Virtual congestion control with boost acks for packet level steering in lwip networks
Kharat Prashant Modified QUIC Protocol with Congestion Control for Improved Network Performance
JP2014220612A (ja) 無線基地局及び移動通信方法
Pawar et al. A Review on TCP Protocol on LTE Network