ES2353634T3 - Mejoras del protocolo de enlace de radio para reducir el tiempo de configuración para llamadas de datos. - Google Patents

Abstract

Un aparato para transmitir un flujo de bytes de información, que comprende: medios para recibir un mensaje que especifica una estimación del tiempo de ida y vuelta, llamado RTT en lo sucesivo, del protocolo de enlace de radio, llamado RLP en lo sucesivo; y medios para conducir una sesión de comunicación del RLP usando dicha estimación del RTT para determinar la temporización de mensajes de acuse de recibo negativo, llamado NAK en lo sucesivo.

Description

ANTECEDENTES DE LA INVENCIÓN

I. Campo de la invención

La presente invención se refiere a comunicaciones inalámbricas. Más específicamente, 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 del protocolo de enlace de radio (RLP).

II. Descripción de la técnica relacionada

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 del sistema. En la tecnología se conocen otras técnicas de sistemas de comunicación de acceso múltiple, tales como el acceso múltiple por división de tiempo (TDMA), el acceso múltiple por división de frecuencia (FDMA) y esquemas de modulación en AM (modulación de amplitud) tales como el de banda lateral única comprimida 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 el documento TIA/EIA/IS-95-B de la Asociación de la Industria de Telecomunicaciones, titulado “MOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUALMODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEMS” [“ESTÁNDAR DE COMPATIBILIDAD ENTRE ESTACIÓN MÓVIL Y ESTACIÓN BASE PARA SISTEMAS CELULARES DE ESPECTRO EXTENDIDO, BANDA ANCHA Y MODALIDAD DUAL”], y al que a continuación en el presente documento se hace referencia como IS-95. Además, en los Estados Unidos, en el documento PN-4431 de la Asociación de la Industria de Telecomunicaciones, a publicarse como TIA/EIA/IS-2000-5, titulado “UPPER LAYER (LAYER 3) SIGNALING STANDARD FOR cdma2000 SPREAD SPECTRUM SYSTEMS” [“ESTÁNDAR DE SEÑALIZACIÓN DE CAPA SUPERIOR (CAPA 3) PARA SISTEMAS cdma2000 DE ESPECTRO EXTENDIDO”], con fecha del 11 de julio de 1999 y al que a continuación en el presente documento se hace referencia como IS-2000, se ha propuesto una nueva norma para sistemas de comunicaciones de acceso múltiple por división de código.

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” [“La presentación candidata cdma2000 de Tecnología de Transmisión por Radio de la Unión Internacional de Telecomunicación – Sector de Comunicación por Radio”]. 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” [“La presentación candidata Acceso por Radio Terrestre de UMTS (UTRA) de Tecnología de Transmisión por Radio de la Unión Internacional de Telecomunicación – Sector de Comunicación por Radio”], que también se conoce como “CDMA de banda ancha” y a la que a continuación en el presente documento se hace referencia como W-CDMA. Una tercera propuesta la emitió el Grupo de Tareas Estadounidense 8/1, titulada “The UWC-136 Candidate Submission” [“La presentación candidata UWC-136”], a la 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.

La IS-95 se optimizó originalmente para la transmisión de tramas de voz de tasa de transmisión variable. Para dar soporte a 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 razonablemente constante y mínimo. Por este motivo, los sistemas IS-95 están diseñados con potentes codificadores de señales de voz y protocolos de corrección de errores hacia delante (FEC) que están diseñados para responder de manera airosa a los errores de trama de voz. Los protocolos de control de errores que requieren procedimientos de retransmisión de tramas añaden retardos inaceptables a la transmisión de voz, por lo que no están incluidos en el diseño de la especificación IS-95.

