ES2315274T3 - Procedimiento y aparato para proporcionar capas y protocolos configurables en un sistema de comunicciones. - Google Patents

Abstract

Un procedimiento para configurar una capa de un protocolo de interfaz aérea antes del comienzo de la comunicación de datos entre una primera entidad (250) y una segunda entidad (210), en el cual el protocolo de interfaz aérea comprende una pluralidad de capas modulares predefinidas dentro de una arquitectura de capas y cada una de dichas capas modulares puede modificarse sin modificar las capas restantes, y en el cual cada capa consiste en uno o más protocolos, que realiza una funcionalidad de la capa, comprendiendo el procedimiento: seleccionar, en la primera entidad (250), un conjunto de una o más capas enteras (310-324) del protocolo de interfaz aérea a negociar, en donde cada capa entera (310-324) seleccionada corresponde a un atributo seleccionado a negociar entre las entidades primera (250) y segunda (210); para cada atributo seleccionado, determinar (732) una lista del valor, o valores, de atributo seleccionado que se considera aceptable para la primera entidad (250); enviar (732) desde la primera entidad (250) una lista de atributos seleccionados y sus listas asociadas de valores de atributo seleccionados; recibir (746) en la primera entidad (250) una lista de atributos procesados y sus listas asociadas de valores de atributo procesados, en donde cada lista de valores de atributo procesados incluye uno o más valores de atributo considerados aceptables para la segunda entidad (210); y configurar (752) el uno o más protocolos, del conjunto seleccionado de una o más capas en la primera entidad (250) de acuerdo a la lista recibida de atributos procesados y sus listas asociadas de valores de atributo procesados.

Description

Procedimiento y aparato para proporcionar capas y protocolos configurables en un sistema de comunicaciones.

Antecedentes de la invención I. Campo de la invención

La presente invención se refiere a la comunicación inalámbrica. Más específicamente, la presente invención se refiere a un procedimiento y aparato para proporcionar capas y protocolos configurables en un sistema de comunicaciones.

II. Descripción de la técnica relacionada

El empleo de técnicas de modulación de acceso múltiple por división de código (CDMA) es una entre varias técnicas para facilitar la comunicación en la que están presentes un gran número de usuarios del sistema. Aunque se conocen en la tecnología otras técnicas de sistemas de comunicación de acceso múltiple, tales como el acceso múltiple por división del tiempo (p. ej., TDMA y GSM), el acceso múltiple por división de frecuencia (FDMA) y esquemas de modulación AM (modulación de amplitud), tales como la banda lateral única de amplitud comprimida/expandida (ACSSB), las técnicas de modulación de espectro extendido del CDMA tienen significativas ventajas sobre estas otras técnicas de modulación para sistemas de comunicaciones de acceso múltiple. El empleo de técnicas de CDMA en un sistema de comunicaciones de acceso múltiple se revela en la Patente Estadounidense Nº 4.901.307, titulada "SPREAD SPECTRUM MULTIPLE ACCESS COMMUNICATION SYSTEM USING SATELLITE OR TERRESTRIAL REPEATERS" ["Sistema de comunicación de acceso múltiple de espectro extendido que emplea repetidores satelitales o terrestres"], expedida el 13 de febrero de 1990, y la Patente Estadounidense Nº 5.103.459, titulada "SYSTEM AND METHOD FOR GENERATING SIGNAL WAVEFORMS IN A CDMA CELLULAR TELEPHONE SYSTEM" ["Sistema y procedimiento para generar ondas de señal en un sistema CDMA de telefonía celular"], expedida el 7 de abril de 1992, transferidas ambas al cesionario de la presente invención.

Los sistemas CDMA, típicamente, se diseñan para que sean conformes a uno o más estándares específicos de CDMA. Los ejemplos de tales estándares de CDMA incluyen el "Estándar de Compatibilidad Estación Móvil - Estación Base TIA/EIA/IS-95-A para un Sistema Celular de Espectro Extendido de Banda Ancha de Modalidad Dual", el "Estándar de Compatibilidad Estación Móvil - Estación Base TIA/EIA/IS-95-B para un Sistema Celular de Espectro Extendido de Banda Ancha de Modalidad Dual", los estándares TIA/EIA/IS-98-A, -B y -C, titulados "Estándar Recomendado de Prestaciones Mínimas para Estaciones Móviles Celulares y Sistemas de Comunicación Personal de Espectro Extendido de Modalidad Dual" y "Submisión Candidato ITU-RRTT cdma2000". Nuevos estándares CDMA se proponen y se adoptan para su empleo constantemente.

Cada estándar de CDMA define un protocolo de interfaz aérea utilizado por ese estándar para brindar soporte a la comunicación entre los dispositivos comunicantes (es decir, entre un terminal de acceso y una red de radio). El protocolo de interfaz aérea define los mecanismos mediante los cuales han de llevarse a cabo las funciones específicas, y puede abarcar un cierto número de protocolos que permiten la implementación de diversas funcio-
nes.

Por convención, cada estándar de CDMA adopta un protocolo específico de interfaz aérea que realiza un cierto número de funciones, y que se identifica por un número único de revisión. Pueden implementarse nuevas funciones definiendo nuevos atributos, mensajes y máquinas de estados, usualmente dentro del marco del protocolo existente de interfaz aérea. Se define entonces un nuevo protocolo de interfaz aérea que incluye los nuevos atributos, mensajes y máquinas de estados, junto con otros atributos, mensajes y máquinas de estados anteriormente definidos. De manera similar, si un protocolo existente se modifica o se actualiza, se define un nuevo protocolo de interfaz aérea y se asigna una nueva revisión.

Por convención, cada dispositivo comunicante (p. ej., cada terminal de acceso y red de radio) está diseñado para brindar soporte a una o más revisiones completas del protocolo de interfaz aérea. Debido a que el protocolo completo de interfaz aérea se define mediante una única revisión, se requiere que cada dispositivo de comunicación brinde soporte a todas las funciones requeridas en una revisión específica, si desea brindar soporte a cualquier función en esa revisión. Los dispositivos comunicantes, típicamente, se diseñan para brindar soporte a una o más revisiones (p. ej., una gama de revisiones). La comunicación entre el terminal de acceso y la red de radio se logra entonces utilizando cualquiera de las revisiones del protocolo de interfaz aérea que usualmente disponen de soporte.

El deseo de una mayor funcionalidad y capacidad inalámbrica ha dado como resultado protocolos de interfaz aérea cada vez más complejos. En particular, los protocolos de interfaz aérea han evolucionado para efectuar numerosas funciones complejas, incluyendo la comunicación de voz, la transmisión de datos, etc.

El procedimiento convencional de definir una nueva revisión para cada nuevo protocolo de interfaz aérea era adecuado para protocolos más "sencillos" en el diseño original del sistema CDMA. Según aumenta el número de funciones y su complejidad, el procedimiento convencional resulta engorroso e inadecuado. El procedimiento convencional tampoco brinda soporte fácilmente a la implementación de funciones adicionales en un protocolo existente de interfaz aérea, o a la implementación de un subconjunto de las funciones en el protocolo de interfaz aérea.

Por tanto, es sumamente deseable una estructura de protocolo de interfaz aérea que brinde soporte eficientemente a la implementación de una gran variedad de funciones.

El documento US-A-5 267 244 describe un sistema de comunicación inalámbrica que incluye una unidad base y una unidad remota. La unidad remota transmite una lista de sus capacidades funcionales a la unidad base. La unidad base recibe la lista de capacidades funcionales de la unidad remota y la compara con la lista de capacidades funcionales de la unidad base a fin de determinar un conjunto común de capacidades funcionales. La unidad base transmite luego la lista del conjunto funcional común de capacidades a la unidad remota. En adelante, las comunicaciones entre la unidad remota y la unidad base se llevan a cabo utilizando el conjunto de capacidades funcionales comunes. Las capacidades funcionales incluyen capacidades de codificación de la voz.

El documento US-A-5 818 871, que es propiedad del presente Solicitante, describe inter alia la negociación de la configuración de servicios para la comunicación digital entre una estación móvil y una estación base. En una realización descrita en ese documento de patente, la estación móvil propone una configuración de servicios a la estación base. Si la configuración de servicios propuesta es aceptable para la estación base, ambas estaciones comienzan a utilizar la configuración propuesta. Si la configuración de servicios propuesta no es aceptable para la estación base, la estación base puede rechazar la configuración propuesta, o bien proponer una configuración alternativa. La estación móvil puede, a su vez, aceptar o rechazar la configuración de servicios propuesta por la estación base, o incluso proponer otra configuración de servicios.

\vskip1.000000\baselineskip

Resumen de la invención

La presente invención proporciona técnicas empleadas para implementar capas y protocolos configurables en un sistema de comunicaciones. Las capas y protocolos de una arquitectura de capas de interfaz aérea son de diseño modular y pueden modificarse y actualizarse para brindar soporte a nuevas características, realizar tareas complejas e implementar funcionalidad adicional. Un terminal de acceso y una red de radio pueden comunicarse utilizando las capas y protocolos que disponen de soporte común en ambos, y esta determinación puede tomarse en el momento en que se abre una sesión de comunicaciones. Un conjunto básico de capas y protocolos que disponen de soporte por parte del terminal de acceso y de la red de radio garantiza un nivel mínimo de compatibilidad entre una primera entidad (p. ej., un terminal de acceso) y una segunda entidad (p. ej., una red de datos), teniendo un conjunto de una o más capas enteras uno o más protocolos seleccionados para la negociación, correspondiendo cada capa seleccionada a un atributo a negociar entre las entidades primera y segunda. Para cada atributo seleccionado, se determina una lista de valores de atributo seleccionados, incluyendo la lista uno o más valores de atributo considerados como aceptables para la primera entidad. Se envía una lista de atributos seleccionados y sus valores de atributo asociados desde la primera entidad y, en respuesta, se recibe una lista de atributos procesados y sus listas asociadas de valores de atributo procesados. Cada lista de valores de atributo procesados incluye uno o más valores de atributo considerados como aceptables para la segunda entidad. Las capas y protocolos en la primera entidad se configuran entonces de acuerdo a la lista recibida de atributos procesados y sus correspondientes valores de atributo procesados. En una realización, cada atributo procesado se asocia con un valor de atributo procesado. En una realización, las capas y protocolos en la primera entidad se configuran con sus valores por omisión si no se reciben los correspondientes valores de atributo procesados en la primera entidad.

