ES2329088T3 - Mejoras de protocolo de enlace de radio para reducir el tiempo de configuracion para llamadas de datos. - Google Patents
Mejoras de protocolo de enlace de radio para reducir el tiempo de configuracion para llamadas de datos. Download PDFInfo
- Publication number
- ES2329088T3 ES2329088T3 ES07004521T ES07004521T ES2329088T3 ES 2329088 T3 ES2329088 T3 ES 2329088T3 ES 07004521 T ES07004521 T ES 07004521T ES 07004521 T ES07004521 T ES 07004521T ES 2329088 T3 ES2329088 T3 ES 2329088T3
- Authority
- ES
- Spain
- Prior art keywords
- rlp
- estimate
- rtt
- message
- nak
- 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
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
- 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/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
-
- 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/1848—Time-out mechanisms
-
- 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/20—Arrangements for detecting or preventing errors in the information received using signal quality detector
-
- 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
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Communication Control (AREA)
- Exchange Systems With Centralized Control (AREA)
- Circuits Of Receivers In General (AREA)
- Medicines That Contain Protein Lipid Enzymes And Other Medicines (AREA)
- Peptides Or Proteins (AREA)
- Synchronisation In Digital Transmission Systems (AREA)
Abstract
Un aparato para transmitir un flujo de bytes de información, caracterizado por: medios (604) para establecer una primera estimación de tiempo de ida y vuelta, a la que a continuación se hace referencia como estimación de RTT, de protocolo de enlace de radio, al que a continuación se hace referencia como RLP, y medios para usar dicha primera estimación de RTT de RLP para determinar un sincronismo de mensajes de acuse de recibo negativo, al que a continuación se hace referencia como NAK, en una sesión de comunicación de RLP posterior.
Description
Mejoras de protocolo de enlace de radio para
reducir el tiempo de configuración para llamadas de datos.
La presente invención se refiere a
comunicaciones inalámbricas. Más particularmente, la presente
invención se refiere a un procedimiento y sistema mejorados que
requieren un tiempo de configuración reducido para establecer una
llamada de datos de protocolo de enlace de radio (RLP).
El uso de técnicas de modulación de acceso
múltiple por división de código (CDMA) es una de varias técnicas
para facilitar las comunicaciones en las que está presente un gran
número de usuarios de sistema. En la técnica se conocen otras
técnicas de sistema de comunicación de acceso múltiple, tales como
esquemas de acceso múltiple por división de tiempo (TDMA), acceso
múltiple por división de frecuencia (FDMA) y modulación en AM tales
como de banda lateral única compandida en amplitud (ACSSB). Estas
técnicas se han normalizado para facilitar la interoperación entre
equipos fabricados por diferentes compañías. Se han normalizado
sistemas de comunicaciones de acceso múltiple por división de
código en los Estados Unidos en la Asociación de la Industria de
Telecomunicaciones TIA/EIA/
IS-95-B, titulada "MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUALMODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEMS", y a lo que a continuación en el presente documento se hace referencia como IS-95. Además, en los Estados Unidos en la Asociación de la Industria de Telecomunicaciones PN-4431 se ha propuesto una nueva norma para sistemas de comunicaciones de acceso múltiple por división de código que va a publicarse como TIA/EIA/IS-2000-5, titulada "UPPER LAYER (LAYER 3) SIGNALING STANDARD FOR cdma2000 SPREAD SPECTRUM SYSTEMS", con fecha del 11 de julio de 1999 y a la que a continuación en el presente documento se hace referencia como IS-2000.
IS-95-B, titulada "MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUALMODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEMS", y a lo que a continuación en el presente documento se hace referencia como IS-95. Además, en los Estados Unidos en la Asociación de la Industria de Telecomunicaciones PN-4431 se ha propuesto una nueva norma para sistemas de comunicaciones de acceso múltiple por división de código que va a publicarse como TIA/EIA/IS-2000-5, titulada "UPPER LAYER (LAYER 3) SIGNALING STANDARD FOR cdma2000 SPREAD SPECTRUM SYSTEMS", con fecha del 11 de julio de 1999 y a la que a continuación en el presente documento se hace referencia como IS-2000.
La Unión Internacional de Telecomunicaciones
solicitó recientemente la presentación de procedimientos propuestos
para proporcionar servicios de datos de tasa de transmisión elevada
y voz de alta calidad sobre canales de comunicación inalámbrica.
Una primera propuesta de éstas fue emitida por la Asociación de la
Industria de Telecomunicaciones, titulada "The cdma2000
ITU-R RTT Candidate Submission". Una segunda
propuesta de éstas fue emitida por el Instituto Europeo de Normas de
Telecomunicaciones (ETSI), titulada "The ETSI UMTS Terrestrial
Radio Access (UTRA) ITU-R RTT Candidate
Submission", que también se conoce como "CDMA de banda
ancha" y a lo que a continuación en el presente documento se
hace referencia como W-CDMA. Una tercera propuesta
la emitió U.S. TG 8/1 titulada "The UWC-136
Candidate Submission", a lo que a continuación en el presente
documento se hace referencia como EDGE. El contenido de estas
presentaciones es de registro público y se conoce bien en la
técnica.
técnica.
La IS-95 se optimizó
originalmente para la transmisión de tramas de voz de tasa de
transmisión variable. Para soportar comunicaciones de voz
bidireccionales, tal como se tipifica en aplicaciones de teléfono
inalámbrico, es deseable que un sistema de comunicación proporcione
un retardo de datos realmente constante y mínimo. Por este motivo,
los sistemas IS-95 están diseñados con
codificadores de señales de voz y protocolos potentes de corrección
de errores hacia delante (FEC) que están diseñados para responder de
manera sencilla a errores de trama de voz. Los protocolos de
control de errores que requieren procedimientos de retransmisión de
trama añaden retardos inaceptables a la transmisión de voz, así que
no están diseñados en la especificación IS-95.
Las optimizaciones que hacen que la
especificación IS-95 independiente sea ideal para
aplicaciones de voz hacen que sea difícil de usar para aplicaciones
de datos por paquetes. En muchas aplicaciones que no son de voz,
tales como la transmisión de datos sobre protocolo de Internet
(IP), los requisitos de retardo del sistema de comunicación son
mucho menos estrictos que en aplicaciones de voz. En el protocolo
de control de transmisión (TCP), probablemente el más frecuente de
los protocolos usados en una red IP, se permiten prácticamente
retardos de transmisión infinitos para garantizar una transmisión
libre de errores. El TCP usa retransmisiones de datagramas de IP,
denominados comúnmente paquetes de IP, para proporcionar esta
fiabilidad de transporte.
Los datagramas de IP son generalmente demasiado
grandes para caber en una única trama IS-95.
Incluso después de dividir un datagrama de IP en segmentos lo
suficientemente pequeños para caber en una serie de tramas de
IS-95, debería recibirse sin error una serie entera
de tramas IS-95 para que el datagrama de IP único
fuera útil para TCP. La tasa de errores de trama típica de un
sistema IS- 95 hace que la probabilidad de una recepción libre de
errores de todos los segmentos de un único datagrama sea muy
baja.
Como se describe en IS-95,
opciones de servicio alternativas permiten la transmisión de otros
tipos de datos en lugar de tramas de voz. La
TIA/EIA/IS-707-A, titulada "DATA
SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS", a la que a
continuación se hace referencia como IS-707,
describe procedimientos usados en la transmisión de datos por
paquetes en un sistema IS-95.
\newpage
El protocolo de enlace de radio (RLP) se
describe en TIA/EIA/IS-707-A.8,
titulada "DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: RADIO
LINK PROTOCOL TYPE 2", a la que a continuación en el presente
documento se hace referencia como RLP2. RLP2 incorpora un protocolo
de control de errores con procedimientos de retransmisión de trama
sobre la capa de trama IS-95. RLP es de una clase
de protocolos de control de errores conocidos como protocolos ARQ
basados en NAK, que se conocen bien en la técnica. El RLP
IS-707 facilita la transmisión de un flujo de bytes,
en lugar de una serie de tramas de voz, a través de un sistema de
comunicación IS-95.
Varias capas de protocolo residen normalmente
por encima de la capa RLP. Los datagramas de IP, por ejemplo, se
convierten normalmente en un flujo de bytes de protocolo punto a
punto (PPP) antes de presentarse como un flujo de bytes a la capa
de protocolo RLP. Como la capa RLP ignora el protocolo y el
entramado de las capas de protocolo más altas, se dice que el flujo
de datos transportado por RLP es un "flujo de bytes sin
características".
El RLP se diseñó originalmente para satisfacer
los requisitos de enviar tramas grandes a través de un canal
IS-95. Por ejemplo, si un datagrama de IP de 500
bytes fuera a enviarse simplemente en tramas IS-95
llevando 20 bytes cada una, el datagrama de IP rellenaría 25 tramas
IS-95 consecutivas. Sin algún tipo de capa de
control de errores, las 25 de estas tramas tendrían que recibirse
sin error para que el datagrama de IP fuera útil para capas de
protocolo más altas. En un canal IS-95 que tiene
una tasa de errores de trama del 1%, la tasa de errores efectiva
del suministro de datagramas de IP sería del (1 -
(0,99)^{25}), ó 22%. Esta es una tasa de errores muy alta
en comparación con la mayor parte de redes usadas para llevar
tráfico sobre protocolo de Internet. RLP se diseñó como un protocolo
de capa de enlace que disminuiría la tasa de errores de tráfico
sobre IP para ser comparable con la tasa de errores típica de un
canal Ethernet 10Base2.
El RLP es un protocolo basado en acuse de recibo
negativo (NAK) en el que se envían tramas de NAK para provocar la
retransmisión de tramas de datos perdidas debido a errores de
comunicación. El sincronismo de la transmisión de tramas de NAK se
basa en estimaciones de tiempo de ida y vuelta (RU) determinado al
inicio de una sesión de RLP. La determinación de RTT en versiones
existentes de RLP requiere una toma de contacto en 3 etapas en la
que ambas partes transmiten tipos de trama específicos basándose en
los tipos de trama recibidos. No se envían datos desde ninguna
parte hasta la finalización de la toma de contacto en 3 etapas.
Esta toma de contacto en 3 etapas consume tiempo que de lo
contrario podría usarse para transmitir datos.
En una configuración de servicios de datos
típica, un ordenador portátil está conectado a un módem inalámbrico
que comunica con una red a través de una conexión de RLP. En una
aplicación típica de ordenador portátil tal como navegar por una
página web de Internet, el ordenador no intercambia datos con la
red de manera continua. En su lugar, el ordenador normalmente envía
una breve petición de datos que contienen la dirección de una
página web. El módem inalámbrico responde estableciendo una sesión
de RLP con la estación base local, y transmite la petición a través
de la estación base a la red. A través de esta sesión de RLP, el
módem inalámbrico recibe entonces los datos solicitados (tales como
el contenido de una página web), y muestra los datos al usuario.
Mientras que el usuario está leyendo los datos mostrados, no se
intercambian datos entre el módem inalámbrico y la estación base o
red.
Para permitir el uso más eficaz del espectro
inalámbrico, una red típica emplea "temporizadores de
actividad" que suspenden una sesión de RLP tras un periodo
predeterminado de inactividad de enlace. Si esto ocurre antes de que
el ordenador portátil intente enviar más datos a través del módem
inalámbrico, entonces se establece otra sesión de RLP para dar
servicio de los nuevos datos. El restablecimiento de una nueva
sesión de RLP provoca un retardo adicional en el intercambio de
datos con la red, que puede caracterizarse como "lentitud" del
ordenador portátil.
Hacer que una nueva sesión de RLP envíe datos
nuevos siempre tardará más que enviar los datos nuevos a través de
una sesión de RLP ya existente. Las versiones de RLP existentes
requieren la realización de una toma de contacto en 3 etapas para
establecer una sesión de RLP. Por lo tanto es muy deseable
minimizar la sobrecarga requerida para establecer una sesión de RLP,
incluyendo minimizar o eliminar el retardo inherente en la toma de
contacto en 3 etapas.
El documento
WO-A-99/37071 describe un
optimizador de TCP de enlace lento para determinar, basándose en un
RTT estimado, si un paquete de datos es un paquete de datos nuevo,
un paquete de datos retransmitido válido o un paquete de datos
retransmitido innecesario.
La presente invención puede usarse para permitir
la transmisión de datos de RLP sin requerir la finalización de una
toma de contacto en 3 etapas. La presente invención puede aplicarse
a cualquier sistema de comunicación que emplee la transmisión de un
flujo de bytes sobre un canal inalámbrico. La presente invención
puede aplicarse a sistemas tales como cdma2000,
W-CDMA, y EDGE, donde un flujo de bytes puede
llevarse en tramas aéreas especificadas para su uso por el sistema
de comunicación inalámbrica.
La presente invención incluye procedimientos
para negociar una estimación de RTT inicial que va a usarse para
una llamada de RLP. La estimación de RTT inicial, junto con otros
parámetros de RLP tales como esquema de NAK y parámetros de
cifrado, se negocian durante la negociación del servicio. Al
concluir la negociación del servicio, ambas partes del enlace de
comunicación de RLP están provistos de una estimación de RTT
inicial y pueden comenzar a enviar tramas de datos de RLP sin
realizar la toma de contacto en 3 etapas.
La presente invención incluye procedimientos
para que la estación base determine y actualice valores de
estimación de RTT inicial propuestos durante las negociaciones del
servicio. La presente invención también incluye procedimientos
mediante los que ambas partes de un enlace de comunicación de RLP
pueden actualizar y refinar dinámicamente las estimaciones de RTT
iniciales especificadas durante la negociación del servicio.
Las características, objetivos y ventajas de la
presente invención se harán más evidentes a partir de la
descripción detallada expuesta a continuación si se toma en
conjunción con los dibujos en los que caracteres de referencia
similares identifican correspondientemente por todo el documento y
en los que:
La figura 1 es un diagrama de un sistema de
comunicaciones de datos configurado según una realización de la
invención.
La figura 2 es un diagrama que muestra el flujo
de mensajes usado para establecer una estimación de RTT usando una
toma de contacto en 3 etapas de RLP.
La figura 3a es un diagrama que muestra el flujo
de mensajes usado para establecer una llamada de RLP originada en
la estación de abonado que tiene una estimación de RTT según una
realización de la invención.
La figura 3b es un diagrama que muestra el flujo
de mensajes usado para establecer una llamada de RLP originada en
la estación base que tiene una estimación de RTT según una
realización de la invención.
La figura 4a es un diagrama de flujo de las
etapas realizadas por una estación de abonado para inicializar y
usar un enlace de RLP según una realización de la invención.
La figura 4b es un diagrama de flujo de las
etapas realizadas por una estación base para inicializar y usar un
enlace de RLP según una realización de la invención.
La figura 5 es un diagrama de flujo de las
etapas usadas para actualizar estimaciones de RTT durante una
sesión de RLP según una realización de la invención.
La figura 6 es un diagrama de bloques de un
aparato usado para establecer y usar un enlace de RLP a través de
un canal de comunicación inalámbrica CDMA según una realización de
la invención.
La figura 1 es un diagrama de un sistema de
comunicaciones de datos configurado según una realización de la
invención. Como se muestra, la estación 102 de abonado se comunica
con la red 108 a través de un canal 106 de comunicación inalámbrica
y una estación 104 base.
La estación 102 de abonado y la estación 104
base establecen un enlace de comunicación de protocolo de enlace de
radio (RLP) para transportar flujos de bytes de datos a través del
canal 106 de comunicación inalámbrica. Los bytes de datos
intercambiados entre la estación 102 de abonado y la red 108 a
través de la estación 104 base pueden ser datagramas de protocolo
de Internet (IP) convertidos en un flujo de bytes usando protocolos
de conversión tales como el protocolo punto a punto (PPP). Tanto el
protocolo IP como el PPP se conocen bien en la técnica.
Antes de que ningún dato pueda intercambiarse
entre la estación 102 de abonado y la estación 104 base, debe
establecerse el enlace de RLP entre las dos. Establecer un enlace de
RLP incluye establecer un tiempo de ida y vuelta (RTT) que va a
usarse tanto por la estación 102 de abonado como por la estación
104 base para sincronismo de acuse de recibo negativo (NAK). En una
realización ejemplar de la presente invención, la estación 102 de
abonado envía a la estación 104 base un mensaje de petición de
servicio que especifica que la estación 102 de abonado puede
aceptar una estimación de RTT inicial enviada en un mensaje de
respuesta de servicio desde la estación 104 base. Tras recibir este
mensaje de petición de servicio, la estación 104 base envía a la
estación 102 de abonado un mensaje de respuesta de servicio que
incluye una estimación de RTT inicial que va a usarse por la
estación 102 de abonado. Después de que la estación 104 base
proporcione una estimación de RTT inicial a la estación 102 de
abonado, no es necesario realizar una toma de contacto en 3 etapas
que lleva mucho tiempo. A continuación, cuando cada parte transmite
una trama de NAK, usa el retardo entre transmitir la trama de NAK y
la recepción de una trama de retransmisión correspondiente para
actualizar su estimación de RTT para su uso en el enlace de
comunicación de RLP en curso.
La figura 2 muestra cómo una estimación de RTT
inicial se establece en enlaces de comunicación de RLP
convencionales usando la toma de contacto en 3 etapas. La estación
102 de abonado transmite tramas 202 de SYNC, tramas 204 de
SYNC/ACK, tramas 206 de ACK y tramas 208 de datos a la estación 104
base sobre el enlace inverso. La estación 104 base, a su vez,
transmite tramas 220 de SYNC, tramas 222 de SYNC/ACK, tramas 224 de
ACK y tramas 226 de datos a la estación 102 de abonado sobre el
enlace directo. En el ejemplo mostrado, el tiempo 230 de ida y
vuelta (RTT) tiene una longitud de 8 tramas. Todo el periodo 232 de
sincronización para generar una primera estimación de RTT tiene una
longitud de 12 tramas, o tiene una longitud de una vez y media el
RTT.
En el momento de iniciar la sincronización 240
de RLP, ambas partes transmiten tramas 202 y 220 de SYNC. Como se
muestra, la estación 102 de abonado transmite una trama de SYNC en
cada periodo de trama. La estación 104 base también comienza el
\hbox{proceso de sincronización transmitiendo una trama 220 de
SYNC en cada periodo de trama.}
En el momento 242, después de la mitad del
primer periodo 230 de RTT y después de que la estación 102 de
abonado haya enviado cuatro tramas 202a a 202d de SYNC, la estación
102 de abonado recibe la primera trama 220 de SYNC transmitida por
la estación 104 base. Al recibir esta primera trama 220 de SYNC, la
estación de abonado deja de transmitir tramas de SYNC y en su lugar
transmite una trama 204 de SYNC/ACK cada periodo de trama. También
en el momento 242, la estación 104 base recibe la primera trama
202a de SYNC transmitida por la estación 102 de abonado. Al recibir
esta primera trama 202a de SYNC, la estación 104 base deja de
transmitir tramas de SYNC y en su lugar transmite una trama 222 de
SYNC/ACK cada periodo de trama.
En el momento 244, la estación 102 de abonado
recibe la primera trama 222 de SYNC/ACK transmitida por la estación
104 base. Al recibir esta primera trama 222 de SYNC/ACK, la
estación de abonado deja de transmitir tramas de SYNC/ACK y en su
lugar transmite una trama 206 de ACK cada periodo de trama. También
en el momento 244, la estación 104 base recibe la primera trama 204
de SYNC/ACK transmitida por la estación 102 de abonado. Al recibir
esta primera trama 204 de SYNC/ACK, la estación 104 base deja de
transmitir tramas de SYNC/ACK y en su lugar transmite una trama 224
de ACK cada periodo de trama.
En el momento 246, la estación 102 de abonado
recibe la primera trama 224 de ACK transmitida por la estación 104
base. Al recibir esta primera trama 224 de ACK, la estación de
abonado deja de transmitir tramas de ACK y puede comenzar a enviar
tramas 208 de datos cada periodo de trama. También en el momento
246, la estación 104 base recibe la primera trama 206 de ACK
transmitida por la estación 102 de abonado. Al recibir esta primera
trama 206 de ACK, la estación 104 base deja de transmitir tramas de
ACK y puede comenzar a enviar tramas 226 de datos.
El periodo entre el momento 240 y el momento 246
tiene una longitud de una vez y media el RTT 230 usado para el
sincronismo de tramas de NAK posteriores. En otras palabras, el
momento 232 entre transmitir las primeras tramas 240 de SYNC y
transmitir las primeras tramas 246 de datos tiene una longitud de
una vez y media el RTT 230. Si el RTT 230 es de 8 tramas como se
muestra, entonces el tiempo requerido para realizar la toma de
contacto 232 en 3 etapas es de 12 tramas.
Si cualquier trama de SYNC, SYNC/ACK o ACK se
pierde por errores de comunicación durante la toma de contacto en 3
etapas, este tiempo de sincronización puede ser más largo.
Adicionalmente, tales errores de comunicación pueden provocar que
la estimación de RTT resultante sea más larga que el RTT real del
enlace de RLP. Una estimación de RTT que sea más larga que el RTT
real del enlace de RLP lleva a retardos indeseables en el envío de
tramas de NAK adicionales cuando se pierde una trama de NAK previa
(de nuevo, debido a errores de comunicación). Tales retardos pueden
provocar lentitud en el protocolo y pueden degradar el rendimiento
global del enlace de RLP.
La figura 3a es un diagrama de un flujo de
mensaje mejorado usado para establecer una estimación de RTT para
una llamada de RLP originada en la estación de abonado según una
realización de la invención. En lugar de realizar una toma de
contacto en 3 etapas, la estación 104 base envía a la estación 102
de abonado una estimación de RTT inicial para su uso en un mensaje
aéreo antes de establecer el enlace de RLP.
En la realización ejemplar, la estación 102 de
abonado comienza transmitiendo un mensaje 302 de petición de
servicio a la estación 104 base. En la realización preferida de la
invención, este mensaje incluye indicaciones de que la estación 102
de abonado soporta la recepción de un RTT inicial desde la estación
104 base sin una toma de contacto en 3 etapas. En la realización
preferida, el mensaje 302 de petición de servicio incluye
opcionalmente parámetros adicionales tales como especificar uno o
más esquemas de NAK soportados por la estación 102 de abonado. El
mensaje 302 de petición de servicio también
\hbox{incluye
opcionalmente parámetros de cifrado para el enlace de comunicación
de RLP.}
Un esquema de NAK está caracterizado por el
número de tramas de NAK enviadas después de cada expiración de un
temporizador de NAK cuando no se recibió una trama de retransmisión
correspondiente. Un ejemplo de un esquema de NAK es un esquema de
NAK 1,2,3 en el que en primer lugar se envía un NAK. Si el
temporizador de NAK asociado con esa primera "serie" de NAK
expira sin la recepción de una trama de retransmisión
correspondiente, entonces se transmite otra serie de NAK
constituida por dos tramas de NAK. Si el temporizador de NAK
asociado con la segunda serie de NAK expira sin recibir al menos una
trama de retransmisión correspondiente, entonces se transmite una
tercera serie de tres NAK. Otros posibles esquemas de NAK incluyen
un esquema 1,1,1,1,1 de cinco series, un esquema 1,2 de dos series.
Como alternativa, el mensaje 302 de petición de servicio puede
indicar un esquema que no sea de NAK apropiado para un protocolo de
RLP síncrono, como se conoce bien en la técnica.
Al recibir el mensaje 302 de petición de
servicio que indica que no hay toma de contacto en 3 etapas, la
estación 104 base transmite el mensaje 304 de respuesta de servicio
que contiene cualquier modificación adicional o propuesta de
parámetros de enlace. Al recibir el mensaje 304 de respuesta de
servicio, la estación 102 de abonado transmite un segundo mensaje
306 de petición de servicio que indica la aceptación o rechazo de
los parámetros propuestos en el mensaje 304 de respuesta de
servicio. Al recibir el mensaje 306 de petición de servicio, la
estación 104 base transmite el mensaje 308 de conexión de servicio
que indica los parámetros de enlace finales que van a usarse. El
mensaje 304 de respuesta de servicio y el mensaje 308 de conexión
de servicio pueden indicar adicionalmente esquemas de NAK o
parámetros de cifrado como se comentó anteriormente.
Después de transmitir el mensaje 308 de conexión
de servicio, la estación 104 base puede comenzar inmediatamente a
transmitir tramas 310 de datos en periodos de trama posteriores. Al
recibir el mensaje 308 de conexión de servicio, la estación 102 de
abonado puede comenzar inmediatamente a transmitir tramas 312 de
datos a la estación 104 base. Como se explicó en
IS-2000, la transmisión de las tramas 310 y 312 de
datos también puede retardarse hasta que se recibe un "momento de
acción" especificado en uno o más de los mensajes previos, o
hasta que se recibe un mensaje completo de conexión de servicio (no
mostrado) por una o ambas partes. Un experto en la técnica
apreciará que puede emplearse un parámetro de "momento de
acción" adicional o un mensaje completo de conexión de servicio
sin apartarse de la presente invención.
Al recibir el primer mensaje 302 de petición de
servicio, la estación 104 base también puede elegir enviar el
mensaje 308 de conexión de servicio inmediatamente. Este atajo hace
innecesario gastar tiempo en la transmisión del mensaje 304 de
respuesta de servicio y el mensaje 306 de petición de servicio. Un
atajo de este tipo sólo funciona cuando los parámetros propuestos
por la estación 104 base en el mensaje 308 de conexión de servicio
están soportados por la estación 102 de abonado y son apropiados
para el tipo de datos que van a intercambiarse a través del enlace
de comunicación de RLP.
En la realización preferida, si no se indica un
esquema de NAK específico en los diversos mensajes, ambas partes
adoptan un esquema de NAK por defecto predeterminado, por ejemplo
el esquema 1,2,3 descrito anteriormente. Permitir un esquema de NAK
por defecto predeterminado de este tipo conserva ancho de banda y
espacio de mensaje durante la negociación del servicio.
En la realización preferida, el formato de cada
uno de los mensajes (mensaje 302 de petición de servicio, mensajes
304 y 308 de respuesta de servicio y mensaje 308 de conexión de
servicio) es tal como se describe en la especificación
IS-2000 mencionada anteriormente. En la realización
preferida, cada uno de los mensajes incluye una sección RLP_BLOB,
que es una nueva forma de BLOB adaptada para fines de negociación
de RLP. BLOB en IS-2000 es la abreviatura de
"bloque de bits". En la realización preferida, el RLP_BLOB
incluye la estimación de RTT inicial que va a usarse y el esquema de
NAK. Un formato ejemplar para RLP_BLOB se describe en la tabla 1
a
continuación.
continuación.
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
En la tabla 1, el campo RLP_BLOB_ID indica un
número de versión del formato RLP_BLOB usado para interpretar el
resto del contenido de la sección RLP_BLOB. RTT es el valor de RTT
inicial que va a usarse en la llamada. NAK_ROUNDS_FWD indica el
número de series de NAK que va a usarse para transmisiones de RLP
de enlace directo. NAK_ROUNDS_REV indica el número de series de NAK
que va a usarse para transmisiones de RLP de enlace inverso. Como
se indica, el campo NAK_ROUNDS_REV va seguido por un número de
campos NAK_PER_ROUND_FWD correspondientes al valor en el campo
NAK_ROUNDS_FWD. El último de los campos NAK_PER_ROUND_FWD va
seguido por un número de campos NAK_PER_ROUND_REV correspondientes
al valor en el campo NAK_ROUNDS_REV. Si el campo NAK_ROUNDS_FWD
tiene un valor de cero, entonces los campos NAK PER_ROUND_REV (si
hay) seguirán inmediatamente al campo NAK_ROUNDS_REV.
\newpage
Por ejemplo, en un mensaje que indica un esquema
de NAK 1,2,3 en enlaces tanto directo como inverso, el campo
RLP_BLOB tiene un valor de NAK_ROUNDS_FWD de 3 y un valor de
NAK_ROUNDS_REV de 3. El campo NAK_ROUNDS_REV va seguido por tres
campos NAK PER_ROUND_FWD que tienen valores de 1, 2 y 3
respectivamente. El último campo NAK PER_ROUND_FWD va seguido por
tres campos NAK_PER_ROUND_REV que tienen valores de 1, 2 y 3
respectivamente.
Además de usar los tipos de mensaje descritos
anteriormente, pueden negociarse momentos de RTT iniciales,
esquemas de NAK y parámetros de cifrado usando secciones RLP_BLOB
en otros tipos de mensajes. Tales tipos de mensajes incluyen pero
no están limitados al mensaje de dirección de traspaso general
(GHDM) y el mensaje de dirección de traspaso universal (UHDM)
descrito en la IS-2000 anteriormente
mencionada.
En la realización preferida, cualquiera de los
mensajes previamente explicados que omita la sección RLP_BLOB se
interpreta como indicador de la realización de una toma de contacto
en 3 etapas. El esquema de NAK puede ser entonces uno
predeterminado por defecto o puede negociarse durante la toma de
contacto en 3 etapas.
En una realización alternativa, la estación 104
base puede reducir adicionalmente el número de mensajes requeridos
para especificar esquemas de NAK y RTT para una llamada de RLP.
Haciendo un seguimiento de las opciones soportadas en llamadas de
RLP previas a cada estación de abonado, la estación 104 base puede
comenzar una llamada transmitiendo un mensaje 308 de conexión de
servicio que especifica los parámetros de RLP que van a usarse.
Después de enviar el mensaje 308 de conexión de servicio, y sin
recibir un mensaje 302 de petición de servicio o mensaje de
respuesta de servicio desde la estación 102 de abonado, la estación
104 base comienza a transmitir datos de
usuario.
usuario.
Pueden emplearse varios procedimientos por la
estación 104 base para determinar la estimación de RTT inicial para
especificar a la estación de abonado al inicio de una llamada de
RLP. En una realización preferida, la estación 104 base obtiene la
estimación de RTT inicial añadiendo un tiempo de protección
predeterminado al promedio de valores de RTT computados durante las
tomas de contacto en 3 etapas para llamadas previas. En una
realización alternativa, la estimación de RTT inicial se configura
en la estación 104 base mediante un operador de servicio
inalámbrico.
La figura 3b es un diagrama que muestra una
variación del flujo de mensaje mejorado que se usa para establecer
una estimación de RTT para una llamada de RLP originada en la
estación base según una realización de la invención. A diferencia
de una llamada originada en la estación de abonado, en una llamada
originada en la estación base el mensaje 342 de petición de servicio
se transmite por la estación 104 base y el mensaje 344 de respuesta
de servicio se transmite por la estación 102 de abonado. El mensaje
308 de conexión de servicio tiene el mismo formato y contenido que
se explicó anteriormente. Como se muestra, la estación 104 base
comienza a transmitir tramas 310 de datos de RLP directas
inmediatamente después del mensaje 308 de conexión de servicio. Al
recibir el mensaje 308 de conexión de servicio, la estación 102 de
abonado comienza a transmitir tramas 312 de datos de RLP
inversas.
En la realización ejemplar, el mensaje 342 de
petición de servicio incluye una propuesta de que ambas partes del
enlace usan una estimación de RTT inicial en lugar de usar la toma
de contacto en 3 etapas. Como se muestra, la estación 102 de
abonado acepta la propuesta en el mensaje 344 de respuesta de
servicio, y no se realiza la toma de contacto en 3 etapas entre el
mensaje 308 de conexión de servicio y las tramas 310 y 312 de datos
de RLP.
Los mismos parámetros de RLP descritos en
conjunción con las llamadas de RLP originadas en la estación de
abonado pueden negociarse en los mensajes mostrados para una
llamada de RLP originada en la estación base. Por ejemplo, el
mensaje 342 de petición de servicio puede incluir un esquema de NAK
propuesto, que se acepta en el mensaje 344 de respuesta de
servicio.
La figura 4a es un diagrama de flujo de las
etapas realizadas por una estación de abonado para inicializar y
usar un enlace de comunicación de RLP según una realización de la
invención. Las etapas se muestran para una llamada de RLP originada
en la estación de abonado, tal como la mostrada en la figura 3a, y
para una llamada de RLP originada en la estación base, tal como la
mostrada en la figura 3b.
En una llamada 400 de RLP originada en la
estación de abonado, la estación de abonado inicia negociaciones de
servicio enviando un primer mensaje 402 de petición de servicio que
indica la capacidad de la estación de abonado para negociar una
estimación de RTT inicial durante la negociación del servicio u
otros parámetros de RLP propuestos. Entonces la estación de abonado
recibe y decodifica la respuesta 404 desde la estación base. El
tipo de la respuesta recibida se evalúa 406 para decidir si
negociar parámetros de RLP adicionales. Si el mensaje recibido fue
un mensaje de respuesta de servicio, proponiendo por ejemplo
cambios de los parámetros de RLP enviados previamente, entonces la
estación de abonado envía otro mensaje 402 de petición de servicio.
El nuevo mensaje de petición de servicio contiene un conjunto de
parámetros que o bien coinciden con o bien modifican los nuevos
parámetros de RLP propuestos por la estación base. Entonces la
estación de abonado espera hasta que recibe otra respuesta 404 al
mensaje de petición de servicio más reciente.
Finalmente, se encuentra en la etapa 406 que el
tipo de respuesta es un mensaje de conexión de servicio que
contiene los parámetros de RLP que van a usarse. El mensaje de
conexión de servicio se evalúa en la etapa 408 para determinar si
el mensaje de conexión de servicio indica la realización de una toma
de contacto en 3 etapas. Si el mensaje de conexión de servicio
indica la realización de una toma de contacto en 3 etapas, entonces
la toma de contacto en 3 etapas se realiza 410 antes de empezar a
enviar datos 412 de usuario. Si el mensaje de conexión de servicio
indica que no es necesaria una toma de contacto en 3 etapas y en su
lugar especifica una estimación de RTT inicial que va a usarse,
entonces la estación de abonado puede comenzar inmediatamente a
enviar datos 412 de
usuario.
usuario.
Como se mencionó anteriormente, el mensaje de
conexión de servicio puede indicar que no es necesaria una toma de
contacto en 3 etapas, pero no incluir estimación de RTT inicial. En
este caso, la estación de abonado usará una estimación de RTT
inicial por defecto predeterminada.
En una llamada 420 de RLP originada en la
estación base, la estación de abonado recibe y decodifica un primer
mensaje 422 de petición de servicio desde la estación base. Este
mensaje de petición de servicio podría indicar que la estación base
soporta la especificación de una estimación de RTT inicial durante
la negociación del servicio. La estación de abonado responde
enviando un mensaje 424 de respuesta de servicio, que indica que el
abonado también soporta el uso de una estimación de RTT inicial
recibida durante la negociación del servicio. Entonces la estación
de abonado recibe y decodifica el siguiente mensaje 426 de
respuesta enviado por la estación base. Se evalúa 428 el tipo de
respuesta. La respuesta puede ser otro mensaje de petición de
servicio, por ejemplo que indica una propuesta de un esquema de NAK
particular u otros parámetros de RLP adicionales. Entonces la
estación de abonado envía otro mensaje 424 de respuesta de servicio
que indica la aceptación o rechazo de los parámetros de RLP
adicionales. Cuando se recibe un mensaje de conexión de servicio,
entonces el procesamiento pasa desde la etapa 428 a la etapa 408
como se describió anteriormente.
La figura 4b es un diagrama de flujo de las
etapas realizadas por una estación base para inicializar y usar un
enlace de comunicación de RLP según una realización de la
invención. Las etapas se muestran para una llamada de RLP originada
en la estación de abonado, tal como la mostrada en la figura 3a, y
para una llamada de RLP originada en la estación base, tal como la
mostrada en la figura 3b.
En una llamada 450 de RLP originada en la
estación de abonado, la estación base recibe y decodifica un primer
mensaje 452 de petición de servicio que indica la capacidad de la
capacidad de la estación de abonado para negociar una estimación de
RTT inicial durante la negociación del servicio u otros parámetros
de RLP propuestos. A continuación, se evalúan 454 los parámetros de
RLP indicados en el mensaje de petición de servicio para determinar
si debería negociarse algún cambio de parámetro. Si es así, la
estación base envía un nuevo conjunto de parámetros de RLP
propuestos en un mensaje de respuesta de servicio y lo envía al
abonado 456.
Si los parámetros de RLP evaluados en la etapa
454 son aceptables para la estación base, la estación base envía un
mensaje 470 de conexión de servicio, que indica los parámetros de
RLP que van a usarse. Entonces la estación base decide 472,
basándose en el contenido del mensaje de conexión de servicio, si
realizar una toma de contacto en 3 etapas. Si es así, la estación
base realiza una toma de contacto 474 en 3 etapas y entonces
comienza a enviar datos de usuario. Si el mensaje de conexión de
servicio no indica ninguna toma de contacto en 3 etapas, entonces
la estación base continúa directamente desde la etapa 472 para
enviar datos 476 de usuario.
En una llamada 460 de RLP originada en la
estación base, la estación base comienza la negociación del
servicio enviando un mensaje 462 de petición de servicio a la
estación de abonado. Este mensaje de petición de servicio indica que
la estación base soporta la especificación de una estimación de RTT
inicial durante la negociación del servicio. Entonces la estación
base recibe y decodifica el mensaje de respuesta de servicio
recibido desde la estación 464 de abonado.
Se evalúan 466 los parámetros de RLP indicados
en el mensaje de respuesta de servicio para determinar si debería
negociarse algún cambio de parámetro. Si es así, la estación base
vuelve a la etapa 462 y envía un nuevo conjunto de parámetros de
RLP propuestos en un mensaje de petición de servicio. Si no, la
estación base envía un mensaje 470 de conexión de servicio y
continúa desde esa etapa como se describió anteriormente.
La figura 5 es un diagrama de flujo de las
etapas usadas para actualizar estimaciones de RTT durante una
sesión de RLP según una realización de la invención. En el caso de
la estimación de RTT inicial negociada durante la negociación del
servicio, es ventajoso para ambas partes poder ajustar sus
estimaciones de RTT según mediciones realizadas durante la llamada.
Este procedimiento usa información recopilada durante la
transmisión de NAK y retransmite tramas para actualizar la
estimación de RTT de manera dinámica durante una llamada de RLP, lo
que da como resultado un proceso de actualización de RTT que se
integra en el proceso de NAK. Para mayor comodidad, el
procedimiento se describe posteriormente desde el punto de vista de
una estación de abonado en una llamada de RLP. Un experto en la
técnica reconocerá que las realizaciones del procedimiento pueden
realizarse por la estación de abonado, la estación base, o ambas
sin alejarse de la presente invención.
El procedimiento de actualización de estimación
de RTT comienza cuando la estación de abonado detecta un hueco 502
de número de secuencia. La estación de abonado inicia un contador
504 de RTT para medir cuánto se tarda en recibir una trama de
retransmisión para la una o más tramas de NAK que van a enviarse.
La estación de abonado también inicializa un temporizador de NAK con
la estimación de RTT actual e inicia el temporizador 506 de NAK.
Entonces la estación de abonado envía el número de tramas 508 de
NAK asociadas con la primera serie en el esquema de NAK actual.
La etapa 510 evalúa si una trama de
retransmisión correspondiente se recibe antes de que el
temporizador de NAK expire. Si es así, entonces el contador de RTT
se comprueba en la etapa 520. Si el contador de RTT no está
funcionando cuando se recibe la trama de retransmisión, entonces el
contador de RTT y el temporizador de NAK se detienen según sea
necesario. Si el contador de RTT todavía está funcionando cuando se
recibe una trama de retransmisión, entonces se actualiza 522 la
estimación de RTT que está usándose para la llamada de RLP según la
nueva estimación. En una realización ejemplar, la nueva estimación
de RTT se computa realizando un promedio ponderado del valor de la
estimación de RTT antigua y la suma del temporizador de RTT y un
tiempo de protección predeterminado. Un experto en la técnica
apreciará que pueden usarse diversos otros procedimientos de
combinación sin alejarse de la presente invención. Estos otros
procedimientos incluyen reemplazar la estimación de RTT por la suma
del valor del temporizador de RTT y un tiempo de protección.
Tras actualizar la estimación 522 de RTT, el
contador de RTT y el temporizador de NAK se detienen, y el proceso
de actualización de RTT integrado en el proceso de NAK termina 540.
Si en la etapa 520 se encuentra que el temporizador de NAK no está
funcionando, entonces se salta la actualización de RTT en la etapa
522, y el procedimiento continúa directamente desde la etapa 520 a
la etapa 524.
Si, en la etapa 510, la estación de abonado
descubre que el temporizador de NAK ha expirado antes de recibirse
una trama de retransmisión correspondiente, entonces la estación de
abonado evalúa 530 cuántas series de NAK han pasado ya sin recibir
una trama de retransmisión correspondiente. El límite al número de
series de NAK en el esquema de NAK actual se determinó al comienzo
de la llamada, o bien a través del campo NAK_ROUNDS_REV mencionado
anteriormente, mediante el esquema de NAK por defecto
predeterminado mencionado anteriormente. Si el número de series de
NAK que han pasado es igual a ese límite, entonces se ha alcanzado
el límite de NAK. Si se ha alcanzado el límite de NAK, entonces no
se permiten más series de NAK para el hueco correspondiente, y la
estación de abonado continúa hasta la etapa 524.
Si, en la etapa 530, no se ha alcanzado el
límite de NAK, la estación de abonado evalúa 532 si la estimación
de RTT para la llamada de RLP se ha actualizado alguna vez. Si se
ha actualizado anteriormente, entonces la estación de abonado
detiene el contador 534 de RTT antes de iniciar el temporizador de
NAK de nuevo 506 y enviar la siguiente serie de tramas 508 de NAK.
Detener el contador de RTT antes de enviar otra serie de tramas de
NAK impide que la ambigüedad de trama de retransmisión cause
imprecisión en estimaciones de RTT. Por ejemplo, si se recibiera
una trama de retransmisión después de enviarse una segunda serie de
tramas de NAK, la estación de abonado no sabría si la trama de
retransmisión correspondía a un NAK en la primera serie o a la
segunda serie. Hacer corresponder de manera incorrecta una trama de
retransmisión de este tipo con una serie de NAK posterior llevaría
a una estimación de RTT incorrecta.
Otro problema se produce, sin embargo, al
detener el contador de RTT tras la expiración del primer
temporizador de NAK. Si, por algún motivo, la estimación de RTT
inicial especificada durante la negociación del servicio fuera
artificialmente pequeña, entonces el primer temporizador de NAK
podría expirar antes de que una primera trama de retransmisión
tenga oportunidad de llegar a la estación de abonado. En estas
circunstancias, la estimación de RTT erróneamente pequeña podría no
llegar a actualizarse nunca, y podría causar un rendimiento pobre
durante la duración de la llamada de RLP.
Este problema se resuelve en la realización
ejemplar permitiendo al contador de RTT continuar funcionando si la
estación de abonado determina 532 que la estimación de RTT no se ha
actualizado todavía. Si la estimación de RTT no se ha actualizado
todavía, entonces se salta la etapa 534, y el abonado reinicia el
temporizador 506 de NAK y envía la siguiente serie de tramas 508 de
NAK. En el peor de los casos, esto puede llevar a una estimación de
RTT actualizada excesivamente larga, pero esto se prefiere frente a
una estimación de RTT demasiado corta. Por consiguiente, en la
realización preferida, la etapa 522 da a la estimación de RTT
existente poco o ningún peso en el promedio ponderado la primera
vez que se actualiza la estimación de RTT. En una realización
alternativa, la ponderación de la estimación de RTT existente en la
primera actualización varía basándose en la cantidad por la que la
primera estimación de RTT supera la estimación de RTT existente y
en el número de series de NAK enviadas antes de la recepción de una
trama de retransmisión.
En una realización alternativa, la decisión en
la etapa 532 se basa no en si la estimación de RTT se ha
actualizado alguna vez, sino en si el hueco correspondiente al
temporizador de NAK que ha expirado es el primer hueco detectado en
la sesión de RLP. Si el hueco fue el primero detectado, entonces el
contador de RTT no se detiene antes de continuar hasta la etapa 506.
Si otros huecos se hubieran detectado anteriormente, entonces se
detiene 534 el contador de RTT antes de continuar hasta la etapa
506.
La figura 6 es un diagrama de bloques de un
aparato usado para establecer y usar un enlace de RLP a través de un
canal de comunicación inalámbrica CDMA según una realización de la
invención. Para mayor comodidad, el aparato se describe
posteriormente en cuanto a una estación de abonado. Un experto en
la técnica reconocerá que la configuración representada y sus
variaciones pueden usarse igualmente en conjunción con una estación
base inalámbrica sin alejarse de la presente invención.
El aparato mostrado incluye la interfaz 602 de
datos que puede estar conectada a un dispositivo de entrada/salida
externo, por ejemplo un terminal de visualización o un ordenador
portátil o de bolsillo. La interfaz 602 de datos puede omitirse si
la estación 102 de abonado incluye además una interfaz de usuario
interna, por ejemplo un teclado numérico y una pantalla. Por
ejemplo, la estación 102 de abonado podría ser un asistente de
datos personal (PDA) inalámbrico de CDMA que pueda intercambiar
datos con Internet y visualizarlos sobre una pantalla de cristal
líquido (LCD).
Si los datos de usuario sin procesar se reciben
a través de la interfaz 602 de datos o desde alguna otra interfaz
de entrada/salida interna, los datos se manipulan según sea
necesario mediante el procesador 604 de control. El procesador 604
de control realiza el formateo y la encapsulación de protocolo
necesarios para enviar los datos a través de un enlace inalámbrico.
En la realización preferida, el procesador 604 de control toma un
flujo de bytes recibido a través de la interfaz 602 de datos y lo
encapsula en tramas de RLP para su transmisión a través del módulo
620 de modulación de CDMA. El procesador 604 de control también
extrae datos de las tramas de RLP recibidas a través del módulo 640
de demodulación de CDMA y proporciona el flujo de bytes resultante
a la interfaz 602 de datos. Además de las tramas de RLP, el
procesador 604 de control también realiza negociación del servicio
transmitiendo y recibiendo mensajes de petición de servicio,
respuesta de servicio, conexión de servicio y otros mensajes
descritos anteriormente a través del módulo 620 de modulación de
CDMA y el módulo 640 de demodulación de CDMA.
El procesador 604 de control está conectado a y
proporciona tramas de transmisión al módulo 620 de modulador de
CDMA. En la realización preferida, el procesador 604 de control
proporciona las tramas de transmisión al módulo 610 de corrección
de errores hacia delante (FEC), que codifica las tramas basándose
en un código de FEC. El módulo 610 de FEC usa cualquiera de varias
técnicas de corrección de errores hacia delante, incluyendo
turbocodificación, codificación convolucional, u otra forma de
decisión suave o codificación de bloques. Las tramas codificadas
resultantes se proporcionan por el módulo 610 de FEC al
intercalador 612, que intercala los datos para proporcionar
diversidad temporal en la señal transmitida. El intercalador 612
utiliza cualquiera de varias técnicas de intercalación, tales como
intercalación de bloques e intercalación inversa de bits. La salida
del intercalador 612 es binaria, y se proporciona entonces al
ensanchador 614 de Walsh, que ensancha la señal usando códigos
Walsh. Tras el ensanchamiento de Walsh, la salida del ensanchador
612 de Walsh se proporciona al ensanchador 616 de pseudorruido
(PN), donde se ensancha usando códigos de PN. La salida del
ensanchador 616 de PN se proporciona entonces al transmisor 618,
donde se convierte de manera ascendente, se amplifica y se
proporciona al diplexor 650, y entonces se transmite a través de la
antena 652.
En la realización preferida, el ensanchador 616
de PN es un ensanchador de PN complejo que multiplica la salida
compleja del ensanchador 614 de Walsh mediante un código de PN
complejo. En una realización alternativa, el ensanchador 616 de PN
multiplica la salida compleja del ensanchador 614 de Walsh por un
código de PN real (no complejo).
Las señales recibidas a través de la antena 652
pasan a través del diplexor 650 y entonces se controlan en cuanto a
ganancia y se convierten de manera descendente en el receptor 638.
De aquí en adelante, las señales se proporcionan al módulo 640 de
demodulador de CDMA, dentro del cual se desensanchan por PN en el
desensanchador 636 de PN, se desensanchan por Walsh en el
desensanchador 634 de Walsh, se desintercalan en el desintercalador
632 y se decodifican por FEC en el decodificador 630 de FEC. El
decodificador 630 de FEC proporciona las tramas recibidas
resultantes al procesador 604 de control.
En la realización preferida, el desensanchador
636 de PN es un desensanchador de PN complejo que multiplica los
flujos de muestras complejas procedentes del receptor 638 mediante
un código de PN complejo. En una realización alternativa, el
desensanchador 638 de PN multiplica los flujos de muestras
complejas procedentes del receptor 638 por un código de PN real (no
complejo). El desintercalador 632 utiliza cualquiera de varias
técnicas de desintercalación, tales como desintercalación de
bloques y desintercalación inversa de bits. El decodificador 610 de
FEC usa cualquiera de varias técnicas de corrección de errores hacia
delante, incluyendo turbocodificación, codificación convolucional,
u otra forma de decisión suave o codificación de bloques.
La anterior descripción de las realizaciones
preferidas se proporciona para permitir a cualquier experto en la
técnica realizar o usar la presente invención. Las diversas
modificaciones de estas realizaciones serán fácilmente evidentes
para los expertos en la técnica, y los principios genéricos
definidos en el presente documento pueden aplicarse a otras
realizaciones sin el uso de la facultad inventiva. Por tanto, no se
pretende limitar la presente invención a las realizaciones
mostradas en el presente documento sino que se le concederá el
alcance más amplio tal como se define mediante las
reivindicaciones.
- 1.
- Un procedimiento para transmitir un flujo de bytes de información que comprende las etapas de:
- \quad
- recibir un mensaje que especifica una estimación de tiempo de ida y vuelta (RTT) de protocolo de enlace de radio (RLP); y llevar a cabo una sesión de comunicación de RLP usando dicha estimación de RTT para determinar sincronismo de mensaje de acuse de recibo negativo (NAK).
- 2.
- El procedimiento según el párrafo 1, en el que dicho mensaje es un mensaje de negociación de servicio.
- 3.
- El procedimiento según el párrafo 1, en el que dicho mensaje es un mensaje de conexión de servicio.
- 4.
- El procedimiento según el párrafo 3, en el que dicho mensaje de conexión de servicio especifica adicionalmente un esquema de NAK, y en el que dicho procedimiento para transmitir comprende además la etapa de usar dicho esquema de NAK.
- 5.
- El procedimiento según el párrafo 1, que comprende además la etapa de negociar, usando mensajes de negociación de servicio, un esquema de NAK usado durante dicha sesión de comunicación de RLP posterior.
- 6.
- El procedimiento según el párrafo 1, que comprende además la etapa de negociar, usando mensajes de negociación de servicio, parámetros de cifrado usados durante dicha sesión de comunicación de RLP posterior.
- 7.
- El procedimiento según el párrafo 1, en el que dicho mensaje es un mensaje de petición de servicio.
- 8.
- El procedimiento según el párrafo 1, en el que dicho mensaje es un mensaje de respuesta de servicio.
- 9.
- El procedimiento según el párrafo 1, en el que dicho mensaje es un mensaje de dirección de traspaso general.
- 10.
- El procedimiento según el párrafo 1, en el que dicho mensaje es un mensaje de dirección de traspaso universal.
- 11.
- Un procedimiento para transmitir un flujo de bytes de información que comprende las etapas de:
- \quad
- enviar un mensaje que especifica una estimación de tiempo de ida y vuelta (RTT) de protocolo de enlace de radio (RLP); y llevar a cabo una sesión de comunicación de RLP usando dicha estimación de RTT para determinar sincronismo de mensaje de acuse de recibo negativo (NAK).
- 12.
- El procedimiento según el párrafo 11, en el que dicho mensaje es un mensaje de negociación de servicio.
- 13.
- El procedimiento según el párrafo 11, en el que dicha estimación de RTT se especifica por un operador de una estación base y se usa para determinar sesiones de comunicación de RLP de sincronismo de mensajes de NAK entre una o más estaciones de abonado y dicha estación base.
- 14.
- El procedimiento según el párrafo 11, en el que dicho mensaje es un mensaje de conexión de servicio.
- 15.
- El procedimiento según el párrafo 11, en el que dicho mensaje es un mensaje de petición de servicio.
- 16.
- El procedimiento según el párrafo 11, en el que dicho mensaje es un mensaje de respuesta de servicio.
- 17.
- El procedimiento según el párrafo 11, en el que dicho mensaje es un mensaje de dirección de traspaso general.
- 18.
- El procedimiento según el párrafo 11, en el que dicho mensaje es un mensaje de dirección de traspaso universal.
- 19.
- El procedimiento según el párrafo 14, en el que dicho mensaje de conexión de servicio especifica además un esquema de NAK, y en el que dicho procedimiento para transmitir comprende además la etapa de usar dicho esquema de NAK.
- 20.
- El procedimiento según el párrafo 12, que comprende además la etapa de negociar, usando mensajes de negociación de servicio, un esquema de NAK usado durante dicha sesión de comunicación de RLP posterior.
- 21.
- El procedimiento según el párrafo 20, que comprende además la etapa de negociar, usando mensajes de negociación de servicio, parámetros de cifrado usados durante dicha sesión de comunicación de RLP posterior.
- 22.
- Un procedimiento para transmitir un flujo de bytes de información que comprende las etapas de:
- \quad
- establecer una primera estimación de tiempo de ida y vuelta (RTT) de protocolo de enlace de radio (RLP) durante la negociación del servicio; y
- \quad
- usar dicha primera estimación de RTT de RLP para determinar sincronismo de mensaje de acuse de recibo negativo (NAK) en una sesión de comunicación de RLP posterior.
- 23.
- El procedimiento según el párrafo 22, que comprende además las etapas de:
- \quad
- medir el retardo entre transmitir una trama de NAK y la recepción de una primera trama de retransmisión correspondiente para formar una segunda estimación de RTT de RLP; y
- \quad
- actualizar dicha primera estimación de RTT de RLP basándose en dicha segunda estimación de RTT de RLP.
- 24.
- El procedimiento según el párrafo 23, en el que dicha etapa de actualizar comprende además realizar un promedio ponderado de dicha primera estimación de RTT de RLP y dicha segunda estimación de RTT de RLP.
- 25.
- El procedimiento según el párrafo 23, en el que dicha etapa de actualizar comprende además reemplazar dicha primera estimación de RTT de RLP por dicha segunda estimación de RLP basándose en la recepción de la primera trama de retransmisión de dicha sesión de comunicación de RLP.
- 26.
- Un procedimiento para transmitir un flujo de bytes de información que comprende las etapas de:
- \quad
- realizar una toma de contacto en 3 etapas para generar una primera estimación de tiempo de ida y vuelta (RTT) asociada con una primera sesión de comunicación de protocolo de enlace de radio (RLP);
- \quad
- establecer una segunda estimación de RTT asociada con una segunda sesión de comunicación de RLP, en la que dicha segunda estimación de RTT se basa en dicha primera estimación de RTT, y en la que dicha segunda estimación de RTT se establece durante la negociación del servicio; y
- \quad
- usar dicha segunda estimación de RTT de RLP para determinar sincronismo de mensaje de acuse de recibo negativo (NAK) en una sesión de comunicación de RLP posterior.
- 27.
- El procedimiento según el párrafo 26, en el que dicha etapa de realizar una toma de contacto en 3 etapas se realiza entre una estación base y una estación de abonado y dicha etapa de establecer una segunda estimación de RTT se realiza entre dicha estación base y dicha estación de abonado.
- 28.
- El procedimiento según el párrafo 26, en el que dicha etapa de realizar una toma de contacto en 3 etapas se realiza entre una estación base y una primera estación de abonado y dicha etapa de establecer una segunda estimación de RTT se realiza entre dicha estación base y una segunda estación de abonado.
- 29.
- El procedimiento según el párrafo 26, en el que dicha segunda estimación de RTT se genera añadiendo un tiempo de protección predeterminado a dicha primera estimación de RTT.
- 30.
- Aparato de estación de abonado que comprende:
- \quad
- procesador de control para recibir un mensaje de negociación de servicio que especifica una estimación de tiempo de ida y vuelta (RTT) de protocolo de enlace de radio (RLP) y que usa dicha estimación de RTT para determinar sincronismo de mensaje de acuse de recibo negativo (NAK) en una sesión de comunicación de RLP posterior; y
- \quad
- módulo de modulación de CDMA para modular tramas de negociación de servicio y tramas de RLP proporcionadas por dicho procesador de control.
- 31.
- El aparato según la reivindicación 29, en el que dicho módulo de modulación de CDMA comprende además un ensanchador de PN para multiplicar una señal de información que comprende dichas tramas de negociación de servicio y dichas tramas de RLP por un código de PN.
- 32.
- Aparato de estación base que comprende:
- \quad
- procesador de control para transmitir un mensaje de negociación de servicio que especifica una estimación de tiempo de ida y vuelta (RTT) de protocolo de enlace de radio (RLP) a una estación de abonado y que usa dicha estimación de RTT para determinar sincronismo de mensaje de acuse de recibo negativo (NAK) en una sesión de comunicación de RLP posterior entre dicha estación base y dicha estación de abonado; y
- \quad
- módulo de modulación de CDMA para modular tramas de negociación de servicio y tramas de RLP proporcionadas por dicho procesador de control.
- 33.
- El aparato según el párrafo 32, en el que dicho módulo de modulación de CDMA comprende además un ensanchador de PN para multiplicar una señal de información que comprende dichas tramas de negociación de servicio y dichas tramas de RLP por un código de PN.
Claims (20)
1. Un aparato para transmitir un flujo de bytes
de información, caracterizado por:
- \quad
- medios (604) para establecer una primera estimación de tiempo de ida y vuelta, a la que a continuación se hace referencia como estimación de RTT, de protocolo de enlace de radio, al que a continuación se hace referencia como RLP, y
- \quad
- medios para usar dicha primera estimación de RTT de RLP para determinar un sincronismo de mensajes de acuse de recibo negativo, al que a continuación se hace referencia como NAK, en una sesión de comunicación de RLP posterior.
2. El aparato según la reivindicación 1, que
comprende además:
- \quad
- medios para medir el retardo entre transmitir una trama de NAK y recibir una primera trama de retransmisión correspondiente para formar una segunda estimación de RTT de RLP; y
- \quad
- medios para actualizar dicha primera estimación de RTT de RLP basándose en dicha segunda estimación de RTT de RLP.
3. El aparato según la reivindicación 2, en el
que dichos medios para actualizar comprenden además medios
adaptados para realizar un promedio ponderado de dicha primera
estimación de RTT de RLP y dicha segunda estimación de RTT de
RLP.
4. El aparato según la reivindicación 2, en el
que dichos medios para actualizar comprenden además medios
adaptados para reemplazar dicha primera estimación de RTT de RLP
por dicha segunda estimación de RU de RLP basándose en la recepción
de la primera trama de retransmisión de dicha sesión de
comunicación de RLP.
5. El aparato según la reivindicación 1, que
comprende además:
- \quad
- medios para realizar una toma de contacto en 3 etapas para generar la primera estimación de RTT de RLP, estando asociada dicha primera estimación de RTT de RLP con una primera sesión de comunicación de RLP;
- \quad
- medios para establecer una segunda estimación de RTT de RLP asociada con una segunda sesión de comunicación de RLP, en la que dicha segunda estimación de RTT de RLP se basa en dicha primera estimación de RTT de RLP, y en la que dicha segunda estimación de RTT de RLP se establece durante la negociación del servicio; y
- \quad
- medios para usar dicha segunda estimación de RTT de RLP para determinar el sincronismo de mensajes de NAK en una sesión de comunicación de RLP posterior.
6. El aparato según la reivindicación 5, en el
que dicha toma de contacto en 3 etapas se realiza entre una
estación (104) base y una estación (102) de abonado y dicho
establecimiento de una segunda estimación de RTT de RLP se realiza
entre dicha estación base y dicha estación de abonado.
7. El aparato según la reivindicación 5, en el
que dicha toma de contacto en 3 etapas se realiza entre una
estación (104) base y una primera estación (102) de abonado y dicho
establecimiento de una segunda estimación de RTT de RLP se realiza
entre dicha estación (104) base y una segunda estación (102) de
abonado.
8. El aparato según la reivindicación 5, en el
que dicha segunda estimación de RTT de RLP se genera sumando un
tiempo de protección predeterminado a dicha primera estimación de
RTT de RLP.
9. El aparato según la reivindicación 1, que
comprende además:
- \quad
- medios para recibir un mensaje que especifica dicha primera estimación de RTT de RLP; y
- \quad
- medios para dirigir una sesión de comunicación de RLP usando dicha primera estimación de RTT de RLP para determinar dicho sincronismo de mensajes de NAK.
10. El aparato según la reivindicación 1, que
comprende además:
- \quad
- medios para enviar un mensaje que especifica dicha primera estimación de RTT de RLP; y
- \quad
- medios para dirigir una sesión de comunicación de RLP usando dicha primera estimación de RTT de RLP para determinar dicho sincronismo de mensajes de NAK.
11. El aparato según la reivindicación 9 ó 10,
en el que dicho mensaje es un mensaje de negociación de
servicio.
12. El aparato según la reivindicación 10, en
el que dicha primera estimación de RTT de RLP se especifica por un
operador de una estación (104) base y se usa para determinar el
sincronismo de mensajes de NAK en sesiones de comunicación de RLP
entre una o más estaciones (102) de abonado y dicha estación (104)
base.
13. El aparato según la reivindicación 9 6 10,
en el que dicho mensaje es un mensaje (308) de conexión de
servicio.
14. El aparato según la reivindicación 9 ó 10,
en el que dicho mensaje es un mensaje (302, 306, 342) de petición
de servicio.
15. El aparato según la reivindicación 9 6 10,
en el que dicho mensaje es un mensaje (304, 344) de respuesta de
servicio.
16. El aparato según la reivindicación 9 ó 10,
en el que dicho mensaje es un mensaje de dirección de traspaso
general.
17. El aparato según la reivindicación 9 ó 10,
en el que dicho mensaje es un mensaje de dirección de traspaso
universal.
18. El aparato según la reivindicación 13, en
el que dicho mensaje (308) de conexión de servicio especifica
además un esquema de NAK, y que comprende además;
- \quad
- medios para usar dicho esquema de NAK en transmisiones.
19. El aparato según la reivindicación 9 u 11,
que comprende además:
- \quad
- medios para negociar, usando mensajes de negociación de servicio, un esquema de NAK usado durante dicha sesión de comunicación de RLP posterior.
20. El aparato según la reivindicación 9 ó 19,
que comprende además:
- \quad
- medios para negociar, usando mensajes de negociación de servicio, parámetros de cifrado usados durante dicha sesión de comunicación de RLP posterior.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US437417 | 1999-11-10 | ||
| US09/437,417 US6608818B1 (en) | 1999-11-10 | 1999-11-10 | Radio link protocol enhancements to reduce setup time for data calls |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2329088T3 true ES2329088T3 (es) | 2009-11-20 |
Family
ID=23736356
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES07004521T Expired - Lifetime ES2329088T3 (es) | 1999-11-10 | 2000-11-09 | Mejoras de protocolo de enlace de radio para reducir el tiempo de configuracion para llamadas de datos. |
Country Status (19)
| Country | Link |
|---|---|
| US (3) | US6608818B1 (es) |
| EP (3) | EP2053789B1 (es) |
| JP (1) | JP4842480B2 (es) |
| KR (1) | KR100688083B1 (es) |
| CN (2) | CN1423875B (es) |
| AT (3) | ATE361607T1 (es) |
| AU (1) | AU769935B2 (es) |
| BR (1) | BR0015438B1 (es) |
| CA (1) | CA2389399C (es) |
| DE (3) | DE60034698T2 (es) |
| ES (1) | ES2329088T3 (es) |
| HK (1) | HK1054640A1 (es) |
| IL (2) | IL149456A0 (es) |
| MX (1) | MXPA02004670A (es) |
| NO (1) | NO20022235L (es) |
| RU (1) | RU2259015C2 (es) |
| TW (1) | TW499804B (es) |
| UA (1) | UA68457C2 (es) |
| WO (1) | WO2001035580A1 (es) |
Families Citing this family (63)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6608818B1 (en) * | 1999-11-10 | 2003-08-19 | Qualcomm Incorporated | Radio link protocol enhancements to reduce setup time for data calls |
| 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 |
| JP3348080B1 (ja) * | 2000-07-07 | 2002-11-20 | 松下電器産業株式会社 | データ送信装置とデータ受信装置及びデータ送受信方法 |
| US7454500B1 (en) * | 2000-09-26 | 2008-11-18 | Foundry Networks, Inc. | Global server load balancing |
| US7657629B1 (en) * | 2000-09-26 | 2010-02-02 | Foundry Networks, Inc. | Global server load balancing |
| US9130954B2 (en) | 2000-09-26 | 2015-09-08 | Brocade Communications Systems, Inc. | Distributed health check for global server load balancing |
| US6976075B2 (en) * | 2000-12-08 | 2005-12-13 | Clarinet Systems, Inc. | System uses communication interface for configuring a simplified single header packet received from a PDA into multiple headers packet before transmitting to destination device |
| CN100467491C (zh) * | 2001-01-17 | 2009-03-11 | 生物质转化有限责任公司 | 植物材料破碎成为易于水解的纤维素颗粒 |
| US20020167948A1 (en) * | 2001-05-09 | 2002-11-14 | Dayong Chen | Communications methods, apparatus, computer program products and data structures using segment sequence numbers |
| GB0127481D0 (en) * | 2001-11-16 | 2002-01-09 | Koninl Philips Electronics Nv | Radio communication system |
| JP4372549B2 (ja) | 2001-11-16 | 2009-11-25 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | 無線通信システム |
| US6850769B2 (en) * | 2002-02-14 | 2005-02-01 | Qualcomm Incorporated | Method and apparatus for adaptive measurement of round-trip time in ARQ protocols and using the same for controlling flow of data in a communication system |
| US7086061B1 (en) | 2002-08-01 | 2006-08-01 | Foundry Networks, Inc. | Statistical tracking of global server load balancing for selecting the best network address from ordered list of network addresses based on a set of performance metrics |
| US7574508B1 (en) * | 2002-08-07 | 2009-08-11 | Foundry Networks, Inc. | Canonical name (CNAME) handling for global server load balancing |
| US7551613B2 (en) * | 2002-09-06 | 2009-06-23 | Motorola, Inc. | Method of supporting reactivation of a dormant session using stored service configurations |
| US20040114598A1 (en) * | 2002-12-11 | 2004-06-17 | Sivaramakrishna Veerepalli | Radio link protocol sync procedure |
| US7340615B2 (en) * | 2003-01-31 | 2008-03-04 | Microsoft Corporation | Method and apparatus for managing power in network interface modules |
| US7636321B1 (en) * | 2003-05-12 | 2009-12-22 | Sprint Communications Company L.P. | Method and system for measuring round-trip time of packets in a communications network |
| US9584360B2 (en) * | 2003-09-29 | 2017-02-28 | Foundry Networks, Llc | Global server load balancing support for private VIP addresses |
| KR100565627B1 (ko) * | 2003-10-13 | 2006-03-29 | 엘지전자 주식회사 | 이동통신 시스템에서의 고속 데이터 통신을 위한 라디오링크 프로토콜 제어 프레임 및 그것을 이용한 라디오 링크프로토콜 시퀀스의 업데이트 방법 |
| KR100606894B1 (ko) | 2004-01-19 | 2006-08-01 | 엘지노텔 주식회사 | 통신 시스템에서의 무선링크프로토콜 처리 방법 |
| US7496651B1 (en) | 2004-05-06 | 2009-02-24 | Foundry Networks, Inc. | Configurable geographic prefixes for global server load balancing |
| US7584301B1 (en) | 2004-05-06 | 2009-09-01 | Foundry Networks, Inc. | Host-level policies for global server load balancing |
| US7379440B2 (en) * | 2004-05-12 | 2008-05-27 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for reducing setup latency in one or more service instances |
| US8855572B2 (en) | 2004-06-16 | 2014-10-07 | Qualcomm Incorporated | Method and apparatus for link control in wireless communications |
| RU2364035C2 (ru) * | 2004-06-16 | 2009-08-10 | Квэлкомм Инкорпорейтед | Способ и устройство управления линией связи в системе беспроводной связи |
| WO2006002658A1 (en) * | 2004-06-29 | 2006-01-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Packet-based data processing technique |
| US20060009159A1 (en) * | 2004-07-09 | 2006-01-12 | Leung Hung F | Protocol layer analysis in mobile device testing |
| JP4762619B2 (ja) * | 2004-07-14 | 2011-08-31 | パナソニック株式会社 | 通信端末装置及び無線通信方法 |
| US7423977B1 (en) * | 2004-08-23 | 2008-09-09 | Foundry Networks Inc. | Smoothing algorithm for round trip time (RTT) measurements |
| JP2006067099A (ja) * | 2004-08-25 | 2006-03-09 | Fujitsu Ltd | 伝送時間測定方法、伝送制御方法及び伝送時間測定機能を備えた移動通信システム |
| CN100396021C (zh) * | 2004-09-30 | 2008-06-18 | 华为技术有限公司 | 避免级联组网往返时间测量误差累积的方法 |
| US7778278B2 (en) * | 2005-03-28 | 2010-08-17 | Cisco Technology, Inc. | System and method for implementing dynamic suppression and recreation of suppressed data in a communications environment |
| KR100703441B1 (ko) * | 2005-04-21 | 2007-04-03 | 삼성전자주식회사 | 통신 환경에 적응적인 라운드 트립 타임을 결정하는 데이터통신 시스템 및 방법 |
| KR101233150B1 (ko) * | 2005-07-19 | 2013-02-15 | 엘지전자 주식회사 | 서비스 연결 설정 및 제어 방법 |
| US9247467B2 (en) * | 2005-10-27 | 2016-01-26 | Qualcomm Incorporated | Resource allocation during tune-away |
| US8229433B2 (en) * | 2005-10-27 | 2012-07-24 | Qualcomm Incorporated | Inter-frequency handoff |
| US8068835B2 (en) | 2005-10-27 | 2011-11-29 | Qualcomm Incorporated | Tune-away and cross paging systems and methods |
| US8134977B2 (en) | 2005-10-27 | 2012-03-13 | Qualcomm Incorporated | Tune-away protocols for wireless systems |
| US7508791B2 (en) * | 2005-10-31 | 2009-03-24 | Kyocera Corporation | Wireless communication coding and transmission systems and methods |
| CN100596050C (zh) * | 2006-03-27 | 2010-03-24 | 阿里巴巴集团控股有限公司 | 一种可靠的系统间消息通知方法和系统 |
| KR100846344B1 (ko) * | 2007-01-05 | 2008-07-15 | 삼성전자주식회사 | 이동통신 시스템에서 전송 제어 프로토콜의 전송 지연을줄이기 위한 장치 및 방법 |
| HUE045900T2 (hu) * | 2007-08-17 | 2020-01-28 | Ericsson Telefon Ab L M | Rádiófrekvenciás csatornák számozása |
| GB2453344B (en) * | 2007-10-04 | 2012-01-18 | Toumaz Technology Ltd | Wireless transmission method and apparatus |
| US7743719B2 (en) * | 2008-11-14 | 2010-06-29 | Cnh Canada, Ltd. | Sectional distribution of granular product |
| CN102246453B (zh) * | 2008-12-16 | 2015-02-25 | 黑莓有限公司 | 由用户设备执行的用于检测harq消息的方法和用户设备 |
| GB2478687B (en) * | 2008-12-22 | 2014-05-21 | Ltn Global Communications Inc | A system and method for recovery of packets in overlay networks |
| US8315278B2 (en) * | 2008-12-23 | 2012-11-20 | Nokia Corporation | Network synchronization method |
| US8050246B2 (en) * | 2009-03-03 | 2011-11-01 | Adc Telecommunications, Inc. | Range extension for time division duplex systems |
| 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 |
| US8549148B2 (en) | 2010-10-15 | 2013-10-01 | Brocade Communications Systems, Inc. | Domain name system security extensions (DNSSEC) for global server load balancing |
| US9223583B2 (en) * | 2010-12-17 | 2015-12-29 | Oracle International Corporation | Proactive token renewal and management in secure conversations |
| US8665729B2 (en) * | 2011-07-29 | 2014-03-04 | Mediatek Inc. | Method for performing radio link control with round trip time awareness, and associated apparatus |
| JP5945007B2 (ja) * | 2012-01-29 | 2016-07-05 | アルカテル−ルーセント | 時分割複信無線通信システムの高干渉インジケータ（ｈｉｉ） |
| US10187309B1 (en) | 2012-08-20 | 2019-01-22 | Amazon Technologies, Inc. | Congestion mitigation in networks using flow-based hashing |
| US10182010B1 (en) | 2012-08-20 | 2019-01-15 | Amazon Technologies, Inc. | Flow collision avoidance |
| US9013998B1 (en) * | 2012-08-20 | 2015-04-21 | Amazon Technologies, Inc. | Estimating round-trip times to improve network performance |
| US9432458B2 (en) | 2013-01-09 | 2016-08-30 | Dell Products, Lp | System and method for enhancing server media throughput in mismatched networks |
| US10038741B1 (en) | 2014-11-24 | 2018-07-31 | Amazon Technologies, Inc. | Selective enabling of sequencing for encapsulated network traffic |
| US9509616B1 (en) | 2014-11-24 | 2016-11-29 | Amazon Technologies, Inc. | Congestion sensitive path-balancing |
| US10645448B2 (en) * | 2017-05-15 | 2020-05-05 | Omnivision Technologies, Inc. | Buffer-aware transmission rate control for real-time video streaming system |
| US10367595B1 (en) * | 2018-04-18 | 2019-07-30 | Huawei Technologies Co., Ltd. | Apparatus and receiver for receiving RF analog signals |
| EP4264993A1 (en) * | 2020-12-18 | 2023-10-25 | Nokia Technologies Oy | Access network with service-based interfaces |
Family Cites Families (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06508008A (ja) * | 1991-06-12 | 1994-09-08 | ヒューレット・パッカード・カンパニー | パケットベースネットワークをテストするための方法および装置 |
| JPH0528072A (ja) * | 1991-07-18 | 1993-02-05 | Nec Corp | 計算機システム |
| IL104412A (en) * | 1992-01-16 | 1996-11-14 | Qualcomm Inc | Method and apparatus for the formatting of data for transmission |
| US5446736A (en) * | 1993-10-07 | 1995-08-29 | Ast Research, Inc. | Method and apparatus for connecting a node to a wireless network using a standard protocol |
| SE515752C2 (sv) * | 1995-08-28 | 2001-10-08 | Telia Ab | Direktåtkomst i OFDM-system |
| FI101332B1 (fi) * | 1995-12-18 | 1998-05-29 | Nokia Telecommunications Oy | Epäjatkuvalähetys monikanavaisessa suurinopeuksisessa datasiirrossa |
| JP3476985B2 (ja) * | 1995-12-28 | 2003-12-10 | 株式会社東芝 | パケット通信システムおよびパケット通信制御方法 |
| US5936940A (en) * | 1996-08-22 | 1999-08-10 | International Business Machines Corporation | Adaptive rate-based congestion control in packet networks |
| JP2969559B2 (ja) * | 1997-02-05 | 1999-11-02 | 株式会社超高速ネットワーク・コンピュータ技術研究所 | データ転送フロー制御方式 |
| 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 |
| JP2001524290A (ja) | 1997-05-06 | 2001-11-27 | インターメック テクノロジーズ コーポレイション | 設定可能なタイマを使用するハンドヘルド装置で、低信頼度のトランスポート層を利用した高信頼性のデータ処理方法及びその装置 |
| US6119235A (en) * | 1997-05-27 | 2000-09-12 | Ukiah Software, Inc. | Method and apparatus for quality of service management |
| US6473425B1 (en) * | 1997-10-02 | 2002-10-29 | Sun Microsystems, Inc. | Mechanism for dispatching packets via a telecommunications network |
| KR100248080B1 (ko) * | 1997-10-06 | 2000-03-15 | 정선종 | 다자간 멀티미디어 통신에서의 에러제어 방법 |
| US6115749A (en) * | 1997-10-14 | 2000-09-05 | Lucent Technologies Inc. | System and method for using a window mechanism to control multicast data congestion |
| EP1032647B1 (en) * | 1997-11-26 | 2006-03-29 | Universal Preservation Technologies, Inc. | Preservation of sensitive biological samples by vitrification |
| US6118765A (en) | 1998-01-13 | 2000-09-12 | Qualcomm Inc. | System method and computer program product for eliminating unnecessary retransmissions |
| JP3388575B2 (ja) * | 1998-02-03 | 2003-03-24 | 日本電信電話株式会社 | 無線通信装置およびプログラム記録媒体 |
| US6275471B1 (en) * | 1998-05-12 | 2001-08-14 | Panasonic Technologies, Inc. | Method for reliable real-time multimedia streaming |
| US6421387B1 (en) * | 1998-05-15 | 2002-07-16 | North Carolina State University | Methods and systems for forward error correction based loss recovery for interactive video transmission |
| US6330451B1 (en) * | 1998-10-13 | 2001-12-11 | Nortel Networks Limited | Selectively delaying data communications in a wireless communication system to provide voice communications capacity |
| EP0996248A1 (en) * | 1998-10-21 | 2000-04-26 | Telefonaktiebolaget L M Ericsson (Publ) | ARQ protocol with packet-based reliability level setting |
| US6424625B1 (en) * | 1998-10-28 | 2002-07-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for discarding packets in a data network having automatic repeat request |
| US6289224B1 (en) * | 1998-10-29 | 2001-09-11 | Motorola, Inc. | Method and apparatus for starting an acknowledgment timer |
| US6601098B1 (en) * | 1999-06-07 | 2003-07-29 | International Business Machines Corporation | Technique for measuring round-trip latency to computing devices requiring no client-side proxy presence |
| US6405337B1 (en) * | 1999-06-21 | 2002-06-11 | Ericsson Inc. | Systems, methods and computer program products for adjusting a timeout for message retransmission based on measured round-trip communications delays |
| US6208620B1 (en) * | 1999-08-02 | 2001-03-27 | Nortel Networks Corporation | TCP-aware agent sublayer (TAS) for robust TCP over wireless |
| US6608818B1 (en) | 1999-11-10 | 2003-08-19 | Qualcomm Incorporated | Radio link protocol enhancements to reduce setup time for data calls |
-
1999
- 1999-11-10 US US09/437,417 patent/US6608818B1/en not_active Expired - Lifetime
-
2000
- 2000-09-11 UA UA2002053783A patent/UA68457C2/uk unknown
- 2000-11-09 DE DE60034698T patent/DE60034698T2/de not_active Expired - Lifetime
- 2000-11-09 ES ES07004521T patent/ES2329088T3/es not_active Expired - Lifetime
- 2000-11-09 JP JP2001537209A patent/JP4842480B2/ja not_active Expired - Lifetime
- 2000-11-09 MX MXPA02004670A patent/MXPA02004670A/es active IP Right Grant
- 2000-11-09 CN CN008172102A patent/CN1423875B/zh not_active Expired - Lifetime
- 2000-11-09 AT AT00977119T patent/ATE361607T1/de not_active IP Right Cessation
- 2000-11-09 HK HK03106827.3A patent/HK1054640A1/zh unknown
- 2000-11-09 DE DE60042664T patent/DE60042664D1/de not_active Expired - Lifetime
- 2000-11-09 DE DE60045172T patent/DE60045172D1/de not_active Expired - Lifetime
- 2000-11-09 WO PCT/US2000/030834 patent/WO2001035580A1/en not_active Ceased
- 2000-11-09 BR BRPI0015438-5A patent/BR0015438B1/pt active IP Right Grant
- 2000-11-09 IL IL14945600A patent/IL149456A0/xx not_active IP Right Cessation
- 2000-11-09 AU AU14801/01A patent/AU769935B2/en not_active Ceased
- 2000-11-09 EP EP09001512A patent/EP2053789B1/en not_active Expired - Lifetime
- 2000-11-09 EP EP07004521A patent/EP1806876B1/en not_active Expired - Lifetime
- 2000-11-09 KR KR1020027005889A patent/KR100688083B1/ko not_active Expired - Fee Related
- 2000-11-09 RU RU2002115291/09A patent/RU2259015C2/ru active
- 2000-11-09 CA CA2389399A patent/CA2389399C/en not_active Expired - Lifetime
- 2000-11-09 CN CNA2007103009830A patent/CN101179365A/zh active Pending
- 2000-11-09 AT AT09001512T patent/ATE486429T1/de not_active IP Right Cessation
- 2000-11-09 EP EP00977119A patent/EP1228602B1/en not_active Expired - Lifetime
- 2000-11-09 AT AT07004521T patent/ATE438240T1/de not_active IP Right Cessation
-
2001
- 2001-01-10 TW TW089123852A patent/TW499804B/zh not_active IP Right Cessation
-
2002
- 2002-05-10 NO NO20022235A patent/NO20022235L/no not_active Application Discontinuation
-
2003
- 2003-06-19 US US10/600,146 patent/US7333440B2/en not_active Expired - Lifetime
-
2007
- 2007-09-16 IL IL185959A patent/IL185959A/en not_active IP Right Cessation
- 2007-12-21 US US11/962,519 patent/US8295190B2/en not_active Expired - Fee Related
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2329088T3 (es) | Mejoras de protocolo de enlace de radio para reducir el tiempo de configuracion para llamadas de datos. | |
| JP5074355B2 (ja) | シンボル累算を用いた時間的効率性のある再送信の方法及び装置 | |
| CN100382640C (zh) | 使用动态解码的改进的反馈系统 | |
| JP4629434B2 (ja) | データ送信のための改善されたフィードバック | |
| US7542482B2 (en) | Method and apparatus for message segmentation in a wireless communication system | |
| KR101038265B1 (ko) | 역방향 링크 자동 반복 요청 | |
| JP2009268118A (ja) | 無線通信システムのためのブロードキャストメッセージのセグメント化 | |
| US6771700B1 (en) | Method and apparatus for minimizing total transmission energy in a communication system employing retransmission of frame received in error | |
| CA2537443C (en) | Method and apparatus for acknowledging reverse link transmissions in a communications system | |
| CN102804669B (zh) | 延迟自动重复请求（arq）确认 | |
| ES2353634T3 (es) | Mejoras del protocolo de enlace de radio para reducir el tiempo de configuración para llamadas de datos. | |
| HK1118150A (en) | Radio link protocol enhancements to reduce setup time for data calls | |
| HK1082627B (en) | Improved feedback system using dynamic decoding | |
| KR20050114180A (ko) | 광대역 무선 접속 시스템에서 복합 자동 재전송 제어정보를 전송하기 위한 맵 정보 요소 전송 방법 |