Las optimizaciones que hacen que la especificación IS-95 autónoma 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 preponderante de los protocolos usados en una red IP, se permiten retardos de transmisión prácticamente infinitos para garantizar una transmisión libre de errores. El TCP usa retransmisiones de datagramas de IP, como se denomina comúnmente a los paquetes de IP, para proporcionar esta fiabilidad de transporte. Véase también el documento WO 9937071 para la retransmisión del TCP.

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 como para caber en una serie de tramas de IS-95, debería recibirse sin errores una serie entera de tramas IS-95 para que el datagrama de IP único fuera útil para el 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. El documento TIA/EIA/IS-707-A, titulado “DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS” [“OPCIONES DEL SERVICIO DE DATOS PARA SISTEMAS DE ESPECTRO EXTENDIDO”], al 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.

El protocolo de enlace de radio (RLP) se describe en el documento TIA/EIA/IS-707-A.8, titulado “DATA SERVICE OPTIONS FOR SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOL TYPE 2” [“OPCIONES DEL SERVICIO DE DATOS PARA SISTEMAS DE ESPECTRO EXTENDIDO: TIPO 2 DEL PROTOCOLO DE ENLACE DE RADIO”], al 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 tramas IS-95. RLP es de una clase de protocolos de control de errores conocidos como protocolos ARQ basados en NAK (Acuse negativo de recibo), que se conocen bien en la técnica. El RLP de 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 habitualmente por encima de la capa del RLP. Los datagramas de IP, por ejemplo, se convierten habitualmente en un flujo de bytes del protocolo punto a punto (PPP) antes de presentarse como un flujo de bytes a la capa del protocolo RLP. Como la capa del 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, todas estas 25 tramas tendrían que recibirse sin errores 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), o sea 22%. Esta es una tasa de errores muy alta en comparación con la mayor parte de las redes usadas para llevar tráfico sobre el Protocolo de Internet. El 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 del tiempo de ida y vuelta (RTT) determinado al inicio de una sesión del RLP. La determinación del RTT en versiones existentes del RLP requiere una interacción inicial 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 interacción inicial en 3 etapas. Esta interacción inicial en 3 etapas consume tiempo que de lo contrario podría usarse para transmitir datos.

En una configuración típica de servicios de datos, un ordenador portátil está conectado con un módem inalámbrico que se 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 cambio, el ordenador habitualmente 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 retransmite 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 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 deshacen una sesión de RLP tras un periodo predeterminado de inactividad del 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 a 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.

Establecer una nueva sesión de RLP para enviar 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 interacción inicial en 3 etapas para establecer una sesión de RLP. Por lo tanto es sumamente deseable minimizar la sobrecarga requerida para establecer una sesión de RLP, incluso minimizar o eliminar el retardo inherente en la interacción inicial en 3 etapas.

RESUMEN DE LA INVENCIÓN

La presente invención puede usarse para permitir la transmisión de datos de RLP sin requerir la finalización de una interacción inicial 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 por 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 parte del sistema de comunicación inalámbrica.

La presente invención incluye procedimientos para negociar una estimación del RTT inicial que va a usarse para una llamada del RLP. La estimación del RTT inicial, junto con otros parámetros del 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 dotadas de una estimación del RTT inicial y pueden comenzar a enviar tramas de datos del RLP sin realizar la interacción inicial en 3 etapas.

La presente invención incluye procedimientos para que la estación base determine y actualice los valores de estimación del RTT inicial propuestos durante las negociaciones del servicio. La presente invención también incluye procedimientos mediante los cuales ambas partes de un enlace de comunicación de RLP pueden actualizar y refinar dinámicamente las estimaciones iniciales del RTT especificadas durante la negociación del servicio.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

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 cuando se considere conjuntamente con los dibujos, en los que caracteres de referencia similares identifican correspondientemente por todo el documento y en los que:

la FIG. 1 es un diagrama de un sistema de comunicaciones de datos configurado según una realización de la invención.

La FIG. 2 es un diagrama que muestra el flujo de mensajes usado para establecer una estimación del RTT usando una interacción inicial en 3 etapas del RLP.

La FIG. 3a es un diagrama que muestra el flujo de mensajes usado para establecer una llamada del RLP originada en una estación de abonado, que tiene una estimación del RTT según una realización de la invención.