La primera o segunda entidad, o ambas, pueden implementar una máquina de estados con un cierto número de estados que incluyen: (1) un estado inactivo, que indica inactividad antes de una negociación de sesión, (2) un estado iniciado, que indica la negociación de la sesión con respecto a la lista de atributos seleccionados y (3) un estado abierto que indica la comunicación activa entre las entidades primera y segunda. El estado iniciado puede implementarse para incluir (1) un estado iniciado de terminal de acceso, que indica la negociación de la sesión con respecto a los atributos seleccionados por el terminal de acceso y (2) un estado iniciado de red de radio, que indica la negociación de la sesión con respecto a los atributos seleccionados por la red de radio.

Una sesión de comunicaciones entre las entidades primera y segunda puede establecerse enviando un mensaje de solicitud-apertura desde la primera entidad y recibiendo un mensaje de respuesta-apertura que indica una aceptación o un rechazo de la solicitud. Los mensajes de solicitud-apertura y de respuesta-apertura pueden enviarse y recibirse mediante canales de comunicaciones comunes.

Los atributos seleccionados y sus valores de atributo asociados pueden enviarse mediante uno o más mensajes de solicitud-configuración, y los atributos procesados, y sus valores de atributo asociados, pueden recibirse mediante uno o más mensajes de respuesta-configuración. Los mensajes pueden identificarse por medio de un identificador de entidad asignado a la primera entidad. Los elementos en cada lista de valores de atributo seleccionados pueden disponerse en un orden basado en la preferencia de la primera entidad, y los elementos en los mensajes recibidos de respuesta-configuración pueden recibirse en un orden correspondiente al orden de los elementos en los mensajes de solicitud-configuración. La información de configuración puede enviarse y recibirse mediante canales de comunicaciones dedicados.

Las entidades primera y segunda pueden comunicarse mediante capas y protocolos por omisión antes de completar la configuración de las capas y protocolos negociados. En una implementación, si ambas entidades primera y segunda seleccionan un conjunto de atributos a negociar, la negociación con respecto al conjunto seleccionado por la primera entidad se completa antes de la negociación del conjunto seleccionado por la segunda entidad.

La invención proporciona un procedimiento y aparato adecuados para implementar capas y protocolos configurables en la red de radio, según las reivindicaciones adjuntas.

\vskip1.000000\baselineskip

Breve descripción de los dibujos

Las características, naturaleza y ventajas de la presente invención resultarán más aparentes a partir de la descripción detallada expuesta a continuación, cuando se consideren conjuntamente con los dibujos, en los cuales los caracteres de referencia iguales identifican análogamente en todos los casos, y en los cuales:

La Fig. 1 muestra un diagrama de un sistema de comunicaciones de espectro extendido que brinda soporte a un cierto número de usuarios;

La Fig. 2 muestra un diagrama de bloques de una realización de una red de radio y un terminal de acceso;

La Fig. 3 muestra un diagrama de una realización de una arquitectura en capas de interfaz aérea que dispone de soporte por parte de la invención;

Las Figs. 4A a 4C son, respectivamente, diagramas de una realización específica de una estructura de canal de alta velocidad de datos (AVD), una estructura de canal directo y una estructura de canal inverso;

La Fig. 5 muestra un diagrama de una realización específica de las capas y sus protocolos para la arquitectura de capas mostrada en la Fig. 3;

Las Figs. 6A y 6B muestran, respectivamente, diagramas de una realización de un protocolo de arranque de sesión para el terminal de acceso y la red de radio;

Las Figs. 6C y 6D muestran, respectivamente, diagramas de estado de una realización de un protocolo de control de sesión para el terminal de acceso y la red de radio;

La Fig. 7A muestra un diagrama de flujo de una implementación específica de una fase de apertura de sesión;

Las Figs. 7B y 7C muestran, respectivamente, diagramas de flujo de una implementación específica de una subfase de negociación de capa/protocolo de sesión y una subfase de activación de capa/protocolo de sesión;

La Fig. 8 muestra un diagrama temporal de una realización de las subfases de negociación y configuración de capa/protocolo de sesión, iniciadas por un terminal de acceso; y

Las Figs. 9A a 9H son diagramas de una realización del formato para diversos mensajes utilizados en la negociación y configuración de las capas y protocolos.

\vskip1.000000\baselineskip

Descripción detallada de las realizaciones específicas

La Fig. 1 muestra un diagrama de un sistema 100 de comunicaciones de espectro extendido que brinda soporte a un cierto número de usuarios. Dentro del sistema 100, un conjunto de terminales 110a a 110c de acceso se comunica con una red de radio a través de un conjunto de transceptores de estación base (TEB) 112a a 112e, mediante enlaces por el aire. Cada transceptor 112 de estación base se acopla con un controlador de estación base (CEB) 114 y un registro de ubicación de visitantes (RUV) 116. Los controladores 114 de estación base (y los transceptores 112 de estación base) también pueden acoplarse directamente entre sí, según se muestra con la línea discontinua en la Fig. 1.

Según se utiliza en el presente documento, un terminal de acceso es un dispositivo que proporciona conectividad de datos y/o voz a un usuario. El terminal de acceso puede ser un dispositivo de datos autónomo y autocontenido, tal como un teléfono celular, una agenda electrónica (PDA) u otros tipos de dispositivos autónomos de datos. El terminal de acceso también puede ser una unidad o módulo configurable para acoplarse con un dispositivo informático tal como un ordenador personal de mesa o portátil. Según se utiliza aquí, una red de radio es el equipo de red (p. ej., el transceptor 112 de estación base, el controlador 114 de estación base y el registro 116 de ubicación de visitantes en la Fig. 1) que proporciona conectividad de datos y/o voz entre una red de datos (p. ej., una red de datos por conmutación de paquetes tal como Internet) y los terminales de acceso. La conectividad, típicamente, se proporciona en una capa de enlace, según se describe más adelante.

La Fig. 2 muestra un diagrama en bloques de una realización de una red 210 de radio y un terminal 250 de acceso. En la red 210 de radio, los datos de tráfico de un almacén temporal 212 y los datos de control de un sistema 214 de control se proporcionan a un codificador 216 que codifica los datos con un formato de codificación específico. El formato de codificación puede incluir, por ejemplo, la codificación del control de redundancia cíclica (CRC), la codificación convolutiva, la codificación concatenada en serie, la codificación de bloque de Reed-Solomon, la cobertura de Walsh, la dispersión de seudo-ruido (PN), etc., que son las que se emplean típicamente para sistemas CDMA. Los datos codificados se proporcionan a un modulador 218 que modula los datos con un formato de modulación específico tal como, por ejemplo, la modulación por desplazamiento de fase de cuadratura (QPSK), la QPSK desplazada, u otros. Un transmisor 220 recibe y convierte los datos modulados en una señal analógica, acondiciona la señal y transmite la señal por el aire mediante un duplexor (D) 222 y una antena 224.

En el terminal 250 de acceso, la señal transmitida es recibida por una antena 252, encaminada a través de un duplexor (D) 254 y suministrada a un receptor 256. El receptor 256 acondiciona la señal y suministra la señal acondicionada a un demodulador 258. El acondicionamiento de la señal puede incluir el filtrado, la amplificación, la conversión de frecuencia, etc. El demodulador 258 demodula la señal acondicionada con un formato de demodulación que es complementario al formato de modulación utilizado en la red 210 de radio. Un descodificador 260 recibe y descodifica los datos demodulados con un formato de descodificación que es complementario al formato de codificación utilizado en la red 210 de radio. Los datos descodificados se suministran entonces a un controlador 262.

La transmisión de datos de tráfico y de control desde el terminal 250 de acceso a la red 210 de radio tiene lugar mediante un camino de señal complementario. Los datos de tráfico de un almacén temporal (no mostrado en la Fig. 2) y los datos de control del controlador 262 son codificados por un codificador 264, modulados por un modulador 266, acondicionados por un transmisor 268, encaminados a través del duplexor 254 y transmitidos mediante la antena 252. En la red 210 de radio, la señal es transmitida por la antena 224, encaminada a través del duplexor 222, acondicionada por un receptor 226 de RF (radiofrecuencia), demodulada por un demodulador 228, descodificada por un descodificador 230 y suministrada a un sistema 214 de control.

Según se utiliza en el presente documento, una transmisión directa se refiere a una transmisión desde la red 210 de radio a un terminal 250 de acceso, y una transmisión inversa se refiere a una transmisión desde el terminal 250 de acceso al terminal 210 de radio. Los formatos de demodulación y descodificación en el camino inverso pueden ser, y típicamente son, distintos a los del camino directo.

Como ocurre con muchos sistemas de comunicaciones, la comunicación entre el terminal de acceso y la red de radio se logra mediante un conjunto de "capas" que definen las modalidades de operación, las características que disponen de soporte y las capacidades del sistema de comunicaciones. Cada capa consiste en uno o más protocolos de capa (o protocolos a secas) que efectúan la funcionalidad de la capa. Cada capa se comunica con la capa superior, con la inferior, o con ambas, mediante interfaces definidas.

Originalmente, un sistema CDMA que es conforme al estándar IS-95 brinda soporte a un protocolo de interfaz aérea que define las capas y sus protocolos. En opinión de algunos, el estándar IS-95 se queda corto al separar los protocolos según su función. El protocolo original de interfaz aérea ha sido modificado varias veces para brindar soporte a funcionalidad adicional, tal como las funciones mejoradas de Control de Acceso al Medio (MAC). Para implementar la funcionalidad añadida, se realizan los cambios necesarios en las capas afectadas del protocolo original de la interfaz aérea, y el protocolo modificado de la interfaz aérea se identifica por un nuevo número de revisión (y, típicamente, se define como un nuevo estándar). El protocolo modificado de la interfaz aérea, típicamente, conserva la mayoría de las estructuras del protocolo original de la interfaz aérea (p. ej., la misma estructura de trama de datos, la misma longitud de trama, etc.), a fin de mantener tanta compatibilidad como sea posible con los sistemas y estándares preexistentes.

Una vez que ha sido adoptado, un nuevo protocolo de interfaz aérea puede ser puesto en práctica por el terminal de acceso y la red de radio si ambos están diseñados para brindar soporte a ese protocolo de interfaz aérea. Este procedimiento para generar nuevos protocolos de interfaz aérea no permite una fácil implementación de nuevas funciones y características en el sistema CDMA.

Según un aspecto de la invención, las capas y sus protocolos se diseñan de forma modular, a fin de que cada capa (o protocolo) pueda modificarse o actualizarse sin necesidad de modificar las restantes capas (o protocolos). Esto puede lograrse, en parte, definiendo y manteniendo las interfaces entre las capas de forma tal que las nuevas funciones puedan disponer fácilmente de soporte. El diseño modular también permite la modificación aislada de una capa y de su(s) protocolo(s).

