ES2221473T3 - Metodo y dispositivo de comunicacion. - Google Patents
Metodo y dispositivo de comunicacion.Info
- Publication number
- ES2221473T3 ES2221473T3 ES99965583T ES99965583T ES2221473T3 ES 2221473 T3 ES2221473 T3 ES 2221473T3 ES 99965583 T ES99965583 T ES 99965583T ES 99965583 T ES99965583 T ES 99965583T ES 2221473 T3 ES2221473 T3 ES 2221473T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- unit
- acknowledgment
- given
- sender
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 71
- 238000004891 communication Methods 0.000 title claims abstract description 36
- 230000007246 mechanism Effects 0.000 claims abstract description 40
- 230000004044 response Effects 0.000 claims abstract description 36
- 238000001514 detection method Methods 0.000 claims abstract description 31
- 230000006978 adaptation Effects 0.000 claims abstract description 26
- 230000001960 triggered effect Effects 0.000 claims abstract description 9
- 230000005540 biological transmission Effects 0.000 claims description 32
- 238000005259 measurement Methods 0.000 claims description 5
- 230000003111 delayed effect Effects 0.000 claims description 4
- 238000010304 firing Methods 0.000 claims description 2
- 230000001934 delay Effects 0.000 description 4
- 238000006243 chemical reaction Methods 0.000 description 3
- 230000009118 appropriate response Effects 0.000 description 2
- 230000001186 cumulative effect Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 238000012384 transportation and delivery Methods 0.000 description 2
- 101100421144 Danio rerio selenoo1 gene Proteins 0.000 description 1
- 101100202896 Mus musculus Selenoo gene Proteins 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000005316 response function Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
- H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
- H04Q11/0478—Provisions for broadband connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1628—List acknowledgements, i.e. the acknowledgement message consisting of a list of identifiers, e.g. of sequence numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1635—Cumulative acknowledgement, i.e. the acknowledgement message applying to all previous messages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1803—Stop-and-wait protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1809—Selective-repeat protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1835—Buffer management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1858—Transmission or retransmission of more than one copy of acknowledgement message
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/187—Details of sliding window management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/188—Time-out mechanisms
-
- 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]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- 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
- 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/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
-
- 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/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0002—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5646—Cell characteristics, e.g. loss, delay, jitter, sequence integrity
- H04L2012/5647—Cell loss
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5646—Cell characteristics, e.g. loss, delay, jitter, sequence integrity
- H04L2012/5649—Cell delay or jitter
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Abstract
Un método para controlar una comunicación orientada en unidades de datos entre un remitente y un receptor de acuerdo con un protocolo de comunicación predeterminado, donde dicho remitente divide una cantidad de datos a ser enviados en una o más unidades de datos que tienen una estructura determinada por dicho protocolo, dicho receptor acusa recibo de la correcta recepción de las unidades de datos, devolviendo para ello unidades de datos de acuse de recibo a dicho remitente, dichas unidades de datos son enviadas por dicho remitente de acuerdo con un procedimiento de control del flujo conducido sobre la base de uno o más parámetros de adaptación y dichas unidades de datos de acuse de recibo, y dicho procedimiento de control del flujo comprende un mecanismo de detección de pérdida de datos capaz de detectar pérdida de datos en dicha comunicación, siendo disparado dicho mecanismo de detección de pérdida de datos para indicar la pérdida potencial de datos por uno o más acontecimientos predeterminados, donde en respuesta al disparo de dicho mecanismo de detección de pérdida de datos se lleva a cabo un procedimiento de respuesta correspondiente (S1, S2, S3, S4, S5, S6, S7), el cual comprende la retransmisión (S3) de una unidad de datos dada, caracterizado porque dicho procedimiento de respuesta (S1, S2, S3, S4, S5, S6, S7) comprende al menos dos modos diferentes (S6, S7) para adaptar dichos uno o más parámetros de adaptación, y comprende una decisión (S5) sobre cuál de dichos al menos dos modos (S6, S7) elegir para adaptar dichos parámetros de adaptación, efectuándose dicha decisión (S5) sobre la base de una o más unidades de datos de acuse de recibo recibidas por dicho remitente después de haber retransmitido dicha unidad de datos dada.
Description
Método y dispositivo de comunicación.
Este presente invento se refiere a un dispositivo
y un método de comunicación, en donde se efectúa una comunicación
orientada en unidades de datos entre un remitente y un receptor,
operando dicho remitente y dicho receptor de acuerdo con un
protocolo de comunicación predeterminado.
La comunicación orientada en unidades de datos es
bien conocida. En la comunicación orientada en unidades de datos se
divide una cantidad de datos en una o más unidades de datos, donde
la estructura de las unidades de datos está definida por un
protocolo de comunicación al cual se adhieren el remitente y el
receptor en la comunicación. El protocolo define también cómo ha de
ser codificada la información específica, y cómo pueden reaccionar
el remitente y/o el receptor a información específica. La
comunicación orientada en unidades de datos es también conocida como
comunicación de intercambio de paquetes. Es de hacer notar que las
unidades de datos usadas en relación con protocolos específicos
tienen diferentes nombre, tales como paquetes, cuadros, segmentos,
etc. Para los fines de la presente descripción, la expresión
"unidad de datos" se referirá genéricamente a todo tipo de
unidades usadas en la comunicación orientada en unidades de
datos.
Una característica que se usa en muchos
protocolos de comunicación para aumentar la fiabilidad es la del
acuse de recibo de los datos recibidos. Más concretamente, un
remitente o examinador de remisión del protocolo dado envía unidades
de datos, y el receptor o examinador de recepción del protocolo dado
acusa recibo de la recepción correcta, devolviendo para ello
unidades de datos de acuse de recibo apropiadas. De este modo, el
examinador de remisión es informado de que las unidades de datos que
fueron enviadas fueron también correctamente recibidas, y puede
ajustar en consecuencia el control del flujo de las demás unidades
de datos a ser enviadas. Un ejemplo de protocolo en el que se usa
acuse de recibo de las unidades de datos es el denominado protocolo
de control de transmisión (TCP), el cual es una parte de las series
de protocolos TCP/IP.
El protocolo de control de transmisión y la serie
de protocolos TCP/IP se han descrito bien en, por ejemplo, el texto
titulado "TCP/IP Illustrated", Volumen 1 - "The
Protocols", de W. Richard Stevens,
Addison-Wesley, 1994.
Con objeto de hacer frente al hecho de que se
pueden perder unidades de datos o acuses de recibo de unidades de
datos, en muchos protocolos se proporciona una característica de
retraso. Tal característica de retraso significa que se establece un
período de retraso cuando se envían los datos, y si no se ha acusado
recibo de los datos específicos para el momento en que expire el
período de retraso, se inicia un procedimiento de respuesta de
retraso. En el protocolo TCP, la respuesta de retraso consiste en
retransmitir los datos de los que no se haya acusado recibo, y
restablecer uno o más parámetros de control del flujo.
Como un ejemplo, en el protocolo TCP se hace uso
de un control del flujo basado en la ventana. El TCP es un protocolo
orientado en octetos que divide un número dado de octetos a ser
enviados en los denominados segmentos, y se mantiene un registro de
los datos enviados en términos de octetos, es decir, hasta cuál de
los octetos fueron enviados los datos, y se mantiene también un
registro de los datos recibidos en términos de octetos, es decir,
hasta qué octetos fueron recibidos los datos. El modo más simple de
controlar el flujo de segmentos en relación con el acuse de recibo
de mensajes sería enviar un segmento y no enviar el segmento
siguiente hasta que se hubiese acusado recibo del último segmento
enviado. Tal método de control del flujo no sería sin embargo muy
eficiente. Como ya se ha mencionado, en el protocolo TCP se hace uso
del control del flujo basado en ventana, al cual se le denomina
también como un control del flujo de acuerdo con ventanas
deslizantes. Este concepto está también bien descrito en el texto
antes citado de W. Richard Stevens.
En la Fig. 2 se ha ilustrado el concepto de
ventanas deslizantes. Como puede verse, se ha de enviar una cantidad
de 8.192 octetos en el ejemplo, donde esta cantidad se divide en
segmentos. la remisión de segmentos se controla de acuerdo con la
ventana de envío, donde el extremo de la izquierda de la ventana de
envío está definido por los datos contenidos en los segmentos que
han sido enviados y de los que ya se ha acusado recibo. En el
ejemplo de la Fig. 2, estos son los datos hasta los 2.048 octetos,
es decir, los segmentos 1 y 2. El ajuste de la longitud de la
ventana de enviar, y por lo tanto del extremo de la derecha de la
ventana, es cuestión del procedimiento de control, lo que no es
necesario explicar aquí con detalle.
La ventana de enviar define la cantidad de datos
que pueden tener pendiente su correspondiente acuse de recibo. En el
ejemplo de la Fig. 2, los datos hasta los 4.96 octetos, es decir,
los segmentos 3 y 4, han sido enviados y todavía no se ha acusado
recibo de los mismos, y la diferencia entre tales segmentos enviados
y de los que no se ha acusado recibo y el extremo de la derecha de
la ventana de enviar, define la ventana utilizable, es decir, los
datos que todavía pueden ser enviados sin que se haya recibido
ningún otro acuse de recibo. En consecuencia, en el ejemplo de la
Fig. 2 se pueden seguir enviando todavía los segmentos 5 y 6, pero
los segmentos 7 y 8 solamente pueden ser enviados si se mueve la
ventana hacia la derecha, lo cual ocurre si se acusa recibo de otro
segmento, de tal modo que el extremo de la izquierda se mueve hacia
la derecha y/o se aumenta la longitud de la ventana de enviar.
Además, es de hacer notar que el protocolo TCP
proporciona acuses de recibo acumulativos, es decir, que no existe
una correspondencia de uno a uno entre los segmentos y los acuses de
recibo para los segmentos, puesto que un mensaje de acuse de recibo
puede cubrir una pluralidad de segmentos. Como ejemplo, el
examinador de recepción para la cantidad de datos ilustrados en la
Fig. 2 podría enviar un acuse de recibo de los octetos hasta el
4.96, de tal modo que ese mensaje de acuse de recibo cubriría ambos
segmentos, el 3 y el 4.
La ventana de enviar usada por el examinador de
remisión estará típicamente determinada por la denominada ventana
ofrecida o anunciada, la cual es una longitud de datos
proporcionados al examinador de remisión por el examinador de
recepción. De este modo, el examinador de recepción puede influir
sobre cuantos segmentos enviará el examinador de remisión de una
vez, y típicamente la ventana anunciada será calculada sobre la base
del almacenamiento de recepción del examinador de recepción. Además,
la ventana anunciada es un parámetro dinámico que puede ser cambiado
con cada acuse de recibo enviado por el examinador de recepción.
Más allá de la ventana anunciada, es también
conocido definir la denominada ventana de congestión, la cual se usa
en relación con varias rutinas de control de congestión, tales como
la de arranque lento, evitación de la congestión, retransmisión
rápida y recuperación rápida, véase también, por ejemplo, el texto
antes mencionado de W. Richard Stevens. La ventana de congestión es
un registro que mantiene el examinador de remisión, y está destinada
a tomar en consideración la congestión a lo largo de la conexión
entre el examinador de remisión y el examinador de recepción. Como
mecanismo de control típico, se definirá la ventana de remisión como
la menor de entre la ventana anunciada y la ventana de
congestión.
Mientras que la ventana anunciada es un control
del flujo impuesto por el examinador de recepción, la ventana de
congestión es un control del flujo impuesto por el examinador de
remisión, como un mecanismo para tener en cuenta la congestión.
En un sentido general, la ventana de congestión
es un ejemplo de un parámetro de control del flujo de adaptación. En
el protocolo TCP la respuesta de retraso antes mencionada consiste
en restablecer la ventana de congestión a un segmento y luego enviar
por consiguiente solamente un segmento, es decir, retransmitir el
segmento del que no hubo acuse de recibo y que por ello originó el
retraso. El examinador de remisión espera entonces el acuse de
recibo de dicho segmento retransmitido.
Otro ejemplo de un parámetro de control del flujo
de adaptación es el propio período de retraso, el cual, por ejemplo
en el protocolo TCP, se denomina RTO (Retransmisión del Retraso). El
RTO se duplica como respuesta a un retraso.
Como se ha mencionado ya, la característica de
retraso es un mecanismo de detección de pérdida de datos. Existen
otros mecanismos de detección de pérdida de datos. Otro ejemplo es
el de la retransmisión de unidades de datos en el protocolo TCP en
respuesta a la detección de acuses de recibo duplicados. Este
mecanismo se explicará brevemente en lo que sigue.
Como se ha mencionado ya (véase, por ejemplo, la
Fig. 2), una cantidad de datos a ser enviados se divide en una
secuencia. Las ejecuciones usuales del protocolo TCP se disponen de
tal modo que si el examinador de recepción ha recibido y acusado
recibo de una cierta cantidad de datos hasta un octeto dado (un
cierto número de segmentos consecutivos), el mismo espera los datos
que están a continuación en la secuencia. Por ejemplo, si han sido
recibidos los segmentos hasta el segmento 4, entonces se acusa
recibo del segmento 4 y el examinador de recepción espera recibir el
segmento 5. Si el mismo recibe entonces otra unidad de datos que sea
diferente al segmento 5 (por ejemplo, los segmentos 6, 7 y 8),
continúa acusando recibo del segmento 4 para cada unidad de datos
que recibe. Como consecuencia, el examinador de remisión recibe
acuses de recibo duplicados. Corrientemente, el protocolo de TCP se
ejecuta de tal modo que el examinador de remisión contará el número
de acuses de recibo duplicados, y si se alcanza un cierto valor
umbral (por ejemplo, de 3), entonces la unidad de datos siguiente en
la secuencia a la unidad de datos para la cual fueron recibidos los
acuses de recibo duplicados se retransmite.
En el documento WO 98/37670 se describe un método
para mejorar las actuaciones del protocolo de transporte en redes
que tienen enlaces con pérdidas. Se dice que los remitentes usuales
en una comunicación identifican que se ha perdido un paquete debido
a la congestión ya sea por la llegada de acuses de recibo duplicados
o ya sea por la ausencia de un acuse de recibo dentro de un
intervalo de retraso. Como reacción a la congestión, se llevan a
cabo esquemas de control apropiados en el remitente, tales como de
arranque lento, de recuperación rápida, y de retransmisión rápida.
En el documento WO 98/37670 se llega a señalar que cuando hay fallos
en la recepción de paquetes transmitidos por razones que no sean la
de la congestión, las medidas de compensación por congestión pueden
ser perjudiciales.
En el documento WO 98/37670 se sugiere el uso de
acuses de recibo selectivos que indican qué paquetes fueron
recibidos satisfactoriamente y cuáles fueron recibidos con errores
de bits no debidos a la congestión, mientras que se suprimen los
acuses de recibo duplicados para evitar que se invoque un mecanismo
de congestión.
En el artículo titulado "A comparison of
Mechanisms for Improving TCP Performance over Wireless Links"
(Comparación de Mecanismos para Mejorar las actuaciones del
Protocolo TCP por Enlaces Inalámbricos``) de H. Balakrishnan y
otros, publicado en las "IEEE/ACM Transactions on Networking",
Vol. 5, Nº 6, 12/1997, XP-000734405, se describe un
esquema similar al del documento WO 98/37670. Además de acuses de
recibo selectivos, en este artículo se menciona también la
notificación explícita de pérdida (ELN).
El objeto del presente invento es mejorar la
comunicación en un sistema en el que se use un protocolo de
comunicación que especifique el acuse de recibo de datos enviados y
que especifique una función de detección de pérdida de datos, tal
como una función de retraso o una función de respuesta a acuse de
recibo duplicado.
Este objeto se consigue por un método tal como el
descrito en la reivindicación 1, y mediante un dispositivo como el
descrito en la reivindicación 27. En las reivindicaciones
subordinadas se describen realizaciones ventajosas.
De acuerdo con el presente invento, un remitente
en una comunicación llevará a cabo un procedimiento de respuesta en
respuesta a un acontecimiento que dispare un mecanismo de detección
de pérdida de datos, donde el procedimiento de respuesta comprende
al menos dos modos diferentes para adaptar los parámetros de
adaptación usados en un control del flujo. De este modo, el método y
el dispositivo del presente invento son sumamente flexibles en su
gestión de acontecimientos de disparo, y pueden ser ejecutados
especialmente de tal modo que se pueda elegir el procedimiento de
respuesta dependiendo de varias causas potenciales del
acontecimiento de disparo, de tal manera que se puedan invocar
medidas de respuesta correcta para una situación dada, y por
consiguiente se puedan evitar medidas que pudieran realmente agravar
situaciones que pueden producirse después de que haya sido disparado
un mecanismo de detección de pérdida de datos.
El mecanismo de detección de pérdida de datos es
un mecanismo que es capaz de detectar una pérdida de datos. Son
ejemplos un mecanismo de retraso o un mecanismo de acuse de recibo
duplicado. Naturalmente, el invento puede ser aplicado a cualquier
mecanismo de detección de pérdida de datos adecuado.
De acuerdo con el presente invento, un
procedimiento de respuesta comprende al menos dos modos diferentes
de adaptar los parámetros de adaptación usados en el control del
flujo. Como ejemplo, que constituye una realización preferida, hay
dos modos, los cuales están asociados, respectivamente, a diferentes
causas de un retraso o a un número predeterminados de acuses de
recibo duplicados (por ejemplo, los 3 antes mencionados). Más
concretamente, un primer modo está asociado con la pérdida de una
unidad de datos, y el segundo modo está asociado con un retardo
excesivo a lo largo de la conexión. Debido al uso de dos modos
diferentes, es posible adaptar los parámetros como sea apropiado
para la causa del retraso o de los acuses de recibo duplicados. En
consecuencia, el procedimiento de control del flujo contendrá uno o
más pasos de evaluación y juicio, en los cuales se cualifica el
acontecimiento de disparo, por ejemplo, se lleva a cabo una
categorización respecto a qué fue lo que originó el acontecimiento.
Luego, dependiendo del resultado de esta caracterización, se puede
capacitar un procedimiento de respuesta apropiado. En el contexto
del anterior ejemplo, si se determina que el retraso o los acuses de
recibo duplicados son originados por la prioridad de una unidad de
datos, entonces se puede poner en funcionamiento el procedimiento de
respuesta conocido para la pérdida de unidades de datos. Como es
conocido, por ejemplo del TCP usual, el cual asume que cualquier
retraso o la recepción de varios acuses de recibo duplicados, se
originan por la pérdida de una unidad de datos. De acuerdo con la
presente realización, hay sin embargo un segundo modo, y si se
determina que el retraso, o los acuses de recibo duplicados, son
originados por un retardo excesivo a lo largo de la conexión, se
lleva a cabo entonces un procedimiento de respuesta de retardo
excesivo, el cual será típicamente diferentes del procedimiento de
respuesta para la pérdida de una unidad de datos.
Más concretamente, como también se explicará con
más detalle en lo que sigue, el juicio de que se han perdido
unidades de datos será respondido reduciendo el ritmo de transmisión
para evitar con ello una mayor congestión. Por otra parte, si hay un
retardo excesivo a lo largo de la conexión, entonces las medidas que
se adopten en respuesta a una supuesta pérdida de datos no serían
útiles, y más bien podrían realmente agravar el problema que originó
el retardo excesivo. Por consiguiente, el procedimiento de respuesta
para un retardo excesivo será típicamente diferente, y por ejemplo
comprenderá mantener el ritmo de transmisión al nivel anterior, pero
aumentar por otra parte el período de retraso, de tal modo que se
eviten retransmisiones adicionales innecesarias.
Naturalmente, el presente invento puede ser
puesto en práctica proporcionando un número arbitrario de modos o
procedimientos de respuesta para las diversas causas de
acontecimientos de disparo. El número de modos y el de medidas
específicas tomadas en cada modo dependen naturalmente de la
situación específica, es decir, del protocolo elegido, de la
situación de comunicación dada, etc.
Un aspecto importante del presente invento es el
de que aunque el mecanismo de detección de pérdida de datos sea
capaz de detectar la pérdida de datos, la reacción al disparo del
mecanismo de detección de pérdida de datos no asume que
necesariamente se haya producido una pérdida de datos, sino que es
más bien posible una respuesta flexible, la cual puede tomar en
consideración varias causas del acontecimiento de disparo.
Otros aspectos y ventajas del presente invento se
comprenderán mejor a la vista de la descripción detallada que sigue,
en la cual se hace referencia a las figuras, en las cuales:
La Fig. 1 representa una realización preferida
del procedimiento de control de acuerdo con el presente invento;
La Fig. 2 es un diagrama explicativo para
describir el concepto de control del flujo basado en ventana;
La Fig. 3 es un gráfico para explicar las
ventajas del presente invento; y
La Fig. 4 es un diagrama explicativo para
ilustrar una situación en la cual se puede originar un retardo
excesivo en una conexión entre ordenadores principales.
Aunque la descripción que sigue estará orientada
en general hacia cualquier protocolo de comunicación en el que se
haga uso de acuse de recibo de datos y que proporcione también una
característica de retraso, se darán frecuentemente ejemplos que se
refieran al protocolo de control de la transmisión (TCP) conocido de
la serie de protocolos TCP/IP. La aplicación del presente invento a
este protocolo es una realización preferida. A fin de evitar toda
repetición innecesaria, la exposición hecha en la introducción de
esta solicitud se incorpora a la exposición del invento.
En la Fig. 1 se ha ilustrado un diagrama de flujo
parcial de una realización preferida del presente invento. Como
puede verse, en el paso S1 se indica que se entra en un
procedimiento de respuesta. En la Fig. 1 no se muestra el
procedimiento del control del flujo que conduce a ese punto, ya que
no tiene importancia para el presente invento. Por ejemplo, éste
puede ser un procedimiento de control del flujo basado en ventana
explicado en relación con la Fig. 2 y por ejemplo bien conocido del
PCT. Únicamente es importante para el invento que hay una
característica de acuse de recibo de datos y una característica de
detección de pérdida de datos, de tal modo que un examinador de
remisión del protocolo tiene la capacidad de detectar una posible o
potencial pérdida de datos, y puede llevar a cabo un procedimiento
de respuesta correspondiente. Como ya se ha mencionado, la
característica de detección de pérdida de datos puede ser, por
ejemplo, una característica de retraso, o bien una característica de
detección de acuse de recibo duplicado.
En el ejemplo de la Fig. 1, después de que se
haya entrado en el procedimiento de respuesta, los parámetros de
adaptación seleccionados que se usan para el control del flujo son
almacenados y luego restablecidos para valores predeterminados, en
el paso S2. Como ejemplo, el período de retraso y/o la ventana de
congestión antes descritos son tales parámetros de control del flujo
de adaptación. En un TCP usual, la ventana de congestión es
típicamente restablecida a un valor de un segmento, y al mismo
tiempo se duplica el RTO. Es de hacer notar que no todos los
parámetros de adaptación usados en el procedimiento de control del
flujo necesitan ser de hecho cambiados, sino más bien sólo un número
seleccionado de ellos.
También deberá quedar claro que el presente
invento no está naturalmente limitado al control del flujo basado en
la ventana y a los parámetros de adaptación asociados, sino que más
bien el invento es aplicable a cualquier principio de control del
flujo y a los parámetros de adaptación asociados.
Volviendo a la Fig. 1, la unidad de datos que
disparó el acontecimiento (por ejemplo, que originó un retraso) es
retransmitida en el paso S3. En otras palabras, cuando se permanece
con el ejemplo de un retraso, la unidad de datos para la cual no fue
recibido acuse de recibo durante ese período de retraso es
retransmitida. Luego, en un punto posterior, se determina en el paso
S4 si se ha recibido un acuse de recibo asociado con la unidad de
datos retransmitida. Éste puede ser un acuse de recibo acumulativo,
o bien un acuse de recibo simple. Puede observarse que las líneas de
trazos de la Fig. 1 indican que puede haber interpuestos otros
pasos, pero que éstos carecen de importancia para el presente
invento. Por consiguiente, de acuerdo con el ejemplo preferido de la
Fig. 1, en el paso S5 se determina si el acuse de recibo asociado
con la unidad de datos que fue retransmitida acusa de hecho recibo
de la transmisión original de la unidad de datos o de su
retransmisión. Es de hacer notar que la "transmisión original"
puede ser ya una retransmisión, de tal modo que la
"retransmisión" puede ser una retransmisión de una
retransmisión, etc. Hay varias posibilidades de poner en práctica el
paso S5, como se explicará con más detalle.
Si en el paso S5 se determina que el mensaje de
acuse de recibo de hecho acusa recibo de la retransmisión de la
unidad de datos, entonces el procedimiento pasa al paso S7, en el
cual se lleva a cabo un procedimiento de respuesta a la pérdida de
la unidad de datos, dado que el resultado negativo del paso de
decisión S5 indica que la transmisión original de la unidad de datos
se había perdido. En el ejemplo del TCP, el paso S7 consistirá en
las medidas usuales contra la pérdida de la unidad de datos.
Por el contrario, si en el paso de decisión S5 se
responde en sentido afirmativo, entonces el procedimiento pasa al
paso S6, en el cual se hace correr un procedimiento de respuesta que
responde a un retardo excesivo. En otras palabras, puesto que el
paso S5 indicó que de hecho la transmisión original de la unidad de
datos no se había perdido, que solamente se había retardado
excesivamente, se deben tomar las correspondientes medidas. Por
ejemplo, cuando se toma el TCP como un ejemplo de parámetro, éstas
pueden consistir en hacer retornar la ventana de congestión al valor
almacenado en el paso S2 t adaptar por otra parte el período de
retraso al retardo. En otras palabras, se puede usar el tiempo de
ida y vuelta, RTP, asociado con la transmisión original y con el
acuse de recibo de la transmisión original, como base para adaptar
el período de retraso. Se pueden con ello evitar otras
retransmisiones y retrasos innecesarios o acuses de recibo
duplicados debidos a un retardo excesivo.
Preferiblemente, la ventana de congestión no es
simplemente restablecida al valor anterior, sino que más bien es
establecida en el valor que habría adoptado si no hubiese tenido
lugar el procedimiento de respuesta, es decir, si no hubiese sido
disparado el mecanismo de detección de pérdida de datos.
Como puede verse, el ejemplo de la Fig. 1 muestra
un primer modo consistente en los pasos S2, S3, S4, S5 y S7, así
como un segundo modo consistente en los pasos S2, S3, S4, S5 y
S6.
A fin de explicar mejor el presente invento, se
hará ahora referencia a la Fig. 3, en la cual se muestra un ejemplo
de un procedimiento de control del flujo llevado a cabo en relación
con el TCP usual. En el gráfico se muestran la cantidad de datos en
octetos transportados en el transcurso del tiempo. Como puede verse,
los dos primeros segmentos son enviados en el tiempo t = 4s. Luego,
debido a la interacción de las unidades de datos de acuse de recibo
de recepción y al ajuste de los parámetros de adaptación, no
representados, se envían los segmentos.
Para que sirva de explicación, es de hacer notar
que los símbolos de forma de rombo se refieren a segmentos, y los
símbolos cuadrados a unidades de datos de acuse de recibo. Los
símbolos de rombos indican el primer octeto del segmento, mientras
que los cuadrados indican el octeto más bajo del que no se ha
acusado recibo. Las unidades de datos de acuse de recibo indicadas
en un cierto nivel de segmento acusan recibo siempre de los
segmentos enviados hasta ese nivel de segmento. En otras palabras,
el acuse de recibo a un nivel de segmento de 6.400 octetos (t = 12s)
acusa recibo de los segmentos por debajo del octeto 6.400, pero sin
incluir el octeto 6.400. Por el contrario, como se ha indicado
explícitamente en el gráfico, el segmento para el octeto 6.400 (t =
10s) es una unidad de datos o un paquete que origina un retraso.
Como consecuencia, se lleva a cabo una retransmisión de dicha unidad
de datos al nivel del octeto 6.400.
Ahora, si se supone que el retraso representado
en la Fig. 3 fue originado por un retardo excesivo y no porque se
hubiera perdido el primer paquete representado, entonces la
retransmisión tiene las siguientes consecuencias negativas.
Por una parte, conduce a unas actuaciones de
producción disminuidas, ya que los mismos datos han de recorrer dos
veces el camino de conexión o para conectar, con lo cual se
desperdician anchuras de banda que podrían en otro caso haber sido
usadas para datos útiles. Esta consecuencia negativa se producirá en
cualquier parámetro que responda falsamente a un retraso mediante la
retransmisión de la unidad de datos.
Si, como se ha ilustrado en la Fig. 3, se usa el
parámetro de TCP, entonces la reacción del examinador de remisión a
tal retraso no originado por la pérdida de unidad de datos es
particularmente desventajosa; el remitente retransmitirá todos los
paquetes pendientes y por encima de eso reduce su ritmo de
transmisión. Esto se ha representado explícitamente en la Fig.
3.
Puede observarse que el retraso antes descrito,
no originado por pérdida de unidad de datos, se denomina también
retraso espúreo.
Como también se ha ilustrado en la Fig. 3, en el
TCP usual el remitente malinterpreta todos los acuses de recibo
asociados con las unidades de datos retransmitidas como acuses de
recibo de la retransmisión, incluso aunque esos acuses de recibo
(ACKs) sean de hecho acuse de recibo retrasados de las transmisiones
originales.
Lo que en la Fig. 3 no se presenta, es que además
las unidades de datos duplicadas enviadas por el examinador de
remisión dispararán acuses de recibo duplicados en el examinador de
recepción, lo cual conducirá a todavía otra reducción del ritmo de
transmisión del remitente de TCP usual, a saber, que la ventana de
congestión se establece en la mitad de su valor anterior.
La existencia de un retardo excesivo que vaya más
allá de lo que puede justificarse por el retraso del TCP, puede
aparecer especialmente en las redes inalámbricas o en conexiones de
parámetro tales que al menos una parte discurra sobre un enlace
inalámbrico. Los inventores de la presente solicitud constataron que
pueden introducirse retrasos espúreos con bastante frecuencia en
tales redes, de modo que resulta una seria degradación de las
actuaciones. Ahora se mencionarán brevemente ejemplos de esto.
En la Fig. 4 se presenta una situación en la que
dos ordenadores principales actúan como examinadores del TCP (lo que
viene indicado por las lechas largas de ordenador principal a
ordenador principal en la parte inferior y en la parte superior de
la figura). Las capas de parámetro inferiores comprenden un enlace
de radio sobre una red de acceso inalámbrica a la de internet. La
conexión entre internet y el ordenador principal de la derecha no se
ha representado. Un ejemplo de un parámetro para el enlace por radio
es el denominado de parámetro de control de enlace por radio RLC.
Como se ha indicado en la Fig. 4, tanto el parámetro de la capa de
transporte (por ejemplo, el TCP) como el parámetro de la capa de
enlace (por ejemplo, el RLC) tienen una función de ARQ (Repetición
de la Petición de Retransmisión Automática). Esto significa que esos
parámetros desempeñan a la vez las funciones de retraso y de
retransmisión. En la situación de la Fig. 4, debido a que se usa el
ARQ en la capa de enlace, se genera una condición de carrera entre
la capa de enlace y la capa de transporte: mientras la capa de
enlace retransmite datos, el temporizador de retransmisión de
transporte podría expirar, lo que conduce a un tiempo de descuento
espúreo. Las retransmisiones en la capa de enlace pueden ser
debidas, por ejemplo, a errores de transmisión, o bien a pérdida de
datos debida a entregas.
Puede observarse también que el retraso de la
transmisión por la red inalámbrica es frecuentemente una fracción
considerable del retardo de extremo a extremo entre el examinador de
remisión y el examinador de recepción del parámetro de la capa de
transporte. Si, en este caso, la anchura de banda disponible para la
conexión de la capa de transporte en la red inalámbrica cae
considerablemente en un corto período de tiempo, el aumento
resultante en el retardo de extremo a extremo entre el remitente y
el receptor de la capa de transporte pudiera conducir a retrasos
espúreos. Como ejemplos de caídas de la anchura de banda se incluyen
el que los ordenadores principales móviles ejecuten una entrega a
una célula que proporcione menor anchura de banda que la célula
antigua.
Como ya se indicó antes, cuando se emplee el
presente invento se puede evitar el problema descrito en relación
con la Fig. 3. Más concretamente, cuando se aplique el método
descrito en relación con la Fig. 1 al problema de la Fig. 3,
entonces el examinador de remisión es capaz de diferenciar entre
unidades de datos de acuse de recibo a la transmisión original de
una unidad de datos y unidades de datos de acuse de recibo a la
retransmisión de una unidad de datos. A la vista de esta
información, el remitente puede decidir si se ha producido un
retraso espúreo, o si ha existido ciertamente una pérdida de una
unidad de datos. El remitente puede entonces reaccionar en
consecuencia.
Más concretamente, en el ejemplo de la Fig. 3, el
remitente que use el invento será capaz de identificar la unidad de
datos de acuse de recibo recibida después de haber retransmitido el
primer paquete representado como siendo un acuse de recibo de la
transmisión original (T = 10s) y no de la retransmisión (t = 15s).
Debido a esto, el remitente efectuará un procedimiento de respuesta
apropiado al excesivo retardo, es decir, que no retransmitirá las
unidades de datos que sigan a la primera unidad de datos
retransmitida, y tampoco disminuirá el ritmo de transmisión, sino
que más bien el remitente aumentará el período de retraso empleado
en el control del flujo sobre la base del retardo medido entre el
envío original de la unidad de datos y la recepción de la
correspondiente unidad de datos de acuse de recibo de dicho envío
original. De este modo se pueden evitar más retransmisiones espúreas
y retrasos.
Como puede verse, el presente invento es capaz de
proporcionar un mecanismo que permite un sistema de comunicación más
flexible cuando usa un protocolo que proporcione acuse de recibo de
datos y una función de retraso o duplicar la función de detección de
acuse de recibo. En el ejemplo que se acaba de describir, el invento
es capaz de cualificar un acontecimiento de disparo, es decir, de
diferenciar entre al menos dos causas diferentes, y además es capaz
de invocar un procedimiento de respuesta apropiado. Puede observarse
que en los anteriores ejemplos los modos para adaptar los parámetros
de adaptación están asociados con la pérdida de unidades de datos
por una parte y con un retardo excesivo por otra, pero naturalmente
el presente invento no está en modo alguno limitado a eso. Muy por
el contrario, los modos para adaptar los parámetros de adaptación
pueden ser asociados con cualquier causa posible de acontecimientos
de retraso o de acontecimientos de acuse de recibo duplicado.
En la realización representada en la Fig. 1, se
decidió en el paso S5 si la unidad de datos de acuse de recibo
asociada con una unidad de datos dada acusaba recibo de la
transmisión original o de la retransmisión de dicha unidad de datos
dada. En consecuencia, para una primera realización preferida para
poner en práctica este paso, el remitente envía un registro del
tiempo de ida y vuelta RTT asociado con la conexión entre el
examinador de remisión y el examinador de recepción, y especialmente
mantiene un registro del RTT más corto hallado durante la conexión o
sesión hasta el momento que se esté considerando. Entonces, si se ha
recibido una unidad de datos de acuse de recibo para una unidad de
datos retransmitida dentro de un período de tiempo que sea más corto
que una fracción predeterminada de dicho RTT más corto, entonces el
remitente determina que ese acuse de recibo pertenece a la
transmisión original, y no a la retransmisión. Esta fracción puede
ser establecida en un valor fijo, o bien puede ser a su vez un
parámetro de adaptación. Naturalmente, no es necesario que el valor
de comparación multiplicado con dicha fracción sea el RTT más corto
medido, sino que, por el contrario, es también posible que el
remitente envíe un valor de RTT medio. En este sentido, el valor de
comparación a ser multiplicado con dicha fracción es generalmente
función de uno o más valores del RTT medidos en el curso de la
conexión (durante la sesión).
De acuerdo con otra realización preferida para
ejecutar el paso S5, el remitente añade una marca a las unidades de
datos que envía, donde dicha marca está definida de tal modo que
permite diferenciar entre una transmisión original y una
retransmisión. Entonces, el receptor puede marcar en consecuencia
unidades de datos de acuse de recibo, de tal manera que el remitente
sea capaz de identificar si un acuse de recibo se refiere a la
transmisión original o a la retransmisión.
Este marcado de las unidades de datos puede
hacerse de cualquier modo que se desee. Por ejemplo, sería posible
en teoría designar simplemente un bit único en las unidades de
datos, donde un valor de 0 indicaría la transmisión original y un
valor de 1 una retransmisión, o viceversa. En un sentido general, se
puede elegir una cadena de bits que puede también conducir alguna
información más. No obstante, en relación con los protocolos que
proporcionan tal opción, se prefiere usar la opción de selo de
tiempo. Esta opción es bien conocida, por ejemplo, para el TCP,
véase el texto de W. R. Stevens. En otras palabras, se prefiere
incluir un sello de tiempo en las unidades de datos enviadas, que
indique cuándo fue enviada la unidad de datos. El receptor puede
entonces simplemente incluir el mismo sello de tiempo en la unidad
de datos de acuse de recibo, de modo que el remitente tenga un modo
único de identificar las unidades de datos a las cuales se refiere
el acuse de recibo.
Aunque el presente invento se ha descrito en
relación con realizaciones preferidas, éstas no limitan el alcance,
y están destinadas únicamente a conducir a una mejor comprensión del
invento. Muy por el contrario, el alcance del invento viene
determinado por las reivindicaciones que se acompañan.
Claims (30)
1. Un método para controlar una comunicación
orientada en unidades de datos entre un remitente y un receptor de
acuerdo con un protocolo de comunicación predeterminado, donde
dicho remitente divide una cantidad de datos a
ser enviados en una o más unidades de datos que tienen una
estructura determinada por dicho protocolo,
dicho receptor acusa recibo de la correcta
recepción de las unidades de datos, devolviendo para ello unidades
de datos de acuse de recibo a dicho remitente,
dichas unidades de datos son enviadas por dicho
remitente de acuerdo con un procedimiento de control del flujo
conducido sobre la base de uno o más parámetros de adaptación y
dichas unidades de datos de acuse de recibo, y
dicho procedimiento de control del flujo
comprende un mecanismo de detección de pérdida de datos capaz de
detectar pérdida de datos en dicha comunicación, siendo disparado
dicho mecanismo de detección de pérdida de datos para indicar la
pérdida potencial de datos por uno o más acontecimientos
predeterminados, donde en respuesta al disparo de dicho mecanismo de
detección de pérdida de datos se lleva a cabo un procedimiento de
respuesta correspondiente (S1, S2, S3, S4, S5, S6, S7), el cual
comprende la retransmisión (S3) de una unidad de datos dada,
caracterizado
porque
dicho procedimiento de respuesta (S1, S2, S3, S4,
S5, S6, S7) comprende al menos dos modos diferentes (S6, S7) para
adaptar dichos uno o más parámetros de adaptación, y comprende una
decisión (S5) sobre cuál de dichos al menos dos modos (S6, S7)
elegir para adaptar dichos parámetros de adaptación, efectuándose
dicha decisión (S5) sobre la base de una o más unidades de datos de
acuse de recibo recibidas por dicho remitente después de haber
retransmitido dicha unidad de datos dada.
2. Un método de acuerdo con la reivindicación 1,
en el que dicho mecanismo de detección de pérdida de datos es un
mecanismo de retraso, de tal modo que después de enviada una unidad
de datos dada, dicho remitente vigila un período de retraso y si no
se recibe ninguna unidad de datos de acuse de recibo asociada con
dicha unidad de datos dada antes de que expire dicho período de
retraso, se dispara dicho mecanismo de retraso.
3. Un método de acuerdo con la reivindicación 1,
en el que dicho mecanismo de detección de pérdida de datos es un
mecanismo de detección de acuse de recibo duplicado, de tal modo que
dicho remitente vigila los acuses de recibo recibidos, y si se acusa
recibo de una unidad de datos un número predeterminado de veces, se
dispara dicho mecanismo de detección de acuse de recibo
duplicado.
4. Un método de acuerdo con la reivindicación 2,
en el que dicho período de retraso es uno de dichos parámetros de
adaptación.
5. Un método de acuerdo con una de las
reivindicaciones 1 a 4, en el que dicho procedimiento de control del
flujo está basado en ventanas, y entre dichos parámetros de
adaptación hay una o más ventanas de control del flujo.
6. Un método de acuerdo con una de las
reivindicaciones 1 a 5, en el que dichos al menos dos modos
consisten en un primer modo y un segundo modo, estando asociado
dicho primer modo con el juicio de que el acontecimiento de disparo
fue originado por la pérdida de dicha unidad de datos dada, y
estando asociado dicho segundo modo con el juicio de que dicha
unidad de datos dada o la unidad de datos de acuse de recibo para
dicha unidad de datos dada ha sido excesivamente retardada.
7. Un método de acuerdo con la reivindicación 6,
en el que dicho remitente marca las unidades de datos que son
enviadas, de tal modo que se pueda diferenciar una transmisión
original de una retransmisión, y dicho receptor marca en
correspondencia las unidades de datos de acuse de recibo, de tal
modo que se pueda diferenciar el acuse de recibo de una unidad de
datos enviada originalmente del acuse de recibo de la retransmisión
de dicha unidad de datos.
8. Un método de acuerdo con la reivindicación 7,
en el que el remitente marca unidades de datos incluyendo para ello
un sello de tiempo en cada unidad de datos enviada, indicando dicho
sello de tiempo el momento en que fue enviada dicha unidad de datos,
y el receptor marca la unidad de datos de acuse de recibo para una
unidad de datos recibida, incluyendo para ello el sello de tiempo
contenido en dicha unidad de datos recibida en la unidad de datos de
acuse de recibo para dicha unidad de datos recibida.
9. Un método de acuerdo con la reivindicación 7,
en el que el remitente marca las unidades de datos incluyendo para
ello una cadena de bits en cada unidad de datos enviada, teniendo
dicha cadena de bits al menos dos valores diferentes, para
diferenciar entre una transmisión original y una retransmisión, y el
receptor marca la unidad de datos de acuse de recibo para una unidad
de datos recibida incluyendo para ello la cadena de bits contenida
en dicha unidad de datos recibida en la unidad de datos de acuse de
recibo para dicha unidad de datos recibida.
10. Un método de acuerdo con la reivindicación 9,
en el que dicha cadena de bits consiste en un solo bit.
11. Un método de acuerdo con la reivindicación 9,
en el que dicha cadena de bits consiste en una pluralidad de bits,
de tal modo que dicha cadena de bits es capaz de diferenciar entre
diferentes retransmisiones.
12. Un método de acuerdo con una de las
reivindicaciones 9 a 11, en el que se elige dicho primer modo si la
primera unidad de datos de acuse de recibo asociada con dicha unidad
de datos dada que es recibida después de haber sido retransmitida
dicha unidad de datos dada, acusa recibo de la retransmisión de
dicha unidad de datos dada, y se elige dicho segundo modo si la
primera unidad de datos de acuse de recibo asociada con dicha unidad
de datos dada que es recibida después de haber sido retransmitida
dicha unidad de datos dada acusa recibo de la transmisión original
de dicha unidad de datos dada.
13. Un método de acuerdo con la reivindicación 6,
en el que
el remitente mide el tiempo de ida y vuelta
asociado con la conexión para enviar dicha cantidad de datos,
se determina el tiempo transcurrido entre la
retransmisión de dicha unidad de datos dada y la recepción de la
primera unidad de datos de acuse de recibo asociada con dicha unidad
de datos dada y se compara con un valor derivado de una o más de
dichas mediciones del tiempo de ida y vuelta, y
se elige dicho primer modo o dicho segundo modo
sobre la base del resultado de dicha comparación.
14. Un método de acuerdo con la reivindicación
13, en el que dicho valor derivado de dichas mediciones del tiempo
de ida y vuelta es el tiempo de ida y vuelta más corto para la
conexión, y se elige el segundo modo si dicho tiempo entre la
retransmisión de dicha unidad de datos dada y la recepción de la
primera unidad de datos de acuse de recibo asociada con dicha unidad
de datos dada es más corto que una fracción predeterminada de dicho
tiempo de ida y vuelta mínimo.
15. Un método de acuerdo con una de las
reivindicaciones 6 a 14, en el que el segundo modo comprende adaptar
el período de retraso sobre la base del tiempo que haya transcurrido
entre la transmisión original de dicha unidad de datos dada y la
recepción de la primera unidad de datos de acuse de recibo asociada
con dicha unidad de datos dada.
16. Un método de acuerdo con una de las
reivindicaciones 6 a 15, en el que el procedimiento de control del
flujo está basado en ventanas, y se usa una ventana de congestión,
donde el valor de dicha ventana de congestión en el momento de dicho
acontecimiento de disparo se almacena después de que se haya
producido dicho acontecimiento de disparo, y a continuación se
restablece dicho valor de la ventana de congestión a un valor
predeterminado, y si se ha elegido dicho segundo modo después de
haber recibido la primera unidad de datos de acuse de recibo
asociada con dicha unidad de datos dada, se establece dicho valor de
dicha ventana de congestión en el valor que habría tomado si no
hubiese tenido lugar el procedimiento de respuesta.
17. Un dispositivo de comunicación para
comunicación orientada en unidades de datos, de acuerdo con un
protocolo de comunicación predeterminado, donde dicho protocolo de
comunicación prescribe que el remitente en una comunicación divida
una cantidad de datos a ser enviados en una o más unidades de datos
que tienen una estructura determinada por dicho protocolo, y el
receptor en dicha comunicación acusa recibo de la correcta recepción
de las unidades de datos devolviendo para ello al remitente unidades
de datos de acuse de recibo. comprendiendo dicho dispositivo de
comunicación:
unos medios tales que cuando dicho dispositivo de
comunicación actúa como remitente, está dispuesto para enviar
unidades de datos de acuerdo con un procedimiento de control del
flujo que se conduce sobre la base de uno o más parámetros de
adaptación y dichas unidades de datos de acuse de recibo,
comprendiendo dicho procedimiento de control del flujo un mecanismo
de detección de pérdida de datos capaz de detectar una pérdida de
datos en dicha comunicación, siendo disparado dicho mecanismo de
detección de pérdida de datos para indicar la pérdida potencial de
datos por uno o más acontecimientos predeterminados, donde en
respuesta al disparo de dicho mecanismo de detección de pérdida de
datos se lleva a cabo un procedimiento de respuesta correspondiente,
el cual comprende la retransmisión de una unidad de datos dada,
caracterizado
porque
dicho dispositivo de comunicación está dispuesto
de tal modo que dicho procedimiento de respuesta (S1, S2, S3, S4,
S5, S6, S7) comprende al menos dos modos diferentes para adaptar
dichos uno o más parámetros de adaptación y comprende una decisión
(S5) sobre cuál de dichos al menos dos modos (S6, S7) elegir para
adaptar dichos parámetros de adaptación,
tomándose dicha decisión (S5) sobre la base de
una o más unidades de datos de acuse de recibo recibidas por dicho
remitente después de haber retransmitido dicha unidad de datos
dada.
18. Un dispositivo de acuerdo con la
reivindicación 17, en el que dicho mecanismo de detección de pérdida
de datos es un mecanismo de retraso, de tal modo que después de
enviada una unidad de datos dada dicho remitente está dispuesto para
vigilar un período de retraso, y si no se recibe una unidad de datos
de acuse de recibo asociada con dicha unidad de datos dada antes de
que expire dicho período de retraso, se dispara dicho mecanismo de
retraso.
19. Un dispositivo de acuerdo con la
reivindicación 17, en el que dicho mecanismo de detección de pérdida
de datos es un mecanismo de detección de acuse de recibo duplicado,
de tal modo que dicho remitente está dispuesto para vigilar los
acuses de recibo recibidos, y si se acusa recibo de una unidad de
datos un número predeterminado de veces, se dispara dicho mecanismo
de detección de acuse de recibo duplicado.
20. Un dispositivo de acuerdo con la
reivindicación 18, en el que dicho período de retraso es uno de
dichos parámetros de adaptación.
21. Un dispositivo de acuerdo con una de las
reivindicaciones 17 a 20, en el que dicho procedimiento de control
del flujo está basado en ventanas, y entre dichos parámetros de
adaptación hay una o más ventanas de control del flujo.
22. Un dispositivo de acuerdo con una de las
reivindicaciones 17 a 21, en el que dichos al menos dos modos
consisten en un primer modo y un segundo modo, estando asociado
dicho primer modo con el juicio de que el acontecimiento de disparo
fue originado por la pérdida de dicha unidad de datos dada, y
estando asociado dicho segundo modo con el juicio de que dicha
unidad de datos dada, o la unidad de datos de acuse de recibo para
dicha unidad de datos dada, se ha retardado excesivamente.
23. Un dispositivo de acuerdo con la
reivindicación 22, en el que dicho dispositivo, cuando actúa como un
remitente, está dispuesto para marcar unidades de datos que sean
enviadas, de tal modo que se pueda diferenciar una transmisión
original de una retransmisión, y dicho dispositivo, cuando actúa
como un receptor, está dispuesto para marcar de modo correspondiente
las unidades de datos de acuse de recibo, de tal modo que el acuse
de recibo de una unidad de datos enviada originalmente pueda ser
diferenciado del acuse de recibo de la retransmisión de dicha unidad
de datos.
24. Un dispositivo de acuerdo con la
reivindicación 23, en el que el dispositivo, cuando actúa como un
remitente, está dispuesto para macar unidades de datos, incluyendo
para ello un sello de tiempo en cada unidad de datos enviada,
indicando dicho sello de tiempo el momento en que fue enviada dicha
unidad de datos, y el dispositivo, cuando actúa como un receptor,
está dispuesto para marcar la unidad de datos de acuse de recibo
para una unidad de datos recibida, incluyendo para ello el sello de
tiempo contenido en dicha unidad de datos recibida en la unidad de
datos de acuse de recibo para dicha unidad de datos recibida.
25. Un dispositivo de acuerdo con la
reivindicación 23, en el que el dispositivo, cuando actúa como un
remitente, está dispuesto para marcar unidades de datos, incluyendo
para ello una cadena de bits en cada unidad de datos enviada,
teniendo dicha cadena de bits al menos dos valores diferentes para
diferenciar entre una transmisión original y una retransmisión, y el
dispositivo, cuando actúa como un receptor, está dispuesto para
marcar la unidad de datos de acuse de recibo para una unidad de
datos recibida, incluyendo para ello la cadena de bits contenida en
dicha unidad de datos recibida en la unidad de datos de acuse de
recibo para dicha unidad de datos recibida.
26. Un dispositivo de acuerdo con la
reivindicación 24 ó 25, que está dispuesto de tal manera que se
elige dicho primer modo si la primera unidad de datos de acuse de
recibo asociada con dicha unidad de datos dada que es recibida
después de haber retransmitido dicha unidad de datos dada acusa
recibo de la retransmisión de dicha unidad de datos dada, y se elige
dicho segundo modo si la primera unidad de datos de acuse de recibo
asociada con dicha unidad de datos dada que es recibida después de
haber retransmitido dicha unidad de datos dada, acusa recibo de la
transmisión original de dicha unidad de datos dada.
27. Un dispositivo de acuerdo con la
reivindicación 22, en el que
el dispositivo, cuando actúa como un remitente,
está dispuesto para medir el tiempo de ida y vuelta asociado con la
conexión para enviar dicha cantidad de datos,
para determinar el tiempo transcurrido entre la
retransmisión de dicha unidad de datos dada y la recepción de la
primera unidad de datos de acuse de recibo asociada con dicha unidad
de datos dada y comparar con un valor derivado de una o más de
dichas mediciones del tiempo de ida y vuelta, y
para elegir dicho primer modo o dicho segundo
modo sobre la base del resultado de dicha comparación.
28. Un dispositivo de acuerdo con la
reivindicación 27, en el que dicho valor derivado de dichas
mediciones del tiempo de ida y vuelta es el tiempo de ida y vuelta
más corto para la conexión, y el dispositivo está dispuesto para
elegir dicho segundo modo si dicho tiempo entre la retransmisión de
dicha unidad de datos dada y la recepción de la primera unidad de
datos de acuse de recibo asociada con dicha unidad de datos dada, es
menor que una fracción predeterminada de dicho tiempo de ida y
vuelta mínimo.
29. Un dispositivo de acuerdo con una de las
reivindicaciones 22 a 28, en el que el segundo modo comprende
adaptar el período de retraso sobre la base del tiempo que haya
transcurrido entre la transmisión original de dicha unidad de datos
dada y la recepción de la primera unidad de datos de acuse de recibo
asociada con dicha unidad de datos dada.
30. Un dispositivo de acuerdo con una de las
reivindicaciones 22 a 29, en el que el procedimiento de control del
flujo está basado en ventanas, y se usa una ventana de congestión,
donde el valor de dicha ventana de congestión en el momento de dicho
acontecimiento de disparo es almacenado después de que se haya
producido dicho acontecimiento de disparo y a continuación se
restablece dicho valor de la ventana de congestión en un valor
predeterminado, y si se elige dicho segundo modo después de haber
recibido la primera unidad de datos de acuse de recibo asociada con
dicha unidad de datos dada, se establece dicho valor de dicha
ventana de congestión en el valor que habría tomado si no hubiese
tenido lugar el procedimiento de respuesta.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP99100274 | 1999-01-08 | ||
| EP99100274A EP1018821A1 (en) | 1999-01-08 | 1999-01-08 | Communication device and method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2221473T3 true ES2221473T3 (es) | 2004-12-16 |
Family
ID=8237320
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES99965583T Expired - Lifetime ES2221473T3 (es) | 1999-01-08 | 1999-12-31 | Metodo y dispositivo de comunicacion. |
Country Status (13)
| Country | Link |
|---|---|
| US (4) | US6992982B1 (es) |
| EP (4) | EP1018821A1 (es) |
| JP (4) | JP4503186B2 (es) |
| KR (3) | KR100860912B1 (es) |
| CN (4) | CN101039272B (es) |
| AR (3) | AR038753A1 (es) |
| AT (3) | ATE281036T1 (es) |
| AU (1) | AU766137B2 (es) |
| CA (3) | CA2358396C (es) |
| DE (3) | DE69921699T2 (es) |
| ES (1) | ES2221473T3 (es) |
| NO (1) | NO332553B1 (es) |
| WO (1) | WO2000041362A1 (es) |
Families Citing this family (58)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1018821A1 (en) * | 1999-01-08 | 2000-07-12 | TELEFONAKTIEBOLAGET L M ERICSSON (publ) | Communication device and method |
| US6728809B1 (en) * | 1999-09-09 | 2004-04-27 | Matsushita Electric Industrial Co., Ltd. | Time-out control apparatus, terminal unit, time-out control system and time-out procedure |
| US6757245B1 (en) * | 2000-06-01 | 2004-06-29 | Nokia Corporation | Apparatus, and associated method, for communicating packet data in a network including a radio-link |
| US7529235B2 (en) * | 2000-12-06 | 2009-05-05 | Franklin Zhigang Zhang | Internet based time distributed message network system and personal mobile access device |
| FI111421B (fi) * | 2000-12-20 | 2003-07-15 | Nokia Corp | Tiedonsiirtomenetelmä ja radiojärjestelmä |
| EP1253795B1 (en) * | 2001-01-09 | 2006-10-04 | Mitsubishi Denki Kabushiki Kaisha | Data communication system and wireless communication device |
| WO2002057917A2 (en) * | 2001-01-22 | 2002-07-25 | Sun Microsystems, Inc. | Peer-to-peer network computing platform |
| US7099273B2 (en) * | 2001-04-12 | 2006-08-29 | Bytemobile, Inc. | Data transport acceleration and management within a network communication system |
| EP1263159A1 (en) * | 2001-06-01 | 2002-12-04 | Telefonaktiebolaget Lm Ericsson | Method and receiver for improved data packet transfer in a transmission protocol with repeat requests |
| EP1263160A1 (en) * | 2001-06-01 | 2002-12-04 | Telefonaktiebolaget Lm Ericsson | Method and transmitter for an efficient packet data transfer in a transmission protocol with repeat requests |
| US7180871B1 (en) * | 2001-07-18 | 2007-02-20 | Nortel Networks Limited | Round trip timeout adjustment in a cellular wireless communication system |
| JP3590387B2 (ja) * | 2001-11-01 | 2004-11-17 | 株式会社東芝 | 通信装置及びプログラム |
| US7283469B2 (en) * | 2002-04-30 | 2007-10-16 | Nokia Corporation | Method and system for throughput and efficiency enhancement of a packet based protocol in a wireless network |
| CN100356750C (zh) * | 2002-08-10 | 2007-12-19 | 华为技术有限公司 | 同步数字体系网络传输数据业务的流量控制方法 |
| US7603464B2 (en) * | 2003-06-04 | 2009-10-13 | Sony Computer Entertainment Inc. | Method and system for identifying available resources in a peer-to-peer network |
| US7385923B2 (en) * | 2003-08-14 | 2008-06-10 | International Business Machines Corporation | Method, system and article for improved TCP performance during packet reordering |
| US7321567B2 (en) * | 2003-09-30 | 2008-01-22 | Motorola, Inc. | Method and apparatus for preventing a spurious retransmission after a planned interruption of communications |
| JP2005167353A (ja) * | 2003-11-28 | 2005-06-23 | Ntt Docomo Inc | 送信装置およびプログラム |
| US7290195B2 (en) * | 2004-03-05 | 2007-10-30 | Microsoft Corporation | Adaptive acknowledgment delay |
| JP2006054853A (ja) * | 2004-07-14 | 2006-02-23 | Iwatsu Electric Co Ltd | 無線ｌａｎにおけるパケット伝送方法及び装置 |
| WO2006007870A1 (en) * | 2004-07-23 | 2006-01-26 | Telefonaktiebolaget Lm Ericsson (Publ) | Data unit sender control method |
| KR100678943B1 (ko) * | 2004-08-24 | 2007-02-07 | 삼성전자주식회사 | 블록 ａｃｋ 프레임 전송방법 및 장치 |
| US20060059256A1 (en) * | 2004-09-10 | 2006-03-16 | Nokia Corporation | Signaling a state of a transmission link via a transport control protocol |
| KR100744116B1 (ko) * | 2005-07-12 | 2007-08-01 | 삼성전자주식회사 | 멀티미디어 정보를 고속 시리얼로 전송하는 양방향 통신장치 및 방법 |
| EP1753197A1 (en) * | 2005-07-27 | 2007-02-14 | Mitsubishi Electric Information Technology Centre Europe B.V. | Method for controlling the delivery of a flow of data to at least a client of a data provider |
| US20070058636A1 (en) * | 2005-09-15 | 2007-03-15 | Research In Motion Limited | System and method for evaluating lower layer reliability using upper layer protocol functionality in a communications network |
| US8615003B1 (en) * | 2005-10-28 | 2013-12-24 | At&T Intellectual Property Ii, L.P. | Method and apparatus for handling network element timeouts in a packet-switched communication network |
| US20070097903A1 (en) * | 2005-11-03 | 2007-05-03 | Interdigital Technology Corporation | Method and apparatus of exchanging messages via a wireless distribution system between groups operating in different frequencies |
| KR100976732B1 (ko) * | 2005-12-01 | 2010-08-18 | 삼성전자주식회사 | 다중 홉 방식의 네트워크에서 중계국을 이용한 재전송 장치및 방법 |
| CN100366005C (zh) * | 2005-12-21 | 2008-01-30 | 中国移动通信集团公司 | Ip设备吞吐量的测试方法 |
| US7827459B1 (en) * | 2006-01-10 | 2010-11-02 | University Of Maryland, College Park | Communications protocol |
| US8115600B2 (en) * | 2008-11-19 | 2012-02-14 | Greatbatch Ltd. | RFID detection and identification system including an RFID reader having a limited transmit time and a time-out period to protect a medical device against RFID-associated electromagnetic interference |
| US8418016B2 (en) | 2006-10-05 | 2013-04-09 | Ntt Docomo, Inc. | Communication system, communication device, and communication method |
| US8355913B2 (en) * | 2006-11-03 | 2013-01-15 | Nokia Corporation | Speech recognition with adjustable timeout period |
| JP5185391B2 (ja) * | 2007-11-01 | 2013-04-17 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | 無線ネットワーク制御装置（ｒｎｃ）における効率的フロー制御 |
| KR100917158B1 (ko) * | 2008-04-16 | 2009-09-16 | 이상휘 | 햇빛추적기 |
| US8299899B2 (en) * | 2008-11-19 | 2012-10-30 | Greatbatch Ltd. | AIMD external programmer incorporating a multifunction RFID reader having a limited transmit time and a time-out period |
| CN102217249B (zh) * | 2008-12-05 | 2014-03-19 | 株式会社Ntt都科摩 | 通信装置和通信方法 |
| CN101527928B (zh) * | 2009-03-19 | 2011-05-25 | 中兴通讯股份有限公司 | 电路数据业务的传输系统及方法 |
| US8093991B2 (en) * | 2009-09-16 | 2012-01-10 | Greatbatch Ltd. | RFID detection and identification system for implantable medical devices |
| EP2520059B1 (en) * | 2009-12-29 | 2014-11-19 | Telecom Italia S.p.A. | Performing a time measurement in a communication network |
| US9860182B2 (en) | 2012-12-19 | 2018-01-02 | Nec Corporation | Data transmission device, data transmission method, and program therefor |
| EP2952035B1 (en) * | 2013-01-29 | 2022-01-12 | Samsung Electronics Co., Ltd. | Method and apparatus for transmitting radio link control status report in communication system based on multiple radio access technologies |
| CN104104608B (zh) * | 2013-04-15 | 2019-06-11 | 华为技术有限公司 | 接收报文的方法及装置 |
| KR102198701B1 (ko) * | 2014-07-03 | 2021-01-05 | 삼성전자주식회사 | 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치 |
| US10482255B2 (en) | 2016-02-16 | 2019-11-19 | Atmel Corporation | Controlled secure code authentication |
| US10474823B2 (en) * | 2016-02-16 | 2019-11-12 | Atmel Corporation | Controlled secure code authentication |
| US10553040B2 (en) * | 2016-02-18 | 2020-02-04 | Ford Global Technologies, Llc | Method and apparatus for enhanced telematics security through secondary channel |
| US10616197B2 (en) | 2016-04-18 | 2020-04-07 | Atmel Corporation | Message authentication with secure code verification |
| US10298504B2 (en) | 2016-05-04 | 2019-05-21 | Microsoft Technology Licensing, Llc | Adaptive gain reduction for background connections |
| US20170324642A1 (en) * | 2016-05-04 | 2017-11-09 | Microsoft Technology Licensing, Llc | Initial and periodic slowdowns for background connections |
| EP3785402B1 (en) * | 2018-04-27 | 2025-08-06 | Telecom Italia S.p.A. | Enabling a performance measurement in a packet-switched communication network |
| US11088906B2 (en) * | 2018-05-10 | 2021-08-10 | International Business Machines Corporation | Dependency determination in network environment |
| CN112470411B (zh) * | 2018-07-24 | 2024-07-30 | 高通股份有限公司 | 用于在拥塞和等待时间约束下进行速率适配的技术 |
| CN110601799A (zh) * | 2019-09-12 | 2019-12-20 | 无锡江南计算技术研究所 | 一种基于双滑动窗口的链路重传方法及装置 |
| WO2021064448A1 (en) * | 2019-10-01 | 2021-04-08 | Pismo Labs Technology Limited | Modified methods and system of transmitting and receiving transmission control protocol segments over internet protocol packets |
| CN111654523A (zh) * | 2020-04-28 | 2020-09-11 | 珠海格力电器股份有限公司 | 一种数据处理方法、装置、存储介质及服务器 |
| CN114760010A (zh) * | 2022-04-02 | 2022-07-15 | 沈阳飞机设计研究所扬州协同创新研究院有限公司 | 一种可靠的串口数据传输方法 |
Family Cites Families (35)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS55150690A (en) * | 1979-05-11 | 1980-11-22 | Nec Corp | Information transfer control system |
| JPH077944B2 (ja) * | 1986-10-17 | 1995-01-30 | 松下電器産業株式会社 | 信号伝送装置 |
| JPS63314934A (ja) * | 1987-06-17 | 1988-12-22 | Fujitsu Ten Ltd | デ−タ転送方式 |
| JPH0761072B2 (ja) * | 1993-02-26 | 1995-06-28 | 日本電気株式会社 | 衛星通信システム |
| JP2536385B2 (ja) * | 1993-03-30 | 1996-09-18 | 日本電気株式会社 | デ―タ通信方式 |
| DE69525895T2 (de) * | 1994-10-11 | 2002-09-05 | Nippon Telegraph And Telephone Corp., Tokio/Tokyo | System für Sendewiederholung in der Datenkommunikation |
| JP3284823B2 (ja) * | 1995-04-21 | 2002-05-20 | 株式会社エフ・エフ・シー | データ通信装置 |
| US5684802A (en) * | 1995-05-02 | 1997-11-04 | Motorola, Inc. | System and method for hybrid contention/polling protocol collison resolution used backoff timers with polling |
| FI98174C (fi) * | 1995-05-09 | 1997-04-25 | Nokia Telecommunications Oy | Datansiirtojärjestelmä, jossa on liukuvaan ikkunaan perustuva datavuonohjaus |
| JP3476985B2 (ja) * | 1995-12-28 | 2003-12-10 | 株式会社東芝 | パケット通信システムおよびパケット通信制御方法 |
| US5648970A (en) * | 1996-03-04 | 1997-07-15 | Motorola, Inc. | Method and system for ordering out-of-sequence packets |
| JPH09305664A (ja) * | 1996-05-10 | 1997-11-28 | Kokusai Electric Co Ltd | 情報表示システム及び情報端末 |
| JP3560423B2 (ja) * | 1996-09-17 | 2004-09-02 | 松下電器産業株式会社 | パケット送受信装置及びパケット受信装置 |
| KR100204583B1 (ko) * | 1996-09-21 | 1999-06-15 | 정선종 | 전송 프로토콜의 다자간 흐름 제어 방법 |
| GB9625208D0 (en) * | 1996-12-04 | 1997-01-22 | Olivetti Research Ltd | Detection system for determining information about objects |
| JP2969559B2 (ja) * | 1997-02-05 | 1999-11-02 | 株式会社超高速ネットワーク・コンピュータ技術研究所 | データ転送フロー制御方式 |
| JPH10224328A (ja) * | 1997-02-06 | 1998-08-21 | Sony Corp | データ通信方法及びデータ通信機 |
| US5974028A (en) * | 1997-02-24 | 1999-10-26 | At&T Corp. | System and method for improving transport protocol performance in communication networks having lossy links |
| JP3000546B2 (ja) * | 1997-03-07 | 2000-01-17 | 株式会社超高速ネットワーク・コンピュータ技術研究所 | 輻輳制御方法 |
| JPH10276241A (ja) * | 1997-03-28 | 1998-10-13 | Toshiba Corp | データ通信方法及びそのシステム |
| US6076114A (en) * | 1997-04-18 | 2000-06-13 | International Business Machines Corporation | Methods, systems and computer program products for reliable data transmission over communications networks |
| US6119235A (en) * | 1997-05-27 | 2000-09-12 | Ukiah Software, Inc. | Method and apparatus for quality of service management |
| US6011796A (en) * | 1997-06-17 | 2000-01-04 | Qualcomm Incorporated | Extended range sequence numbering for selective repeat data transmission protocol |
| US6018516A (en) * | 1997-11-14 | 2000-01-25 | Packeteer, Inc. | Method for minimizing unneeded retransmission of packets in a packet communication environment supporting a plurality of data link rates |
| US6041352A (en) * | 1998-01-23 | 2000-03-21 | Hewlett-Packard Company | Response time measuring system and method for determining and isolating time delays within a network |
| US6205120B1 (en) * | 1998-03-13 | 2001-03-20 | Packeteer, Inc. | Method for transparently determining and setting an optimal minimum required TCP window size |
| US6247058B1 (en) * | 1998-03-30 | 2001-06-12 | Hewlett-Packard Company | Method and apparatus for processing network packets using time stamps |
| US6392993B1 (en) * | 1998-06-29 | 2002-05-21 | Microsoft Corporation | Method and computer program product for efficiently and reliably sending small data messages from a sending system to a large number of receiving systems |
| EP0975123A1 (en) * | 1998-07-15 | 2000-01-26 | Telefonaktiebolaget L M Ericsson (Publ) | Communication device and method for reliable and low-delay packet transmission |
| US6389016B1 (en) * | 1998-10-14 | 2002-05-14 | Nortel Networks Limited | Data communication system and method for transporting data |
| US6661802B1 (en) * | 1998-10-27 | 2003-12-09 | Fujitsu Network Communications, Inc. | Congestion management |
| EP1018821A1 (en) * | 1999-01-08 | 2000-07-12 | TELEFONAKTIEBOLAGET L M ERICSSON (publ) | Communication device and method |
| EP1077559A1 (en) * | 1999-08-17 | 2001-02-21 | Telefonaktiebolaget Lm Ericsson | Method and device for determining a time-parameter |
| ES2310530T3 (es) * | 2001-04-04 | 2009-01-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Metodo de control de flujo de datos. |
| US7385923B2 (en) * | 2003-08-14 | 2008-06-10 | International Business Machines Corporation | Method, system and article for improved TCP performance during packet reordering |
-
1999
- 1999-01-08 EP EP99100274A patent/EP1018821A1/en not_active Withdrawn
- 1999-12-31 CN CN2007100881023A patent/CN101039272B/zh not_active Expired - Lifetime
- 1999-12-31 AT AT01127446T patent/ATE281036T1/de not_active IP Right Cessation
- 1999-12-31 DE DE69921699T patent/DE69921699T2/de not_active Expired - Lifetime
- 1999-12-31 CA CA002358396A patent/CA2358396C/en not_active Expired - Lifetime
- 1999-12-31 EP EP99965583A patent/EP1142226B1/en not_active Expired - Lifetime
- 1999-12-31 AU AU21043/00A patent/AU766137B2/en not_active Expired
- 1999-12-31 CN CNB2005100517451A patent/CN100338899C/zh not_active Expired - Lifetime
- 1999-12-31 ES ES99965583T patent/ES2221473T3/es not_active Expired - Lifetime
- 1999-12-31 KR KR1020017008526A patent/KR100860912B1/ko not_active Expired - Lifetime
- 1999-12-31 AT AT99965583T patent/ATE272281T1/de not_active IP Right Cessation
- 1999-12-31 EP EP02019795A patent/EP1263176B1/en not_active Expired - Lifetime
- 1999-12-31 CA CA2646502A patent/CA2646502C/en not_active Expired - Lifetime
- 1999-12-31 AT AT02019795T patent/ATE281728T1/de not_active IP Right Cessation
- 1999-12-31 EP EP01127446A patent/EP1195966B1/en not_active Expired - Lifetime
- 1999-12-31 DE DE69919027T patent/DE69919027T2/de not_active Expired - Lifetime
- 1999-12-31 JP JP2000592993A patent/JP4503186B2/ja not_active Expired - Lifetime
- 1999-12-31 CN CNB2005100517447A patent/CN100334825C/zh not_active Expired - Lifetime
- 1999-12-31 CA CA2646512A patent/CA2646512C/en not_active Expired - Lifetime
- 1999-12-31 DE DE69921512T patent/DE69921512T2/de not_active Expired - Lifetime
- 1999-12-31 KR KR1020047021672A patent/KR100789034B1/ko not_active Expired - Lifetime
- 1999-12-31 KR KR1020047021673A patent/KR100789035B1/ko not_active Expired - Lifetime
- 1999-12-31 CN CNB998155004A patent/CN1201531C/zh not_active Expired - Lifetime
- 1999-12-31 WO PCT/EP1999/010480 patent/WO2000041362A1/en not_active Ceased
-
2000
- 2000-01-05 US US09/478,168 patent/US6992982B1/en not_active Expired - Lifetime
- 2000-01-07 AR ARP000100071A patent/AR038753A1/es active IP Right Grant
-
2001
- 2001-07-06 NO NO20013361A patent/NO332553B1/no not_active IP Right Cessation
-
2005
- 2005-01-14 US US11/036,881 patent/US7158544B2/en not_active Expired - Lifetime
- 2005-09-30 US US11/240,935 patent/US7515540B2/en not_active Expired - Fee Related
-
2006
- 2006-03-31 AR ARP060101287A patent/AR054023A2/es active IP Right Grant
- 2006-03-31 AR ARP060101286A patent/AR053570A2/es active IP Right Grant
- 2006-10-27 US US11/553,667 patent/US7599402B2/en not_active Expired - Lifetime
-
2010
- 2010-01-21 JP JP2010011286A patent/JP4794672B2/ja not_active Expired - Lifetime
- 2010-01-21 JP JP2010011304A patent/JP5153799B2/ja not_active Expired - Lifetime
-
2012
- 2012-07-11 JP JP2012155466A patent/JP5694993B2/ja not_active Expired - Lifetime
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2221473T3 (es) | Metodo y dispositivo de comunicacion. | |
| ES2310530T3 (es) | Metodo de control de flujo de datos. | |
| ES2239721T3 (es) | Metodo y receptor para la transferencia mejorada de paquetes de datos en un protocolo de transmision con peticiones de repeticion. | |
| ES2297162T3 (es) | Metodo para vigilar los numeros de secuencia de transmision asignados a unidades de datos de protocolo para detectar y corregir errores de transmision. | |
| ES2296966T3 (es) | Metodo y transmision para una transferencia eficaz de datos por paquetes en un protocolo de transmision con peticiones de repeticion. | |
| JP4354406B2 (ja) | データユニット送信機及びこの送信機の制御方法 | |
| KR20190095487A (ko) | 패킷 전송 방법, 단말, 네트워크 디바이스 및 통신 시스템 | |
| ES2587012T3 (es) | Procedimiento de cambio de estado del protocolo de transmisión de control de flujo | |
| JP4435817B2 (ja) | 通信端末、通信制御方法および通信制御プログラム | |
| KR100895182B1 (ko) | 무선통신 시스템의 전송 제어 방법 | |
| Kühlewind et al. | TCP modifications for Congestion Exposure | |
| Zabir et al. | An efficient flow control approach for TCP over wireless Networks | |
| De Vleeschouwer et al. | Explicit window-based transport control protocols in lossy environments | |
| Prasanthi et al. | A new TCP mechanism for reducing retransmission timeouts over multi-hop wireless networks | |
| MXPA01005631A (es) | Dispositivo y metodo de comunicacion |