La FIG. 3b es un diagrama que muestra el flujo de mensajes usado para establecer una llamada del RLP originada en una estación base, que tiene una estimación del RTT según una realización de la invención.

La FIG. 4a es un diagrama de flujo de las etapas realizadas por una estación de abonado para inicializar y usar un enlace del RLP según una realización de la invención.

La FIG. 4b es un diagrama de flujo de las etapas realizadas por una estación base para inicializar y usar un enlace del RLP según una realización de la invención.

La FIG. 5 es un diagrama de flujo de las etapas usadas para actualizar estimaciones del RTT durante una sesión del RLP según una realización de la invención.

La FIG. 6 es un diagrama en bloques de un aparato usado para establecer y usar un enlace del RLP a través de un canal de comunicación inalámbrica CDMA según una realización de la invención.

DESCRIPCIÓN DETALLADA DE LAS REALIZACIONES PREFERIDAS

La FIG. 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 base 104.

La estación 102 de abonado y la estación base 104 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 base 104 pueden ser datagramas del 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 base 104, debe establecerse el enlace del RLP entre las dos. Establecer un enlace del 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 base 104 para el sincronismo del 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 base 104 un Mensaje de Petición de Servicio que especifica que la estación 102 de abonado puede aceptar una estimación del RTT inicial enviada en un Mensaje de Respuesta de Servicio desde la estación base 104. Tras recibir este Mensaje de Petición de Servicio, la estación base 104 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 ser usada por la estación 102 de abonado. Después de que la estación base 104 proporcione una estimación de RTT inicial a la estación 102 de abonado, no es necesario realizar una interacción inicial en 3 etapas, que lleva mucho tiempo. A continuación, cuando cada parte transmite una trama de NAK, usa el retardo entre la transmisión de 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 del RLP en curso.

La FIG. 2 muestra cómo una estimación de RTT inicial se establece en enlaces de comunicación convencionales del RLP usando la interacción inicial 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 base 104 por el enlace inverso. La estación base 104, 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 por 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 sea, una longitud de una vez y media el RTT.

En el momento de iniciar la sincronización 240 del 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 base 104 también comienza el 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 base 104. 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 base 104 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 base 104 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 base 104. 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 base 104 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 base 104 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 base 104. 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 base 104 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 base 104 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 232 usado para el sincronismo de tramas de NAK posteriores. En otras palabras, el tiempo entre la transmisión de las primeras tramas 240 de SYNC y la transmisión de las primeras tramas 246 de datos tiene una longitud de una vez y media el RTT 232. Si el RTT 230 es de 8 tramas, como se muestra, entonces el tiempo requerido para realizar la interacción inicial 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 interacción inicial 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 caudal global del enlace de RLP.

La FIG. 3a es un diagrama de un flujo de mensajes mejorado usado para establecer una estimación del RTT para una llamada del RLP originada en la estación de abonado según una realización de la invención. En lugar de realizar una interacción inicial en 3 etapas, la estación base 104 envía a la estación 102 de abonado una estimación del RTT inicial para su uso en un mensaje aéreo antes de establecer el enlace del 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 base 104. En la realización preferida de la invención, este mensaje incluye indicaciones de que la estación 102 de abonado da soporte a la recepción de un RTT inicial desde la estación base 104 sin una interacción inicial en 3 etapas. En la realización preferida, el Mensaje 302 de Petición de Servicio incluye optativamente parámetros adicionales tales como especificar uno o más esquemas de NAK con soporte por parte de la estación 102 de abonado. El Mensaje 302 de Petición de Servicio también incluye optativamente parámetros de cifrado para el enlace de comunicación del 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 correspondiente trama de retransmisión. 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 a esa primera “ronda” de NAK expira sin la recepción de una correspondiente trama de retransmisión, entonces se transmite otra ronda de NAK constituida por dos tramas de NAK. Si el temporizador de NAK asociado a la segunda ronda de NAK expira sin recibir al menos una correspondiente trama de retransmisión, entonces se transmite una tercera ronda de tres NAK. Otros posibles esquemas de NAK incluyen un esquema 1, 1, 1, 1, 1 de cinco rondas y un esquema 1, 2 de dos rondas. Como alternativa, el Mensaje 302 de Petición de Servicio puede indicar un esquema sin NAK apropiado para un protocolo 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 interacción inicial en 3 etapas, la estación base 104 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 base 104 transmite el Mensaje 308 de Conexión de Servicio que indica los parámetros de enlace finales que van a usarse. Los Mensajes 304 y 308 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 ha expuesto anteriormente.