Cada capa incluye uno o más protocolos que llevan a cabo la funcionalidad de esa capa. El protocolo, o protocolos, de una capa específica puede(n) negociarse individualmente entre el terminal de acceso y la red de radio (p. ej., al comenzar una sesión de comunicaciones). Tanto el terminal de acceso como la red de radio pueden diseñarse para brindar soporte a un conjunto distinto de protocolos pero, aun así, pueden comunicarse entre sí mediante los protocolos que les sean comunes a ambos. La característica de las capas y protocolos negociados permite flexibilidad en el diseño y el empleo de distintas versiones de un protocolo de interfaz aérea, sin necesidad de definir y mantener explícitamente cada modificación como un nuevo protocolo de interfaz aérea, como se hace convencionalmente.

La Fig. 3 muestra un diagrama de una realización de una arquitectura 300 de capas de interfaz aérea, que dispone de soporte en la invención. Según se muestra en la Fig. 3, la arquitectura 300 de capas comprende siete capas, que se identifican como: (1) una capa física 310, (2) una capa 314 de control de acceso al medio (MAC), (3) una capa 316 de seguridad, (4) una capa 318 de conexión, (5) una capa 320 de sesión, (6) una capa 322 de flujo y (7) una capa 324 de aplicación. Para una mejor comprensión de la presente invención, se proporciona a continuación una breve descripción de la función principal de cada capa.

La capa física 310 define las características "físicas" de la transmisión entre el terminal de acceso y la red de radio. Estas características físicas pueden incluir, por ejemplo, la estructura del canal, la frecuencia de transmisión, el nivel de potencia de transmisión de salida, el formato de modulación, el esquema de codificación, etc., para los enlaces directo e inverso.

La capa MAC 314 define los procedimientos utilizados para transmitir y recibir datos por la capa física 310.

La capa 316 de seguridad proporciona servicios dotados de seguridad que pueden incluir, por ejemplo, servicios de autenticación y de cifrado.

La capa 318 de conexión proporciona servicios de establecimiento y mantenimiento de conexión por enlace aéreo.

La capa 320 de sesión proporciona servicios de negociación de capas y protocolos, de configuración de protocolos, y de mantenimiento de estados. La capa 320 de sesión se describe en mayor detalle más adelante.

La capa 322 de flujo proporciona multiplexado de diversos flujos de aplicación. En una realización específica, el sistema de comunicaciones brinda soporte a cuatro flujos de aplicación, indicados como flujos 0 a 3. En una realización, el flujo 0 se emplea para la señalización entre el terminal de acceso y la red de radio, el flujo 1 se emplea para la transmisión de datos en paquetes, y los flujos 2 y 3 se emplean para otras aplicaciones. Según se muestra en la Fig. 3, el flujo de señalización (p. ej., el flujo 0) recibe soporte de un Protocolo de Enlace de Señalización (SLP) 330 y de un Protocolo de Mensajes de Alta Velocidad de Datos (HMP) 332, y el flujo de datos en paquetes (p. ej., el flujo 1) recibe soporte de un Protocolo de Enlace de Radio (RLP) 340 y de un Protocolo Punto a Punto (PPP) 342. En una realización, un flujo de señalización por omisión (es decir, un protocolo HMP/SLP por omisión) se utiliza como el valor por omisión para el flujo 0, y un servicio de paquetes por omisión (es decir, un protocolo PPP/RLP por omisión) se utiliza como el valor por omisión para el flujo 1, si estos flujos no han sido negociados entre el terminal de acceso y la red de radio.

El SLP 330 proporciona mecanismos de entrega fiables y de "máximo esfuerzo" para mensajes de señalización, y el HMP 332 proporciona servicios de transmisión de mensajes para mensajes de señalización. El RLP 340 proporciona retransmisión y detección de datos duplicados para un flujo específico de datos definido, y una implementación se describe adicionalmente en el estándar IS-707. Puede diseñarse y emplearse una implementación del RLP 340 distinta a la descrita en IS-707, y esto está dentro del ámbito de la presente invención. Cuando se utiliza en el contexto del servicio de paquetes por omisión, el RLP 340 puede definirse para que transporte paquetes PPP. El PPP 342 proporciona soporte de entramado y multi-protocolo, y está adicionalmente descrito por W. Simpson en el documento "The Point-to-Point Protocol (PPP)" ["El Protocolo Punto a Punto (PPP)"], RFC 1661, Julio de 1994. Los protocolos que funcionan sobre el PPP 342 pueden transportar datos de tráfico, así como realizar diversas tareas de administración de red.

La Fig. 3 muestra una realización específica de una arquitectura en capas que dispone de soporte en la presente invención. Otras arquitecturas de capas, con capas adicionales, con menos capas, o con capas distintas, también pueden disponer de soporte en la presente invención.

Las Figs. 4A a 4C son, respectivamente, diagramas de una realización específica de una estructura 410 de canal de alta velocidad de datos (AVD), una estructura 420 de canal directo, y una estructura 440 de canal inverso, que reciben soporte de un sistema de comunicación (p. ej., el sistema 100 de comunicaciones en la Fig. 1). La estructura 410 de canal AVD incluye la estructura 420 de canal directo que se emplea para transmitir datos desde la red de radio al terminal de acceso, y la estructura 440 de canal inverso que se emplea para transmitir datos desde el terminal de acceso a la red de radio. Las estructuras de canal directo e inverso se diseñan para proporcionar la funcionalidad requerida, y cada estructura de canal se diseña basándose en las características específicas de la transmisión de datos en el enlace directo o inverso.

La Fig. 4B muestra un diagrama de una realización de una estructura 420 de canal directo. En esta realización, la estructura 420 de canal directo incluye un canal piloto 422, un canal MAC 424, uno o más canales 426 de tráfico, y uno o más canales 428 de control. El canal MAC 424 incluye adicionalmente un canal 432 de actividad directa, un canal 434 de actividad inversa y un canal 436 de control de potencia inversa. Estos canales pueden diseñarse de distintas maneras, y esto está dentro del ámbito de la presente invención. Los canales piloto, MAC y de control son canales "comunes" compartidos por un cierto número de terminales de acceso en comunicación con la red de radio. El canal, o canales, de tráfico, son canales dedicados asignados al terminal de acceso al establecer una sesión.

La Fig. 4C muestra un diagrama de una realización de una estructura 440 de canal inverso. En esta realización, la estructura 440 de canal inverso incluye uno o más canales 442 de tráfico y un canal 444 de acceso. El canal, o canales, 442 de tráfico incluye(n) adicionalmente un canal piloto 452, un canal MAC 454 y uno o más canales 456 de datos. El canal MAC 454 puede incluir adicionalmente un canal 462 indicador de velocidad inversa y un canal 464 de control de velocidad de datos. El canal 444 de acceso incluye adicionalmente un canal piloto 472, un canal MAC 474 y uno o más canales 476 de datos. El canal MAC 474 puede incluir adicionalmente un canal 478 indicador de velocidad inversa. Nuevamente, estos canales pueden diseñarse de diversas maneras, y esto está dentro del ámbito de la presente invención. Como ocurre con la estructura del canal directo, el canal, o canales, de tráfico, son canales "dedicados", y el canal de acceso es un canal "común" compartido con otros terminales de acceso.

Se utiliza un cierto número de términos para describir la invención, y estos términos se definen a continuación.

Una sesión se refiere a un estado operativo compartido entre un terminal de acceso y una red de radio. El estado operativo compartido almacena los protocolos y las configuraciones de protocolos que se han negociado, y que están disponibles para su empleo en la comunicación entre el terminal de acceso y la red de radio. De acuerdo a un aspecto de la invención, las capas, los protocolos y las configuraciones de protocolos pueden negociarse entre el terminal de acceso y la red de radio cuando se establece una sesión y, en algunas implementaciones, pueden renegociarse en cualquier momento durante la sesión. En una realización, si no es para establecer una sesión, un terminal de acceso no puede comunicarse con una red de radio sin tener una sesión abierta (es decir, el terminal de acceso puede comunicarse con la red de radio con el fin explícito de abrir una sesión).

Una conexión es un estado específico del enlace aéreo, en el cual se asignan al terminal de acceso recursos dedicados del enlace aéreo (p. ej., un canal de tráfico directo, un canal de tráfico inverso y canales MAC asociados). Durante cualquier sesión específica, el terminal de acceso y la red de radio pueden abrir y cerrar una conexión muchas veces. En una realización, si no es para establecer una sesión, no existe una conexión sin una sesión.

Un flujo es un canal de transmisión utilizado para enviar información para una aplicación específica. Un flujo puede definirse para transportar información de señalización, datos de tráfico, otros tipos de datos, o una combinación de los mismos. El terminal de acceso y la red de radio pueden estar, y típicamente están, diseñados para brindar soporte a transmisiones concurrentes de flujos múltiples. Los flujos pueden emplearse para transportar datos con distintos requisitos de calidad de servicio (QoS), u otras aplicaciones.

La Fig. 5 muestra un diagrama de una realización específica de las capas y de sus protocolos para la arquitectura 300 en capas en la Fig. 3, que están diseñados para brindar soporte a la estructura 410 de canal AVD en las Figs. 4A a 4C. Según se muestra en la Fig. 5, cada capa incluye uno o más protocolos que realizan la funcionalidad de la capa. Los protocolos utilizan mensajes y/o cabeceras de señalización para transportar información a la otra entidad en el otro extremo del enlace aéreo. La Fig. 5 muestra algunos de los protocolos incluidos en las capas de la arquitectura 300 en capas.

En la realización mostrada en la Fig. 5, la capa MAC 314 incluye un protocolo MAC 514a de canal de control, un protocolo MAC 514b de canal de tráfico directo, un protocolo MAC 514c de canal de acceso y un protocolo MAC 514d de canal de tráfico inverso. El protocolo MAC 514a de canal de control proporciona los procedimientos utilizados por la red de radio para transmitir, y por el terminal de acceso para recibir, por el canal 428 de control. El protocolo MAC 514b de canal de tráfico directo proporciona los procedimientos utilizados por la red de radio para transmitir, y por el terminal de acceso para recibir, por el canal 426 de tráfico directo. El protocolo MAC 514c de canal de acceso proporciona los procedimientos utilizados por el terminal de acceso para transmitir, y por la red de radio para recibir, por el canal 444 de acceso. Y el protocolo MAC 514d de canal de tráfico inverso proporciona los procedimientos utilizados por el terminal de acceso para transmitir, y por la red de radio para recibir, por el canal 442 de tráfico inverso.

La capa 316 de seguridad incluye uno o más protocolos de seguridad diseñados para proteger del robo de las transmisiones de señal. En una realización, la capa 316 de seguridad incluye un protocolo básico de seguridad (no mostrado en la Fig. 4) que protege del robo de servicio y del robo de identidad. La comunicación de datos sensibles, típicamente, puede protegerse utilizando la autenticación y cifrado de extremo a extremo, y la seguridad adicional de la capa 316 de seguridad, típicamente, no es necesaria. Sin embargo, se proporcionan interfaces para permitir que se añadan diversos protocolos de seguridad, según sea necesario.

La capa 318 de conexión incluye un protocolo 518a de gestión de enlace aéreo, un protocolo 518b de estado de inicialización, un protocolo 518c de estado de inactividad, un protocolo 518d de estado conectado, un protocolo 518e de supervisión del estado de inactividad, un protocolo 518f de supervisión del estado conectado, un protocolo 518g de consolidación de paquetes, un protocolo 518h de actualización de rutas y un protocolo 518i de mensajes de sobregasto. El protocolo 518a de gestión de enlace aéreo proporciona la gestión general de la máquina de estados que rige al terminal de acceso y a la red de radio durante una conexión. El protocolo 518b del estado de inicialización proporciona los procedimientos que sigue el terminal de acceso para adquirir una red de radio, y los procedimientos que la red de radio sigue para brindar soporte a la adquisición de la red. El protocolo 518c del estado de inactividad proporciona los procedimientos que el terminal de acceso y la red de radio siguen cuando no está abierta una conexión. El protocolo 518d del estado conectado proporciona los procedimientos que el terminal de acceso y la red de radio siguen cuando está abierta una conexión. El protocolo 518e de supervisión del estado de inactividad proporciona los procedimientos de supervisión que el terminal de acceso sigue cuando no está abierta una conexión. El protocolo 518f de supervisión del estado conectado proporciona los procedimientos de supervisión que el terminal de acceso y la red de radio siguen cuando está abierta una conexión. El protocolo 518g de consolidación de paquetes proporciona la priorización de transmisiones y la encapsulación de paquetes para la capa 318 de conexión. El protocolo 518h de actualización de rutas brinda los medios para mantener una ruta entre el terminal de acceso y la red de radio. Y el protocolo 518i de mensajes de sobregasto proporciona mensajes radiados que contienen información utilizada por los protocolos en la capa 318 de conexión.

La capa 320 de sesión incluye un protocolo 520a de arranque de sesión y un protocolo 520b de control de sesión. El protocolo 520a de arranque de sesión proporciona el intercambio inicial de mensajes utilizado para iniciar una sesión, y proporciona adicionalmente los medios para rechazar a un terminal de acceso que no tiene actualmente una sesión. El intercambio inicial de mensajes asigna al terminal de acceso un UATI (Identificador de Unitransmisión de Terminal de Acceso) y selecciona el protocolo de control de sesión que, a su vez, negocia y configura los protocolos utilizados en la sesión. El UATI también se denomina aquí un "identificador de terminal". En una realización, el protocolo 520a de arranque de sesión es no negociable.

El protocolo 520b de control de sesión proporciona la negociación inicial y la configuración de los protocolos utilizados durante una sesión, y brinda soporte adicional a los procedimientos de supervisión de sesión y de cierre de sesión. En una realización, el protocolo 520b de control de sesión brinda soporte a dos fases de negociación - una negociación iniciada por un terminal de acceso (TA) y una negociación iniciada por una red de radio (RR). En la fase de negociación iniciada por el TA, los intercambios de negociaciones son iniciados por el terminal de acceso. Esta fase, típicamente, se utiliza para negociar los protocolos que se emplearán en la sesión, y para negociar las configuraciones para los protocolos (p. ej., longitudes de las claves de autenticación). En la fase de negociación iniciada por la RR, los intercambios de negociaciones son iniciados por la red de radio. Esta fase, típicamente, se emplea para reemplazar valores por omisión utilizados por los protocolos negociados. El protocolo 520b de control de sesión también puede proporcionar un mecanismo de mantenimiento en actividad de una sesión. En una realización, de acuerdo al mecanismo de mantenimiento en actividad, si no ha circulado nada entre el terminal de acceso y la red de radio durante un cierto periodo de tiempo, entonces una entidad envía un mensaje de mantenimiento en actividad, al cual responde la otra entidad.

El protocolo 520a de arranque de sesión y el protocolo 520b de control de sesión se describen en más detalle más adelante.

La capa 322 de flujo incluye un protocolo 522a de flujo. En la dirección de transmisión, el protocolo 522a de flujo añade una cabecera de flujo a los paquetes de datos y se asegura de que los paquetes estén alineados en entornos de octetos de bits. En la dirección de recepción, el protocolo 522a de flujo retira la cabecera de flujo y remite los paquetes a la aplicación correspondiente.

En una realización, los protocolos están definidos por sus interfaces y estados de protocolo. En una realización específica, se definen cuatro tipos de interfaces, que incluyen: (1) cabeceras y mensajes, (2) comandos, (3) indicaciones y (4) datos públicos. Para la siguiente exposición, el término "entidad" se emplea para denotar bien el terminal de acceso o bien la red de radio.

Las cabeceras y los mensajes se utilizan para la comunicación entre un protocolo que se ejecuta en una entidad y el mismo protocolo en la otra entidad.

Los comandos son empleados por un protocolo de capa superior a fin de obtener un servicio de un protocolo de capa inferior en la misma entidad. Por ejemplo, los comandos pueden utilizarse como primitivas por una capa superior para conseguir que un protocolo en una capa inferior emprenda alguna acción (p. ej., abortar cualquier intento de acceso actualmente en marcha). En una realización, pueden enviarse comandos entre protocolos en la misma capa, pero se limitan a una dirección (es decir, la entidad que recibe un comando desde un protocolo específico tiene prohibido enviar un comando a la otra entidad en el mismo protocolo).

Las indicaciones son utilizadas por un protocolo de capa inferior para trasladar información con respecto a la ocurrencia de un suceso (p. ej., para proporcionar notificaciones cuando ocurren ciertos sucesos). En una realización, los protocolos en una capa superior o en la misma capa pueden registrarse para recibir indicaciones. En una realización, las indicaciones entre los protocolos en la misma capa se limitan a una dirección (es decir, si el protocolo A se registra para recibir indicaciones desde el protocolo B en la misma capa, el protocolo B tiene prohibido registrarse para recibir indicaciones desde el protocolo A).

Los datos públicos se utilizan para compartir información de forma controlada entre protocolos. Los protocolos pueden poner a disposición de otros protocolos algunos de los datos que generan o que reciben mediante mensajes. Los datos públicos pueden compartirse entre protocolos en la misma capa, así como entre protocolos en distintas capas.

Los estados de los protocolos se utilizan para identificar los estados operativos específicos de un protocolo específico. Cada estado de un protocolo puede asociarse con un conjunto específico de características de comportamiento que puede depender, por ejemplo, de la condición de operación, del entorno de la entidad (p. ej., si una conexión está abierta o no, si una sesión está abierta o no, etc.) y de otros factores. Las transiciones entre los estados de los protocolos son disparadas por la ocurrencia de sucesos específicos, que también son capturados por los estados de operación. Los ejemplos de sucesos que pueden llevar a una transición de estado incluyen la recepción de un mensaje, un comando desde un protocolo de capa superior, una indicación desde un protocolo de capa inferior, y la expiración de un temporizador.

La red de radio es capaz de comunicarse con un cierto número de terminales de acceso simultáneamente. La red de radio instancia un protocolo de señalización para cada terminal de acceso con el cual se comunica y, en lo sucesivo, mantiene una máquina de estados del protocolo para el terminal de acceso. La red de radio es capaz de mantener múltiples instanciaciones independientes del protocolo de señalización, cada una de ellas con su propia máquina de estados independiente.

En una realización, se proporcionan un estado inactivo, un estado abierto y un estado cerrado para cada uno de un cierto número de protocolos. Se ingresa al estado inactivo cuando el protocolo no está operativo en un momento específico. Por ejemplo, el protocolo MAC del canal de acceso en el terminal de acceso ingresa al estado inactivo cuando tiene una conexión abierta. El estado abierto indica que la sesión o conexión (según lo que sea aplicable al protocolo) está abierta, y el estado cerrado indica que la sesión o conexión está cerrada. En una realización, todos los estados de un protocolo específico, que no sean el estado inactivo, se denominan colectivamente estados activos, aunque puedan ser nombrados individualmente. Por ejemplo, el protocolo MAC del canal de tráfico directo puede diseñarse para que tenga tres estados: inactivo, de velocidad variable y de velocidad fija, denominándose los estados de velocidad variable y fija estados activos.

Cada protocolo brinda soporte a un conjunto de comandos que facilita la comunicación con otros protocolos. Algunos comandos comunes que disponen de soporte en muchos de los protocolos incluyen la activación, la desactivación, la apertura y el cierre. La activación ordena al protocolo efectuar la transición desde el estado inactivo a algún otro estado. La desactivación ordena al protocolo efectuar la transición al estado inactivo. La apertura (o el cierre) ordenan al protocolo realizar una función vinculada con la apertura (o cierre) de una sesión o con la apertura (o cierre) de una conexión.

De acuerdo a un aspecto de la invención, puede negociarse y configurarse un cierto número de aplicaciones, capas, protocolos o configuraciones (es decir, para las aplicaciones, capas y protocolos), o una combinación de los mismos, cuando se establece una sesión. A cada flujo, capa y protocolo se asigna un identificador único (denominado aquí un Tipo) que identifica el flujo, capa o protocolo general (p. ej., el protocolo MAC del canal de acceso). En una implementación específica, el identificador es un valor de 8 bits. También puede negociarse la composición de capas (p. ej., la mostrada en la Fig. 3).

En una realización, un flujo, una capa o un protocolo puede asociarse adicionalmente a un Subtipo que identifica una instancia específica de la capa o del protocolo (p. ej., el protocolo MAC por omisión del canal de acceso y un día, tal vez, el extendido y atiborrado protocolo MAC del canal de acceso, u otros).

La arquitectura de capas mostrada en la Fig. 3 brinda soporte a una gran variedad de aplicaciones. De acuerdo a un aspecto de la invención, para una compatibilidad mínima, se define un conjunto de aplicaciones por omisión que dispone de soporte por parte de todos los terminales de acceso y las redes de radio. En una realización, las aplicaciones por omisión incluyen una aplicación de señalización por omisión y una aplicación de paquetes por omisión. La aplicación de señalización por omisión proporciona los medios para enviar mensajes entre un protocolo en una entidad y el mismo protocolo en la otra entidad. La aplicación de paquetes por omisión proporciona un flujo de octetos de bits del protocolo PPP entre las entidades.