Después de transmitir el Mensaje 308 de Conexión de Servicio, la estación base 104 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 base 104. Como se expone en IS-2000, la transmisión de las tramas 310 y 312 de datos también puede retardarse hasta un “momento de acción” especificado en uno o más de los mensajes previos,

o hasta que sea recibido un Mensaje de Conexión de Servicio Completa (no mostrado) por una

o ambas partes. Un experto en la técnica apreciará que puede emplearse un parámetro adicional de “momento de acción” o un Mensaje de Conexión de Servicio Completo sin apartarse de la presente invención.

Al recibir el primer Mensaje 302 de Petición de Servicio, la estación base 104 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 base 104 en el Mensaje 308 de Conexión de Servicio tienen soporte en 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 del RLP.

5 En la realización preferida, si no se indica ningún esquema de NAK específico en los diversos mensajes, ambas partes suponen un esquema predeterminado de NAK por omisión, por ejemplo, el esquema 1, 2, 3 descrito anteriormente. Permitir tal esquema predeterminado de NAK por omisión conserva espacio de mensaje y ancho de banda durante la negociación del servicio.

10 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 precitada especificación IS-2000. En la realización preferida, cada uno de los mensajes incluye una sección RLP_BLOB, que es una

15 nueva forma de BLOB adaptada para fines de negociación del 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.

20 Tabla 1

Campo

Longitud (bits)

RLP_BLOB_ID

3

RTT

4

NAK_ROUNDS_FWD

3

NAK_ROUNDS_REV

3

NAK_ROUNDS_FWD repeticiones de lo siguiente:

NAK_PER_ROUND_FWD

3

NAK_ROUNDS_REV repeticiones de lo siguiente:

NAK_PER_ROUND_REV

3

En la tabla 1, el campo RLP_BLOB_ID indica un número de versión del formato de 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 rondas de NAK que va a usarse para transmisiones del RLP del enlace directo.

NAK_ROUNDS_REV indica el número de rondas de NAK que va a usarse para transmisiones del RLP del enlace inverso. Como se indica, el campo NAK_ROUNDS_REV va seguido por un número de NAK_PER_ROUND_FWD campos, correspondientes al valor en el campo NAK_ROUNDS_FWD. El último de los NAK_PER_ROUND_FWD campos va seguido por un número de NAK_PER_ROUND_REV campos correspondientes al valor en el campo NAK_ROUNDS_REV. Si el campo NAK_ROUNDS_FWD tiene un valor de cero, entonces los NAK_PER_ROUND_REV campos (si hubiera alguno) seguirán inmediatamente al campo NAK_ROUNDS_REV.

Por ejemplo, en un mensaje que indica un esquema de NAK 1, 2, 3 en ambos enlaces, directo e 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 tiempos de RTT, esquemas de NAK y parámetros de cifrado iniciales, usando secciones RLP_BLOB en otros tipos de mensajes. Tales tipos de mensajes incluyen, pero no están limitados a, el Mensaje de Dirección de Traspaso General (GHDM) y el Mensaje de Dirección de Traspaso Universal (UHDM) descrito en el precitado IS-2000.

En la realización preferida, cualquiera de los mensajes previamente expuestos que omita la sección RLP_BLOB se interpreta como indicador de la realización de una interacción inicial en 3 etapas. El esquema de NAK puede ser entonces uno predeterminado por omisión, o puede negociarse durante la interacción inicial en 3 etapas.