En una realización, el protocolo de señalización por omisión incluye (1) un protocolo de mensajes (p. ej., el protocolo de mensajes de AVD) y (2) un protocolo de capa de enlace que proporciona fragmentación y retransmisión de mensajes, y detección de datos duplicados (p. ej., el Protocolo de Enlace de Señalización SLP). En una realización, la aplicación de paquetes por omisión incluye (1) el protocolo PPP (es decir, según lo definido por el documento IETF RFC 1661) que proporciona un flujo de octetos de bits PPP y (2) un protocolo de capa de enlace (p. ej., el Protocolo de Enlace de Radio RLP) que proporciona retransmisión de octetos de bits y detección de datos duplicados.

De acuerdo a un aspecto de la invención, las aplicaciones a emplear, los flujos sobre los que se transportan las aplicaciones, las capas, los protocolos y las configuraciones pueden negociarse como parte de una negociación de sesión. En una realización, la negociación de sesión se implementa en la capa de sesión. De acuerdo a otro aspecto de la invención, cada terminal de acceso y red de radio se diseña para brindar soporte a una arquitectura básica de capas y a un conjunto básico de protocolos. Al iniciar una comunicación entre el terminal de acceso y la red de radio, se lleva a cabo una negociación de sesión, y los protocolos en el conjunto básico, y los protocolos adicionales, pueden negociarse entre las entidades.

Se emplea un conjunto de aplicaciones, capas, protocolos y configuraciones por omisión para brindar soporte a la comunicación entre las entidades hasta que se negocian los protocolos. Cada capa incluye uno o más protocolos por omisión. Pueden utilizarse mensajes del protocolo por omisión de señalización de sobregasto para intercambiar información vinculada con las capas, protocolos y configuraciones por omisión. El terminal de acceso y la red de radio utilizan las configuraciones por omisión hasta que se completa la negociación de la sesión, momento en el cual aplican las capas, protocolos y configuraciones negociados para su empleo en la comunicación subsiguiente.

La Fig. 6A muestra un diagrama de estados de una realización de un protocolo de arranque de sesión (p. ej., el protocolo 520a de arranque de sesión en la Fig. 5) para el terminal de acceso, que incluye un estado inactivo 610, un estado 612 de inicialización y un estado 614 de sesión. Según se muestra en la Fig. 6A, el protocolo de arranque de sesión para el terminal de acceso efectúa la transición desde un estado inicial hasta un estado inactivo 610 para abrir una sesión. En el estado inactivo 610, no hay ninguna comunicación entre el terminal de acceso y la red de radio. Al transmitir o recibir un mensaje de activación, el protocolo efectúa la transición al estado 612 de inicialización, en el cual el terminal de acceso y la red de radio intercambian los mensajes de solicitud-apertura y de respuesta-apertura. El protocolo efectúa la transición de vuelta al estado inactivo 610 si el mensaje de respuesta-apertura recibido indica que la solicitud ha sido rechazada, y efectúa la transición al estado 614 de sesión si la solicitud ha sido aceptada. Mediante el intercambio de mensajes de solicitud-apertura y respuesta-apertura, se asigna al terminal de acceso un UATI (es decir, un identificador de terminal) y se selecciona un protocolo de control de sesión para su empleo en la negociación de sesión. En el estado 614 de sesión, una sesión está bien abierta o bien en el proceso de ser negociada por el protocolo de control de sesión seleccionado en el estado 612 de inicialización. El protocolo efectúa la transición de vuelta desde el estado 614 de sesión al estado inactivo 610 al enviar o recibir un mensaje de cierre, o al recibir un mensaje de rechazo desde la red de radio.

La Fig. 6B muestra un diagrama de estados de una realización de un protocolo de arranque de sesión para la red de radio, que incluye un estado inactivo 620, un estado 622 de inicialización y un estado 624 de sesión. El protocolo de arranque de sesión para la red de radio ingresa al estado inactivo 620 al recibir una indicación para abrir una sesión. El protocolo efectúa la transición desde el estado inactivo 610 al estado 612 de inicialización al recibir un mensaje de solicitud-apertura desde el terminal de acceso. El mensaje de solicitud-apertura se procesa y el protocolo efectúa la transición de vuelta al estado inactivo 620 al transmitir un mensaje de respuesta-apertura que indica el rechazo de la solicitud de apertura, y al estado 624 de sesión al transmitir un mensaje de respuesta-apertura que indica la aceptación de la solicitud. El protocolo efectúa la transición de vuelta desde el estado 624 de sesión al estado inactivo 620 al transmitir o recibir un mensaje de cierre.

La Fig. 6C muestra un diagrama de estados de una realización de un protocolo de control de sesión (p. ej., el protocolo 520b de control de sesión en la Fig. 5) para el terminal de acceso, que incluye un estado inactivo 630, un estado 632 iniciado por el TA, un estado 634 iniciado por la RR, y un estado abierto 636. El protocolo de control de sesión para el terminal de acceso efectúa la transición desde un estado inicial al estado inactivo 630 para una negociación de sesión. En el estado inactivo 630, el protocolo espera un comando de activación y, al recibirlo o transmitirlo, efectúa la transición al estado 632 iniciado por el TA. En el estado 632 iniciado por el TA, se efectúa la negociación por iniciativa del terminal de acceso y, al completarla (p. ej., según lo determinado por la transmisión de un mensaje de configuración-completa), el protocolo efectúa la transición al estado 634 iniciado por la RR. En el estado 634 iniciado por la RR, se realiza la negociación por iniciativa de la red de radio y, al completarla (p. ej., según lo determinado por la recepción de un mensaje de configuración-completa), el protocolo efectúa la transición al estado abierto 636. En el estado abierto 636, la sesión está abierta y puede utilizarse para intercambiar tráfico de aplicaciones (p. ej., por los flujos 0 a 3) entre el terminal de acceso y la red de radio. El protocolo efectúa la transición de vuelta desde el estado abierto 636 al estado inactivo 630 al cerrar la sesión (p. ej., al transmitir un mensaje de cierre).

La Fig. 6D muestra un diagrama de estados de una realización de un protocolo de control de sesión para la red de radio, que incluye un estado inactivo 640, un estado 642 iniciado por el TA, un estado 644 iniciado por la RR, un estado abierto 646 y un estado cerrado 648. El protocolo de control de sesión para la red de radio efectúa la transición al estado inactivo 640 para una negociación de sesión. En el estado inactivo 640, el protocolo espera un comando de activación y, al recibirlo o transmitirlo, efectúa la transición al estado 642 iniciado por el TA. En el estado 642 iniciado por el TA, se lleva a cabo la negociación iniciada por el terminal de acceso y, al completarla (p. ej., según lo determinado por la recepción de un mensaje de configuración-completa), el protocolo efectúa la transición al estado 644 iniciado por la RR. En el estado 644 iniciado por la RR, se lleva a cabo la negociación iniciada por la red de radio y, al completarla (p. ej., según lo determinado por la transmisión de un mensaje de configuración-completa), el protocolo efectúa la transición al estado abierto 646. En el estado abierto 646, la sesión está abierta y puede emplearse para intercambiar tráfico de aplicaciones entre el terminal de acceso y la red de radio. El protocolo efectúa la transición de vuelta desde el estado abierto 646 al estado inactivo 640 al recibir un mensaje de cierre, y al estado 648 de cierre al transmitir un mensaje de cierre. Desde el estado 648 de cierre, el protocolo efectúa la transición de vuelta al estado inactivo 640 al recibir un mensaje de cierre o la expiración de un temporizador.

Para simplificar, no se muestran todas las transiciones en las Figs. 6A a 6D. Por ejemplo, no se muestran las transiciones de desactivación en las Figs. 6A y 6B, y no se muestran las transiciones por fallo en las Figs. 6C y 6D.

La Fig. 7A muestra un diagrama de flujo de una implementación específica de la fase 610 de apertura de sesión. El protocolo en la fase 610 de apertura de sesión utiliza un mensaje de solicitud-apertura y un mensaje de respuesta-apertura para permitir que el terminal de acceso solicite y reciba un identificador de terminal de acceso. El terminal de acceso inicia el intercambio de mensajes enviando un mensaje de solicitud-apertura por el canal común inverso (p. ej., el canal 444 de acceso en la Fig. 4C) y se identifica con un identificador aleatorio de terminal de acceso, en el bloque 710. La red de radio recibe y procesa el mensaje de solicitud-apertura en el bloque 712.

En el bloque 714, la red de radio determina si ha de aceptar o rechazar la solicitud de apertura. Si se acepta la solicitud de sesión, la red de radio asigna un identificador de terminal de acceso al terminal de acceso y genera un mensaje de respuesta-apertura que incluye el identificador asignado, en el bloque 716. El identificador de terminal de acceso ha de ser empleado por el terminal de acceso durante el transcurso de la sesión. En caso contrario, si se rechaza la solicitud de sesión, la red de radio genera un menaje de respuesta-apertura que incluye una razón para el rechazo, en el bloque 718. El mensaje de respuesta-apertura incluye adicionalmente el identificador aleatorio del terminal de acceso extraído del mensaje de solicitud-apertura recibido desde el terminal de acceso. El mensaje de respuesta-apertura se envía entonces al terminal de acceso por el canal común directo (p. ej., el canal 428 de control), en el bloque 720. En una realización, los mensajes en la fase 610 de apertura de sesión son transportados por el protocolo de sesión (por omisión).

Según se muestra en la Fig. 6, la fase 620 de configuración de sesión incluye una subfase 622 de negociación de capa/protocolo de sesión, una subfase 624 de configuración de capa/protocolo de sesión y una subfase 626 de activación de capa/protocolo de sesión. Estas subfases se describen en más detalle más adelante.

La Fig. 7B muestra un diagrama de flujo de una implementación específica de la subfase 622 de negociación de capa/protocolo de sesión. El protocolo en la subfase 622 utiliza uno o más mensajes de solicitud-configuración y mensajes de respuesta-configuración para permitir que el terminal de acceso y la red de radio negocien capas, protocolos y configuraciones mutuamente aceptables.

Inicialmente, el terminal de acceso identifica un conjunto de capas y protocolos (o capas/protocolos, que se identifican por sus Tipos) a negociar, en el bloque 730. Para cada capa y protocolo seleccionados, el terminal de acceso identifica un conjunto de configuraciones aceptables (que se identifican por sus Subtipos), en el bloque 732. El terminal de acceso genera y envía entonces uno o más mensajes de solicitud-configuración por el canal dedicado inverso a la red de radio, en el bloque 734.

Cada mensaje de solicitud-configuración incluye uno o más Tipos que identifican las correspondientes capas/proto-
colos (una, uno o más) a negociar. Para cada Tipo, el mensaje incluye adicionalmente una lista de uno o más Subtipos aceptables, en orden descendiente de preferencia. En una realización, para simplificar el procesamiento de mensajes, cada mensaje de solicitud-configuración incluye una o más listas de Subtipos completas y ordenadas (es decir, una lista de Subtipos no se subdivide dentro de un mensaje de solicitud-configuración y no se subdivide entre múltiples mensajes de solicitud-configuración).