En una realización alternativa, la estación base 104 puede reducir adicionalmente el número de mensajes requeridos para especificar esquemas de NAK y RTT para una llamada del RLP. Haciendo un seguimiento de las opciones con soporte en llamadas previas del RLP a cada estación de abonado, la estación base 104 puede comenzar una llamada transmitiendo un Mensaje 308 de Conexión de Servicio que especifica los parámetros del 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 base 104 comienza a transmitir datos de usuario.

Pueden ser empleados varios procedimientos por la estación base 104 a fin de determinar la estimación del RTT inicial a especificar a una estación de abonado al inicio de una llamada del RLP. En una realización preferida, la estación base 104 obtiene la estimación de RTT inicial añadiendo un tiempo de protección predeterminado al promedio de los valores de RTT computados durante las interacciones iniciales en 3 etapas para llamadas previas. En una realización alternativa, la estimación del RTT inicial es configurada en la estación base 104 por un operador del servicio inalámbrico.

La FIG. 3b es un diagrama que muestra una variación del flujo de mensajes mejorado que se usa para establecer una estimación del RTT para una llamada del RLP originada en una 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 es transmitido por la estación base 104 y el Mensaje 344 de Respuesta de Servicio es transmitido por la estación 102 de abonado. El Mensaje 308 de Conexión de Servicio tiene el mismo formato y contenido anteriormente expuestos. Como se muestra, la estación base 104 comienza a transmitir tramas directas 310 de datos del RLP 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 inversas 312 de datos del RLP.

En la realización ejemplar, el Mensaje 342 de Petición de Servicio incluye una propuesta de que ambas partes del enlace usen una estimación de RTT inicial en lugar de usar la interacción inicial 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 interacción inicial en 3 etapas entre el Mensaje 308 de Conexión de Servicio y las tramas 310 y 312 de datos del RLP.

Los mismos parámetros del RLP descritos conjuntamente con las llamadas del RLP originadas en la estación de abonado pueden negociarse en los mensajes mostrados para una llamada del RLP originada en una 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 FIG. 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 del RLP según una realización de la invención. Las etapas se muestran para una llamada del RLP originada en la estación de abonado, tal como la mostrada en la FIG. 3a, y para una llamada del RLP originada en la estación base, tal como la mostrada en la FIG. 3b.

En una llamada 400 del 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 del RTT inicial durante la negociación del servicio, u otros parámetros del RLP propuestos. Entonces la estación de abonado recibe y descodifica la respuesta 404 desde la estación base. El tipo de la respuesta recibida se evalúa 406 para decidir si se negocian o no parámetros del RLP adicionales. Si el mensaje recibido fue un Mensaje de Respuesta de Servicio, proponiendo tal vez cambios de los parámetros del 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 del 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 halla en la etapa 406 que el tipo de respuesta es un Mensaje de Conexión de Servicio que contiene los parámetros del 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 interacción inicial en 3 etapas. Si el Mensaje de Conexión de Servicio indica la realización de una interacción inicial en 3 etapas, entonces la interacción inicial 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 interacción inicial en 3 etapas y en su lugar especifica una estimación del RTT inicial que va a usarse, entonces la estación de abonado puede comenzar inmediatamente a enviar datos 412 de usuario.

Como se ha mencionado anteriormente, el Mensaje de Conexión de Servicio puede indicar que no es necesaria una interacción inicial en 3 etapas, pero no incluir estimación del RTT inicial. En este caso, la estación de abonado usará una estimación predeterminada del RTT inicial por defecto.

En una llamada 420 del RLP originada en la estación base, la estación de abonado recibe y descodifica 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 da soporte a la especificación de una estimación del 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 da soporte al uso de una estimación del RTT inicial recibida durante la negociación del servicio. Entonces la estación de abonado recibe y descodifica 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 que indica, por ejemplo, una propuesta de un esquema de NAK particular u otros parámetros del 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 del RLP adicionales. Cuando se recibe un Mensaje de Conexión de Servicio, entonces el procesamiento pasa desde la etapa 428 a la etapa 408 anteriormente descrita.

La FIG. 4b es un diagrama de flujo de las etapas realizadas por una estación base para inicializar y usar un enlace de comunicación del RLP según una realización de la invención. Las etapas se muestran para una llamada del RLP originada en la estación de abonado, tal como la mostrada en la FIG. 3a, y para una llamada del RLP originada en la estación base, tal como la mostrada en la FIG. 3b.

En una llamada 450 del RLP originada en la estación de abonado, la estación base recibe y descodifica 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 del RTT inicial durante la negociación del servicio u otros parámetros del RLP propuestos. A continuación, se evalúan 454 los parámetros del 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 del RLP propuestos en un Mensaje de Respuesta de Servicio y lo envía al abonado 456.

Si los parámetros del 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 del 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 realiza o no una interacción inicial en 3 etapas. Si es así, la estación base realiza una interacción inicial 474 en 3 etapas y entonces comienza a enviar datos de usuario. Si el Mensaje de Conexión de Servicio no indica ninguna interacción inicial en 3 etapas, entonces la estación base continúa directamente desde la etapa

472 con el envío de datos 476 de usuario.

En una llamada 460 del 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 da soporte a la especificación de una estimación del RTT inicial durante la negociación del servicio. Entonces la estación base recibe y descodifica el Mensaje de Respuesta de Servicio recibido desde la estación 464 de abonado.

Se evalúan 466 los parámetros del RLP indicados en el Mensaje de Respuesta de Servicio para determinar si debería o no 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 del RLP propuestos en un Mensaje de Petición de Servicio. En caso contrario, la estación base envía un Mensaje 470 de Conexión de Servicio y continúa desde esa etapa como se ha descrito anteriormente.

La FIG. 5 es un diagrama de flujo de las etapas usadas para actualizar estimaciones del RTT durante una sesión del RLP según una realización de la invención. En el caso de la estimación del RTT inicial negociada durante la negociación del servicio, es ventajoso para ambas partes poder ajustar sus estimaciones del RTT según mediciones realizadas durante la llamada. Este procedimiento usa información recopilada durante la transmisión de tramas NAK y de retransmisión para actualizar la estimación del RTT de manera dinámica durante una llamada del RLP, lo que da como resultado un proceso de actualización del RTT que se integra en el proceso de los NAK. Para mayor comodidad, el procedimiento se describe posteriormente desde el punto de vista de una estación de abonado en una llamada del RLP. Un experto en la técnica reconocerá que las realizaciones del procedimiento pueden ser realizadas por la estación de abonado, la estación base, o ambas, sin apartarse de la presente invención.

El procedimiento de actualización de la estimación del RTT comienza cuando la estación de abonado detecta un hueco 502 del 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 trama, o tramas, NAK que va(n) a enviarse. La estación de abonado también inicializa un temporizador de NAK con la estimación del 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 a la primera ronda 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 del RTT se comprueba en la etapa 520. Si el contador del RTT no está funcionando cuando se recibe la trama de retransmisión, entonces el contador del RTT y el temporizador de NAK se detienen según sea necesario. Si el contador del RTT todavía está funcionando cuando se recibe una trama de retransmisión, entonces se actualiza 522 la estimación del RTT que está usándose para la llamada del RLP, según la nueva estimación. En una realización ejemplar, la nueva estimación del RTT se computa realizando un promedio ponderado del valor de la estimación de RTT antigua y la suma del temporizador del RTT y un tiempo de protección predeterminado. Un experto en la técnica apreciará que pueden usarse otros diversos procedimientos de combinación sin apartarse de la presente invención. Estos otros procedimientos incluyen reemplazar la estimación del RTT por la suma del valor del temporizador del RTT y un tiempo de protección.