La red de radio recibe el mensaje, o mensajes, de solicitud-configuración, en el bloque 736, e identifica cada Tipo y su lista asociada de Subtipos, en el bloque 738. Para cada Tipo reconocido en el mensaje de solicitud-configuración, la red de radio selecciona un Subtipo aceptable entre la lista asociada de Subtipos previamente identificados por el terminal de acceso como aceptables, en el bloque 740. Si la red de radio no reconoce el Tipo o no halla un Subtipo aceptable en la lista asociada, ese Tipo se pasa por alto. La red de radio genera y envía entonces un mensaje de respuesta-configuración que incluye el Tipo, o Tipos, procesado(s) por la red de radio, y el Subtipo seleccionado para cada Tipo, en el bloque 742. Todo Tipo descartado por la red de radio se omite del mensaje de respuesta-configuración. En una realización, para simplificar el procesamiento por parte del terminal de acceso, el Tipo, o Tipos, en el mensaje de respuesta-configuración se dispone(n) en el mismo orden hallado en el mensaje de solicitud-configuración.

El terminal de acceso recibe el mensaje de respuesta-configuración, en el bloque 746, y compara el Tipo, o Tipos, en el mensaje de respuesta-configuración, con el Tipo, o Tipos, en el mensaje de solicitud-configuración, en el bloque 748. Para cada Tipo en el mensaje de solicitud-configuración que no se halle en el mensaje de respuesta-configuración, el terminal de acceso fija el Subtipo para ese Tipo en el valor por omisión, en el bloque 750. Para cada Tipo en el mensaje de respuesta-configuración, el terminal de acceso fija el Subtipo para ese Tipo en el Subtipo asociado hallado en el mensaje de respuesta-configuración recibido, en el bloque 752.

En una realización, la red de radio declara un fallo de configuración, en el bloque 744, si determina, en cualquier momento durante el intercambio de mensajes, que los Tipos o Subtipos seleccionados por el terminal de acceso no funcionarán.

En una realización, el terminal de acceso declara un fallo de configuración, en el bloque 754, si determina, en cualquier momento durante el intercambio de mensajes, que:

1)

el mensaje de respuesta-configuración recibido no tiene ningún mensaje asociado de solicitud-configuración,

2)

el mensaje de respuesta-configuración incluye múltiples valores de atributo (es decir, múltiples Subtipos) para un atributo (es decir, Tipo),

3)

el mensaje de respuesta-configuración incluye un atributo no hallado en el mensaje de solicitud-configuración asociado,

4)

el mensaje de respuesta-configuración incluye un valor de atributo no hallado en el mensaje de solicitud-configuración,

5)

el mensaje de respuesta-configuración incluye un atributo en un orden que es distinto al orden en el mensaje de solicitud-configuración asociado, o bien

6)

las configuraciones seleccionadas por la red de radio no funcionarán.

\newpage

El fallo de configuración también puede ser declarado por el terminal de acceso y por la red de radio basándose en algunas otras condiciones.

Si se declara un fallo de configuración, la entidad que declara el fallo cierra la sesión. El Tipo de cierre y el Subtipo de cierre se fijan en el Tipo y Subtipo, respectivamente, de los protocolos de la capa de enlace. En una realización, si el terminal de acceso y la red de radio no son capaces de acordar la configuración para una o más capas/protocolos de sesión, se cierra la sesión.

Una vez que se completa la subfase 622 de negociación de capa/protocolo de sesión para una capa/protocolo específicos, el terminal de acceso y la red de radio ingresan en la subfase 624 de configuración de capa/protocolo de sesión para esa capa/protocolo. En la subfase 624, el terminal de acceso y la red de radio determinan la configuración de las capas y protocolos negociados durante la subfase 622 de negociación de capas/protocolos de sesión. Los mensajes para la subfase 624 son transportados por sus respectivos Tipos de capa/protocolo.

Las subfases de configuración de capa/protocolo de sesión para la(s) capa(s)/protocolo(s) seleccionado(s) pueden efectuarse en serie, o en paralelo, para acelerar el proceso de configuración. Para una compatibilidad mejorada, puede diseñarse la red de radio a fin de brindar soporte a la configuración tanto en serie como en paralelo, y el terminal de acceso puede diseñarse para brindar soporte a una configuración bien en serie o bien en paralelo, o posiblemente a ambas.

La implementación de la subfase 624 de configuración depende de la capa/protocolo específico a configurar. Pueden contemplarse diversas implementaciones de la fase 624 de configuración, y están dentro del ámbito de la presente invención.

La Fig. 7C muestra un diagrama de flujo de una realización de la subfase 626 de activación de capa/protocolo de sesión. Al completar la subfase 624 de configuración de capa/protocolo de sesión para todas las capas y protocolos negociados, el terminal de acceso y la red de radio ingresan a la subfase 626 de activación de capa/protocolo de sesión. En la subfase 626, el terminal de acceso y la red de radio activan las capas y protocolos de sesión negociados. Los mensajes en la subfase 626 son transportados por el protocolo de sesión.

En una realización, el terminal de acceso inicia la subfase 626 de activación enviando un mensaje de solicitud-activación-sesión por el canal dedicado inverso, en el bloque 780. Si el terminal de acceso requiere la liberación de la conexión a fin de activar las capas y protocolos negociados, indica este requisito en el mensaje de solicitud-activación-sesión. La red de radio recibe y procesa el mensaje, en el bloque 782. La red de radio envía entonces un mensaje de respuesta-activación-sesión por el canal dedicado directo, en el bloque 784. Si se requiere una liberación de la conexión, la red de radio indica este requisito en el mensaje de respuesta-activación-sesión.

En el bloque 786, se toma una determinación en cuanto a si el terminal de acceso o la red de radio requieren la liberación de la conexión a fin de activar las capas y protocolos negociados. Si se requiere una liberación de la conexión, el terminal de acceso libera la conexión, en el bloque 788. Al liberar la conexión, el terminal de acceso y la red de radio activan y utilizan las capas y protocolos negociados, en el bloque 790. Alternativamente, puede tomarse una determinación en cuanto a si el mensaje de respuesta-activación-sesión es recibido por el terminal de acceso, en el bloque 792. Si se recibe el mensaje de respuesta-activación-sesión, el terminal de acceso y la red de radio activan y utilizan las capas y protocolos negociados. El terminal de acceso devuelve un mensaje de confirmación a la red de radio al recibir el mensaje de respuesta-activación-sesión.

Durante la sesión, si se determina que se requieren distintas capas, protocolos y/o configuraciones, en el bloque 796, se termina la sesión actual y se establece una nueva sesión, en el bloque 798.

En una realización, la subfase 622 de negociación de capa/protocolo de sesión puede efectuarse para todas las capas y protocolos seleccionados y, a continuación, la subfase 624 de configuración de capa/protocolo de sesión se lleva a cabo para cada capa y protocolo seleccionados. Alternativamente, la subfase 622 de negociación de capa/protocolo de sesión puede realizarse para un número específico de capas y protocolos seleccionados (p. ej., una capa o protocolo), seguida a continuación por la subfase 624 de configuración de capa/protocolo de sesión para las capas y protocolos seleccionados (p. ej., las subfases de negociación y configuración se efectúan como una combinación para cada capa y protocolo).

La Fig. 8 muestra un diagrama de flujo de mensajes de una implementación específica de la subfase 622 de negociación de capa/protocolo de sesión y de la subfase 624 de configuración de capa/protocolo de sesión, iniciadas por un terminal de acceso para establecer un enlace de comunicación con una red de radio. El terminal de acceso inicia la negociación de la sesión enviando un mensaje 810 de solicitud-apertura a la red de radio mediante un canal común (p. ej., el canal 444 de acceso en la Fig. 4, o un canal de acceso en un sistema conforme al estándar IS-95). El mensaje de solicitud-apertura incluye un identificador de mensaje y un identificador de transacción que identifican, respectivamente, el mensaje y la transacción ante la red de radio. La red de radio recibe y procesa el mensaje de solicitud-apertura y devuelve un mensaje 812 de respuesta-apertura al terminal de acceso. El mensaje de respuesta-apertura incluye los identificadores de mensaje y de transacción, un código de resultado correspondiente al resultado de la solicitud de apertura y un identificador de terminal de acceso, si se acepta la solicitud.

El terminal de acceso y la red de radio determinan luego las capas y protocolos a negociar. Esto puede lograrse mediante un intercambio de mensajes 820 y 822 entre el terminal de acceso y la red de radio por los canales asignados de tráfico directo e inverso (p. ej., el canal 426 de tráfico directo y el canal 442 de tráfico inverso en la Fig. 4). Múltiples mensajes pueden ser enviados por el terminal de acceso y la red de radio. El mensaje, o mensajes, enviado(s) por el terminal de acceso se representa(n) simbólicamente como el mensaje 820 en la Fig. 8 y el mensaje, o mensajes, enviado(s)
por la red de radio se representa(n) simbólicamente como el mensaje 822.

En una realización, los mensajes de solicitud-apertura y respuesta-apertura se envían por los canales comunes (p. ej., el canal de acceso y el de control), que son compartidos con otros terminales de acceso, pero los mensajes de negociación y configuración se envían por los canales dedicados asignados por la red de radio. Los mensajes de solicitud-apertura y respuesta-apertura se diseñan para que sean breves. Los mensajes de negociación y configuración, típicamente, son más largos, y se envían mediante los canales dedicados asignados para prestaciones mejoradas (es decir, tiempo de respuesta más breve).

Una vez que se seleccionan las capas y los protocolos, se efectúa posteriormente la negociación para cada capa y protocolo seleccionados. En una realización, las capas y protocolos seleccionados por una entidad (p. ej., el terminal de acceso) se negocian primero, y las capas y protocolos seleccionados por la otra entidad (p. ej., la red de radio) se negocian luego. La entidad que negocia una capa o protocolo específico envía a la otra entidad un mensaje 830 (u 840) de solicitud-configuración que incluye una o más capas y/o protocolos seleccionados, y una lista de configuraciones aceptables para cada capa y protocolo seleccionados. (Las capas y protocolos negociados también se denominan atributos, y las configuraciones también se denominan valores de atributos).

La otra entidad recibe el mensaje, o mensajes, de solicitud-configuración, y responde con el mensaje, o mensajes, correspondiente(s) 832 (u 842) de respuesta-configuración, que incluye(n) las capas y/o protocolos negociados, y sus configuraciones seleccionadas. El intercambio de mensajes de solicitud/respuesta de configuración continúa hasta que ambas entidades aceptan los atributos negociados. Un mensaje 834 (u 844) de confirmación es enviado entonces por la entidad que inicia la negociación, para confirmar la aceptación del atributo negociado. Los atributos adicionales seleccionados, si los hubiera, se negocian luego de manera similar.

En la Fig. 8, los mensajes 830 y 832 de negociación y el mensaje 834 de confirmación representan los mensajes para un conjunto de atributos (es decir, una capa, un protocolo, etc.). Otro conjunto de mensajes se envía para cada conjunto de atributos seleccionados para negociación. En la realización mostrada en la Fig. 8, los mensajes 840 y 842 de negociación y el mensaje 844 de confirmación para el conjunto de atributos seleccionados para la negociación por la red de radio se intercambian después de que se han negociado los atributos seleccionados por el terminal de acceso.

Al completar la negociación del protocolo, la comunicación entre el terminal de acceso y la red de radio puede efectuarse utilizando las capas y protocolos negociados.

De acuerdo a un aspecto de la invención, el terminal de acceso y la red de radio se diseñan para brindar soporte a un conjunto básico de mensajes. En una realización, el terminal de acceso y la red de radio brindan soporte a los mensajes enumerados en la Tabla 1, que se describen en más detalle más adelante.

\vskip1.000000\baselineskip

TABLA 1

1

\vskip1.000000\baselineskip

La Fig. 9A es un diagrama de una realización de un formato para el mensaje de solicitud-apertura. En esta realización, el mensaje de solicitud-apertura incluye un campo 910 de identificador de mensaje y un campo 912 de identificador de transacción. En una realización, el campo 910 del identificador de mensaje es un campo de 8 bits con un valor de 0x00 que identifica el mensaje de solicitud-apertura, y el campo 912 de identificador de transacción también es un campo de 8 bits con un valor que se incrementa con cada nuevo mensaje de solicitud-apertura enviado.

La Fig. 9B es un diagrama de una realización de un formato para el mensaje de respuesta-apertura. En esta realización, el mensaje de respuesta-apertura incluye un campo 920 de identificador de mensaje, un campo 922 de identificador de transacción, un campo 924 de código de resultado, un campo 926 de identificador de terminal de acceso y un campo 928 de temporizador de inactividad de sesión. En una realización, el campo 920 de identificador de mensaje es un campo de 8 bits con un valor de 0x01 que identifica el mensaje de respuesta-apertura, y el campo 922 de identificador de transacción también es un campo de 8 bits que contiene el valor del campo 912 de identificador de transacción en el correspondiente mensaje recibido de solicitud-apertura que está siendo procesado. En una realización, el campo 924 de código de resultado es un campo de 8 bits con un valor de 0x00 si la solicitud de apertura es aceptada, un valor de 0x01 si la solicitud de apertura es rechazada por un motivo no especificado, y un valor de 0x02 si la solicitud de apertura es rechazada debido a la falta de recursos. También pueden generarse valores adicionales, o distintos, para el campo 924 del código de resultado.

En una realización, el campo 926 de identificador de terminal de acceso es un campo de 4 octetos de bits con un valor asignado como el identificador del terminal de acceso a ser utilizado por el terminal de acceso en el curso de la sesión. Si el valor en el campo 924 de código de resultado es 0x00, entonces el campo 926 de identificador de terminal de acceso se fija en 0x00000000, y el terminal de acceso ignora este valor. En una realización, el campo 928 del temporizador de inactividad de sesión es un campo de 8 bits con un valor que indica la duración de la inactividad, en minutos, de la sesión. Si el valor en el campo 924 del código de resultado es 0x00, lo que indica la aceptación de la solicitud de apertura, entonces la red de radio fija el valor en el campo 928 del temporizador de inactividad de sesión en un valor tomado de un temporizador de inactividad de sesión que se emplea para la sesión. Si el valor en el campo 924 del código de resultado no es 0x00, lo que indica el rechazo de la solicitud de apertura, entonces el campo 928 del temporizador de inactividad de la sesión se fija en 0x00, y el terminal de acceso ignora este valor.

La Fig. 9C es un diagrama de una realización de un formato para el mensaje de cierre. En esta realización, el mensaje de cierre incluye un campo 930 de identificador de mensaje, un identificador 932 de transacción, un campo 934 de razón del cierre, un campo 936 de longitud de la información adicional y un campo 938 de información adicional. En una realización, el campo 930 del identificador de mensaje es un campo de 8 bits con un valor de 0x02 que identifica el mensaje de cierre, y el campo 932 del identificador de transacción también es un campo de 8 bits con un valor que se incrementa con cada nuevo mensaje de cierre enviado. En una realización, el campo 934 de razón del cierre es un campo de 1 octeto de bits con un valor que identifica la razón del cierre, el campo 936 de la longitud de la información adicional es un campo de 1 octeto de bits con un valor que identifica la longitud (en octetos de bits) del subsiguiente campo 938 de información adicional, y el campo 938 de información adicional es un campo de longitud variable que contiene información adicional referida al cierre. El formato para el campo 938 de información adicional depende del cierre específico.

La Fig. 9D es un diagrama de una realización de un formato para el mensaje "hola". En esta realización, el mensaje "hola" incluye un campo 940 de identificador de mensaje de 8 bits con un valor de 0x03 que identifica el mensaje "hola".

La Fig. 9E es un diagrama de una realización de un formato para el mensaje de solicitud-configuración. En esta realización, el mensaje de solicitud-configuración incluye un campo 950 de tipo, un campo 952 de identificador de mensaje, un campo 954 de identificador de transacción y un campo 956 de lista de atributos. En una realización, el campo 950 de tipo es un campo de 8 bits con un valor que identifica el tipo del protocolo que se está configurando, el campo 952 de identificador de mensaje es un campo de 8 bits con un valor de 0x04 que identifica el mensaje de solicitud-configuración y el campo 954 del identificador de transacción también es un campo de 8 bits con un valor que se incrementa con cada nuevo mensaje de solicitud-configuración enviado. En una realización, el campo 956 de la lista de atributos es un campo de longitud variable que incluye una lista de Subtipos aceptables para cada Tipo a negociar, incluyendo cada elemento de la lista uno o más pares (Tipo, Subtipo). En una realización, si una lista incluye más de un elemento, entonces los elementos se disponen en orden descendiente de preferencia. La entidad receptora puede determinar la longitud del mensaje de solicitud-configuración utilizando la longitud del mensaje.

La Fig. 9F es un diagrama de una realización de un formato para el mensaje de respuesta-configuración. En esta realización, el mensaje de respuesta-configuración incluye un campo 960 de tipo, un campo 962 de identificador de mensaje, un campo 964 de identificador de transacción y un campo 966 de lista de atributos. En una realización, el campo 960 de tipo es un campo de 8 bits con un valor que identifica el tipo de protocolo que se está configurando, el campo 962 del identificador de mensaje es un campo de 8 bits con un valor de 0x05 que identifica el mensaje de respuesta-configuración, y el campo 922 del identificador de transacción también es un campo de 8 bits que contiene el valor del campo 954 de identificador de transacción en el mensaje recibido de solicitud-configuración que está siendo procesado.

En una realización, el campo 966 de la lista de atributos es un campo de longitud variable que incluye uno (o tal vez más) Subtipo(s) aceptable(s) para cada Tipo procesado. Los elementos en el campo 966 de la lista de atributos son pares (Tipo, Subtipo). El campo 966 de la lista de atributos no contiene un elemento no hallado en el correspondiente mensaje de solicitud-configuración, y los elementos en el campo 966 de la lista de atributos están dispuestos en el orden hallado en el correspondiente mensaje de solicitud-configuración. Nuevamente, la entidad receptora puede determinar la longitud del mensaje de respuesta-configuración utilizando la longitud del mensaje.

La Fig. 9G es un diagrama de una realización de un formato para el mensaje de solicitud-activar-sesión. En esta realización, el mensaje de solicitud-activar-sesión incluye un campo 970 de identificador de mensaje, un campo 972 de identificador de transacción y un campo 974 de indicación-liberación-conexión. En una realización, el campo 970 del identificador de mensaje es un campo de 8 bits con un valor de 0x06 que identifica el mensaje de solicitud-activar-sesión, y el campo 972 del identificador de transacción también es un campo de 8 bits con un valor que se incrementa con cada nuevo mensaje de solicitud-activar-sesión enviado. En una realización, el campo 974 de indicación-liberación-conexión es un campo de 1 octeto de bits con un valor de 0x01 si el terminal de acceso requiere que la conexión sea liberada a fin de efectuar la transición a la subfase de negociación o configuración de la capa/protocolo de sesión, y un valor de 0x00 en caso contrario.

La Fig. 9H es un diagrama de una realización de un formato para el mensaje de respuesta-activar-sesión. En esta realización, el mensaje de respuesta-activar-sesión incluye un campo 980 de identificador de mensaje, un campo 982 de identificador de transacción y un campo 984 de indicación-liberación-conexión. En una realización, el campo 980 del identificador de mensaje es un campo de 8 bits con un valor de 0x07 que identifica el mensaje de respuesta-activar-sesión, y el campo 982 del identificador de transacción también es un campo de 8 bits que contiene el valor del campo 972 del identificador de transacción en el mensaje recibido de solicitud-activar-sesión que está siendo procesado. En una realización, el campo 984 de indicación-liberación-conexión es un campo de 1 octeto de bits con un valor de 0x01 si el terminal de acceso, o la red de radio, requiere que la conexión sea liberada a fin de efectuar la transición a la subfase de negociación o configuración de capa/protocolo de sesión, y un valor de 0x00 en caso contrario.

Las Figs. 9A a 9H muestran diagramas de una implementación específica de algunos de los mensajes que pueden emplearse para la configuración de aplicaciones, capas y protocolos. También pueden definirse y emplearse mensajes adicionales y/o distintos a aquellos anteriormente descritos (p. ej., un mensaje de activación, un mensaje de configuración completa, y muchos otros), y esto está dentro del ámbito de la presente invención. Además, los mensajes pueden diseñarse para tener formatos de mensaje, campos y formatos de campo distintos (o adicionales) a aquellos mostrados en las Figs. 9A a 9H, y esto también está dentro del ámbito de la presente invención.

La invención brinda numerosas ventajas. En primer lugar, el diseño modular de las capas y protocolos permite la fácil modificación y actualización del sistema de comunicación a fin de brindar soporte a nuevas características y funcionalidades. El terminal de acceso y la red de radio pueden comunicarse utilizando las capas y protocolos que reciben soporte común de ambos, y esta determinación puede tomarse en el momento en que se abre una sesión. En segundo lugar, el conjunto básico de capas y protocolos que dispone de soporte de los terminales de acceso y las redes de radio garantiza un nivel mínimo de compatibilidad entre los terminales de acceso y las redes de radio. Para que una red de radio sea compatible, en versiones actuales y futuras, con este protocolo de señalización, sólo necesita implementar un conjunto limitado de funcionalidades. Por ejemplo, la red de radio sólo necesita ser capaz de enviar un mensaje vacío de respuesta-configuración en respuesta a un mensaje recibido de solicitud-configuración. De esta manera, el protocolo de señalización de la invención permite una fácil implementación de configuraciones futuras incluso si no se necesita ninguna configuración actual.