Tras actualizar la estimación 522 del RTT, el contador del RTT y el temporizador de NAK se detienen, y el proceso de actualización del RTT integrado en el proceso de NAK termina 540. Si en la etapa 520 se halla que el temporizador de NAK no está funcionando, entonces se omite la actualización del 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 rondas de NAK han pasado ya sin recibir una trama de retransmisión correspondiente. El límite del número de rondas de NAK en el esquema de NAK actual se determinó al comienzo de la llamada, bien a través del campo NAK_ROUNDS_REV precitado, o bien mediante el precitado esquema predeterminado de NAK por defecto. Si el número de rondas 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 rondas 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 del RTT para la llamada del RLP se ha actualizado alguna vez. Si se ha actualizado anteriormente, entonces la estación de abonado detiene el contador 534 del RTT antes de iniciar el temporizador de NAK de nuevo 506 y enviar la siguiente ronda de tramas 508 de NAK. Detener el contador del RTT antes de enviar otra ronda de tramas de NAK impide que la ambigüedad de las tramas de retransmisión cause imprecisión en las estimaciones del RTT. Por ejemplo, si se recibiera una trama de retransmisión después de enviarse una segunda ronda 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 ronda o en la segunda ronda. Hacer corresponder de manera incorrecta una trama de retransmisión de este tipo con una ronda de NAK posterior llevaría a una estimación incorrecta del RTT.

Otro problema se produce, sin embargo, al detener el contador del RTT tras la expiración del primer temporizador de NAK. Si, por algún motivo, la estimación del 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 del 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 del RLP.

Este problema se resuelve en la realización ejemplar permitiendo al contador del RTT continuar funcionando si la estación de abonado determina 532 que la estimación del RTT no se ha actualizado todavía. Si la estimación del RTT no se ha actualizado todavía, entonces se omite la etapa 534, y el abonado reinicia el temporizador 506 de NAK y envía la siguiente ronda de tramas 508 de NAK. En el peor de los casos, esto puede llevar a una estimación del RTT actualizada que sea excesivamente larga, pero esto se prefiere frente a una estimación de RTT que sea demasiado corta. Por consiguiente, en la realización preferida, la etapa 522 da a la estimación del RTT existente poco o ningún peso en el promedio ponderado la primera vez que se actualiza la estimación del RTT. En una realización alternativa, la ponderación de la estimación del RTT existente en la primera actualización varía en base a la cantidad por la que la primera estimación del RTT supera la estimación del RTT existente y el número de rondas 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 del 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 del RLP. Si el hueco fue el primero detectado, entonces el contador del RTT no se detiene antes de continuar hasta la etapa 506. Si otros huecos se hubieran detectado anteriormente, entonces se detiene 534 el contador del RTT antes de continuar hasta la etapa 506.

La FIG. 6 es un diagrama en bloques de un aparato usado para establecer y usar un enlace del 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 términos de una estación de abonado. Un experto en la técnica reconocerá que la configuración representada y sus variaciones pueden usarse igualmente conjuntamente con una estación base inalámbrica sin apartarse de la presente invención.

El aparato mostrado incluye la interfaz 602 de datos, que puede estar conectada con un dispositivo de entrada/salida externo, por ejemplo un terminal de visualización o un ordenador de mano o portátil. 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 panel de teclas y un visor. Por ejemplo, la estación 102 de abonado podría ser una agenda electrónica (PDA) inalámbrica de CDMA capaz de intercambiar datos con Internet y visualizarlos sobre un visor de cristal líquido (LCD).

Ya sea que los datos de usuario sin procesar se reciban 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 del 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 del 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 del 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 con, y proporciona tramas de transmisión a, el módulo 620 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 entre varias técnicas de corrección de errores hacia delante, incluyendo la turbocodificación, la codificación convolutiva u otra forma de decisión en software o codificación de bloques. Las tramas codificadas resultantes son proporcionadas 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 entre varias técnicas de intercalación, tales como la intercalación de bloques y la intercalación por inversión 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 aumenta su frecuencia, se amplifica y se proporciona al diplexor 650, y luego 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 luego se controlan en cuanto a ganancia y se les reduce la frecuencia en el receptor 638. De aquí en adelante, las señales se proporcionan al módulo 640 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 descodifican por FEC en el descodificador 630 de FEC. El descodificador 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 por 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 entre varias técnicas de desintercalación, tales como la desintercalación de bloques y la desintercalación por inversión de bits. El decodificador 610 de FEC usa cualquiera entre varias técnicas de corrección de errores hacia delante, incluyendo la turbocodificación, la codificación convolutiva u otra forma de decisión por software 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 inmediatamente 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