La invención puede implementarse de diversas formas, y puede implementarse en software, hardware, o una combinación de los mismos. Por ejemplo, haciendo referencia a la Fig. 2, la invención puede implementarse por una combinación de software y/o hardware dentro del sistema 214 de control y el controlador 262, u otras unidades acopladas con el sistema 214 de control y el controlador 262. El hardware puede implementarse en uno o más circuitos integrados, un circuito integrado específico para la aplicación (ASIC), un procesador de señales digitales (DSP), un controlador, un microprocesador u otros circuitos diseñados para llevar a cabo las funciones aquí descritas.

La invención aquí descrita puede aplicarse a muchos sistemas de comunicaciones de espectro extendido. La invención es aplicable a los sistemas de espectro extendido que existen actualmente y a los nuevos sistemas que están considerándose continuamente. Se describe un sistema CDMA específico en la precitada Solicitud de Patente Estadounidense con Nº de Serie 08/963.386. Otro sistema CDMA se revela en las precitadas Patentes Estadounidenses Nº 4.901.307 y 5.103.459.

La descripción precedente de las realizaciones preferidas se proporciona a fin de permitir que cualquier persona versada en la técnica haga o utilice la presente invención. Las diversas modificaciones a estas realizaciones serán inmediatamente evidentes a los versados en la técnica, y los principios enéricos aquí definidos pueden aplicarse a otras realizaciones sin el empleo de la facultad inventiva. Así, la presente invención no pretende estar limitada a las realizaciones aquí mostradas, sino al alcance de las reivindicaciones adjuntas.

Claims (25)

1. Un procedimiento para configurar una capa de un protocolo de interfaz aérea antes del comienzo de la comunicación de datos entre una primera entidad (250) y una segunda entidad (210), en el cual el protocolo de interfaz aérea comprende una pluralidad de capas modulares predefinidas dentro de una arquitectura de capas y cada una de dichas capas modulares puede modificarse sin modificar las capas restantes, y en el cual cada capa consiste en uno o más protocolos, que realiza una funcionalidad de la capa, comprendiendo el procedimiento:

seleccionar, en la primera entidad (250), un conjunto de una o más capas enteras (310-324) del protocolo de interfaz aérea a negociar, en donde cada capa entera (310-324) seleccionada corresponde a un atributo seleccionado a negociar entre las entidades primera (250) y segunda (210);

para cada atributo seleccionado, determinar (732) una lista del valor, o valores, de atributo seleccionado que se considera aceptable para la primera entidad (250);

enviar (732) desde la primera entidad (250) una lista de atributos seleccionados y sus listas asociadas de valores de atributo seleccionados;

recibir (746) en la primera entidad (250) una lista de atributos procesados y sus listas asociadas de valores de atributo procesados, en donde cada lista de valores de atributo procesados incluye uno o más valores de atributo considerados aceptables para la segunda entidad (210); y

configurar (752) el uno o más protocolos, del conjunto seleccionado de una o más capas en la primera entidad (250) de acuerdo a la lista recibida de atributos procesados y sus listas asociadas de valores de atributo procesados.

2. El procedimiento de la reivindicación 1, en el cual los elementos en cada lista de valores de atributo seleccionados están dispuestos en un orden basado en la preferencia de la primera entidad (250).

3. El procedimiento de la reivindicación 1, en el cual cada atributo procesado está asociado con un valor de atributo procesado.

4. El procedimiento de la reivindicación 1, en el cual las capas (310-324) en la primera entidad (250) se configuran con sus valores por omisión si no se reciben los correspondientes valores de atributo procesados en la primera entidad (250).

5. El procedimiento de la reivindicación 1, en el cual el envío (734) y la recepción (746) se logran mediante canales de comunicaciones dedicados.

6. El procedimiento de la reivindicación 1, en el cual la entidad primera o segunda (210), o ambas, implementan una máquina de estados con una pluralidad de estados, que incluyen un estado inactivo (630, 640), que indica inactividad antes de una negociación de sesión, un estado iniciado (632, 634, 642, 644), que indica la negociación de sesión con respecto a la lista de atributos seleccionados, y un estado abierto (636, 646) que indica la comunicación activa entre las entidades primera (250) y segunda (210).

7. El procedimiento de la reivindicación 6, en el cual el estado iniciado (632, 634, 642, 644) incluye un estado iniciado (632, 642) de terminal de acceso, que indica la negociación de sesión con respecto a los atributos seleccionados por la primera entidad (250) y un estado iniciado (634, 644) de red de radio, que indica la negociación de sesión con respecto a los atributos seleccionados por la segunda entidad (210).

8. El procedimiento de la reivindicación 1, en el cual la lista de atributos seleccionados y sus listas asociadas de valores de atributo seleccionados se envía desde la primera entidad (250) mediante uno o más mensajes (830) de solicitud-configuración.

9. El procedimiento de la reivindicación 1, en el cual el conjunto de atributos procesados y sus listas asociadas de valores de atributo procesados son recibidos en la primera entidad (250) mediante uno o más mensajes (832) de respuesta-configuración.

10. El procedimiento de la reivindicación 2, en el cual los atributos procesados y sus listas asociadas de valores de atributo procesados son recibidos en un orden que corresponde a un orden de los atributos seleccionados y sus listas asociadas de valores de atributo seleccionados.

11. El procedimiento de la reivindicación 1, en el cual la comunicación entre las entidades primera (250) y segunda (210) tiene lugar mediante capas y protocolos por omisión antes de completar la configuración del conjunto seleccionado de una o más capas en la primera entidad (250).

\newpage

12. El procedimiento de la reivindicación 1, que comprende adicionalmente:

recibir un identificador de entidad en la primera entidad (250), y en donde los mensajes subsiguientes enviados desde la primera entidad (250) son identificados por el identificador de entidad.

13. El procedimiento de la reivindicación 1, en el cual la primera entidad (250) selecciona un primer conjunto de atributos a negociar y la segunda entidad (210) selecciona un segundo conjunto de atributos a negociar, y en el cual la negociación del primer conjunto de atributos seleccionados por la primera entidad (250) se completa antes de la negociación del segundo conjunto de atributos seleccionados por la segunda entidad (210).

14. El procedimiento de cualquiera de las reivindicaciones 1 a 13, en el cual la primera entidad (250) es un terminal de acceso.

15. El procedimiento de cualquiera de las reivindicaciones 1 a 14, en el cual la segunda entidad (210) es una red de radio.

16. El procedimiento de la reivindicación 1, que comprende adicionalmente:

enviar (710) desde la primera entidad (250) un mensaje (810) de solicitud-apertura, que indica una solicitud para abrir una sesión de comunicaciones; y

recibir en la primera entidad (250) un mensaje (812) de respuesta-apertura, que indica una aceptación o rechazo de la solicitud para abrir la sesión de comunicaciones.

17. El procedimiento de la reivindicación 16, en el cual el mensaje (810) de solicitud-apertura y el mensaje (812) de respuesta-apertura se envían y se reciben mediante canales de comunicaciones comunes.

18. El procedimiento de la reivindicación 1, que comprende adicionalmente las etapas de:

mantener un conjunto de capas y protocolos por omisión, para su empleo en una primera entidad a fin de comunicarse con una segunda entidad;

proporcionar una máquina de estados que indica un estado de comunicaciones de la primera entidad (250):

en donde las etapas de enviar (734) y recibir (746) se llevan a cabo utilizando un conjunto de mensajes de configuración que comprenden información de configuración referida a cada atributo configurable.

19. El procedimiento de la reivindicación 18, en el cual los mensajes de configuración se implementan en una capa (320) de sesión del sistema de comunicaciones.

20. El procedimiento de la reivindicación 18, en el cual el conjunto de capas y protocolos por omisión incluye un protocolo de sobregasto para enviar y recibir mensajes que brindan soporte a la negociación y configuración del conjunto de atributos configurables.

21. El procedimiento de la reivindicación 18, en el cual la máquina de estados incluye un estado inactivo (630) que indica la inactividad antes de la negociación de una sesión, un estado iniciado (632, 634) que indica la negociación de sesión con respecto a una lista de atributos seleccionados, y un estado abierto (636) que indica la comunicación activa entre las entidades primera (250) y segunda (210).

22. El procedimiento de la reivindicación 18, en el cual cada mensaje de configuración incluye un identificador de entidad que identifica a la primera entidad (250).

23. El procedimiento de la reivindicación 18, en el cual cada mensaje de configuración incluye un identificador (912, 922, 932, 954, 964, 972, 982) de transacción que identifica una instancia específica del mensaje de configuración.

24. Un terminal (250) de acceso para un sistema (100) de comunicaciones de espectro extendido que comprende un controlador (262) configurado para recibir y procesar datos, un codificador (264) acoplado al controlador (262) y configurado para codificar datos procesados desde el controlador (262), un modulador (266) acoplado al codificador (264) y configurado para modular datos codificados desde el codificador (264), y un transmisor (268) acoplado al modulador (266) y configurado para convertir los datos modulados desde el modulador (266) en una señal analógica adecuada para su transmisión por un medio de transmisión, y en el cual el controlador (262) está adicionalmente configurado para implementar un conjunto de capas modulares de un protocolo de interfaz aérea utilizado para brindar soporte a la transmisión de datos, estando las capas modulares predefinidas dentro de una arquitectura de capas, consistiendo cada capa en uno o más protocolos que realizan una funcionalidad de la capa, caracterizado porque:

cada capa entera de una o más de las capas configurables del protocolo de interfaz aérea corresponde a un atributo negociable por el terminal (250) de acceso para configurar el protocolo, o protocolos, de cada una de dichas capas entre la capa, o capas, configurable(s) antes de la transmisión de datos.

25. El terminal (250) de acceso de la reivindicación 24, que comprende adicionalmente:

un receptor (256) configurado para recibir una señal del enlace directo;

un demodulador (258) acoplado al receptor (256) y configurado para demodular la señal del enlace directo recibida; y

un descodificador (260) acoplado al demodulador (258) y configurado para descodificar la señal demodulada desde el demodulador (258) a fin de generar datos descodificados; y

en el que el controlador (262) se acopla adicionalmente al descodificador (260) y está operativo para configurar una o más de las capas configurables del protocolo de interfaz aérea, basándose, al menos en parte, en los datos descodificados desde el descodificador (260).