5 invención a las realizaciones mostradas en el presente documento, sino que ha de concedérsele el alcance más amplio coherente con los principios y características novedosas expuestas en el presente documento.

Claims (14)

1.

Un aparato para transmitir un flujo de bytes de información, que comprende:

medios para recibir un mensaje que especifica una estimación del tiempo de ida y vuelta, llamado RTT en lo sucesivo, del protocolo de enlace de radio, llamado RLP en lo sucesivo; y medios para conducir una sesión de comunicación del RLP usando dicha estimación del RTT para determinar la temporización de mensajes de acuse de recibo negativo, llamado NAK en lo sucesivo.

2.

El aparato de la reivindicación 1, en el cual dicho mensaje es un mensaje de negociación de servicio.

3.

El aparato de la reivindicación 1, en el cual dicho mensaje es un Mensaje de Conexión de Servicio.

4.

El aparato según la reivindicación 3, en el cual dicho Mensaje de Conexión de Servicio especifica adicionalmente un esquema de NAK, y que comprende adicionalmente:

medios para aplicar dicho esquema de NAK en las transmisiones.

5.

El aparato de la reivindicación 1, que comprende adicionalmente:

medios para negociar, usando mensajes de negociación de servicio, un esquema de NAK usado durante dicha subsiguiente sesión de comunicación del RLP.

6.

El aparato de la reivindicación 1, que comprende adicionalmente:

medios para negociar, usando mensajes de negociación de servicio, parámetros de cifrado usados durante dicha subsiguiente sesión de comunicación del RLP.

7.

El aparato de la reivindicación 1, en el cual dicho mensaje es un Mensaje de Petición de Servicio, o un Mensaje de Respuesta de Servicio, o un Mensaje de Dirección de Traspaso General, o bien es un Mensaje de Dirección de Traspaso Universal.

8.

Un aparato para transmitir un flujo de bytes de información, que comprende:

medios para enviar un mensaje que especifica una estimación del tiempo de ida y vuelta, llamado RTT en lo sucesivo, del protocolo de enlace de radio, llamado RLP en lo sucesivo; y medios para conducir una sesión de comunicación del RLP usando dicha estimación del RTT para determinar la temporización de mensajes de acuse de recibo negativo, llamado NAK en lo sucesivo.

9.

El aparato de la reivindicación 8, en el cual dicho mensaje es un mensaje de negociación de servicio.

10.

El aparato de la reivindicación 8, en el cual dicha estimación del RTT está especificada por un operador de una estación base y se usa para determinar la temporización de mensajes de NAK para una segunda sesión de comunicación del RLP.

11.

El aparato de la reivindicación 8, en el cual dicho mensaje es un Mensaje de Conexión de Servicio, o un Mensaje de Petición de Servicio, o un Mensaje de Respuesta de Servicio, o un Mensaje de Dirección de Traspaso General, o bien es un Mensaje de Dirección de Traspaso Universal.

12.

El aparato según la reivindicación 11, en el cual el mensaje es un Mensaje de Conexión de Servicio que especifica adicionalmente un esquema de NAK, y que comprende adicionalmente:

medios para aplicar dicho esquema de NAK en las transmisiones.

13.

El aparato de la reivindicación 8, que comprende adicionalmente:

medios para negociar, usando mensajes de negociación de servicio, un esquema de NAK usado durante dicha subsiguiente sesión de comunicación del RLP.

14.

El aparato de la reivindicación 8, que comprende adicionalmente:

medios para negociar, usando mensajes de negociación de servicio, parámetros de cifrado usados durante dicha subsiguiente sesión de comunicación del RLP.