MXPA06012747A - Metodo y aparato para gestion de restraso adaptivo en un sistema de comunicacion inalambrica. - Google Patents

Abstract

Medios de gestion de retraso adaptivo y metodo para asignar recursos que tienen diferentes requerimientos de Calidad de Servicio (QoS); un programador de Enlace de Avance (FL) prepara los casos de transmision mediante el tratamiento de colas de datos pendientes de acuerdo con una clase de prioridad, tal como Mejor Esfuerzo (BE) y Reenvio Acelerado (EF); los bits de datos provenientes de multiples colas son puestos en un caso de transmision; se utilizan varias metricas para generar un conjunto de candidatos para transmision y despues seleccionar y construir un siguiente caso de transmision a partir del conjunto de candidatos.

Description

MÉTODO Y APARATO PARA GESTIÓN DE RESTRASO ADAPTIVO EN UN SISTEMA DE COMUNICACIÓN INALÁMBRICA CAMPO DE LA INVENCIÓN La presente invención pertenece generalmente a comunicaciones, y muy específicamente a una programación de transmisiones en un sistema de comunicación inalámbrica utilizando gestión de retraso adaptivo.

ANTECEDENTES DE LA INVENCIÓN Los sistemas de comunicación inalámbrica incluyen sistemas que procesan comunicaciones utilizando un circuito conmutado, o asignación de recursos fijos, tecnología de tipo y sistemas gue procesan comunicaciones utilizando un paquete conmutado, o tecnología de tipo asignación de recurso dinámico. La conmutación de circuito y la conmutación de paquete se pueden utilizar en redes de alta capacidad. En un sistema de comunicaciones de circuito conmutado, se establece una trayectoria de comunicación dedicada entre el remitente y el receptor; y los recursos de red entre el transmisor y el receptor se consideran estáticos antes del inicio de la transferencia, creando asi un "circuito". Los recursos permanecen dedicados al circuito durante toda la transferencia y todo el mensaje sigue la misma trayectoria. En las redes de paquete conmutado, el mensaje es separado en paquetes, cada uno de los cuales puede tomar una ruta diferente al destino de los paquetes. Al momento de la recepción, los paquetes son recopilados para recuperar el mensaje original. En un sistema de paquete conmutado, los paquetes que representan los mensajes o fragmentos de mensajes son individualmente enrutados entre nodos. Los paquetes son enrutados a un destino a través de una ruta conveniente. En otras palabras, no todos los paquetes que se desplazan entre los dos mismos huéspedes necesariamente seguirán la misma ruta, incluso cuando dichos paquetes son parte de un solo mensaje. En un sistema de paquete conmutado, o sistema de datos de paquete compartido, se puede utilizar un servicio de Voz sobre Protocolo de Internet (VoIP) para emular las comunicaciones de voz de circuito conmutado. VolP típicamente es una aplicación o servicio sensible al retraso, y por lo tanto, se utilizan mecanismos de Calidad de Servicio para cumplir con las restricciones de retraso en la entrega de paquetes. Otros servicios y tipos de transmisiones también tienen varios requerimientos de retraso u objetivos para asegurar la QoS. Por consiguiente, existe la necesidad de gestión de retraso adaptiva para programar transmisiones en un sistema de comunicación.

BREVE DESCRIPCIÓN DE LAS FIGURAS Las características, objetivos y ventajas del método y aparato aqui descritos serán más aparentes a partir de la descripción detallada que se estipula a continuación, cuando se considere en conjunto con las figuras en donde caracteres de referencia similares se identifican de manera correspondiente en el texto. La figura 1A es un sistema de comunicación inalámbrica. La figura IB es un sistema de comunicación inalámbrica que soporta transmisiones de datos de alta velocidad; La figura 2 es un diagrama en bloques de una Red de Acceso (AN) en un sistema de comunicación inalámbrica. La figura 3 es un diagrama de flujo de un algoritmo de programación para transmisiones en un sistema de comunicación inalámbrica. La figura 4 ilustra la categorización de programadores de datos en paquete. La figura 5 ilustra un lazo de retroalimentación para determinar las mediciones de intensidad de canal con base en las solicitudes de datos recibidas por parte de un usuario . La figura 6 ilustra el comportamiento de un programador en presencia de usuarios de Reenvió Acelerado (EF) únicamente con un solo tipo de tráfico. La figura 7 ilustra el cálculo del polinomio de carga útil condensada c(z) a partir del polinomio de carga útil p (z) . La figura 8 ilustra un programador de acuerdo con una modalidad. La figura 9 ilustra una porción del programador de la figura 8 de acuerdo con una modalidad. La figura 10 ilustra un algoritmo de programación para ejecutar gestión de retraso adaptivo de transmisiones. La figura 11 ilustra una porción del algoritmo de programación de la figura 10, de acuerdo con una modalidad. La figura 12 ilustra una porción del algoritmo de programación de la figura 10, de acuerdo con una modalidad. La figura 13 ilustra una porción del algoritmo de programación de la figura 10, de acuerdo con una modalidad.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La operación de un sistema de comunicación que soporta servicios y aplicaciones que tienen diferentes requerimientos QoS pueden ser sub-óptimos e indeficientes.

Por ejemplo, aplicaciones VolP tienen requerimientos de retraso. Un método emula la voz proporcionando restricciones de retraso iguales para múltiples usuarios independientes de carga y cobertura. Dicho enfoque es su-óptimo en lo que respecta a la asignación de recursos para garantizar un retraso igual y en lo que respecta a evitar optimizaciones posibles para aumentar la capacidad del sistema. En una modalidad, la capacidad del sistema se puede incrementar proveyendo retraso desigual para varios usuarios, en donde los recursos son asignados como una función de carga y cobertura. El siguiente análisis se refiere a un algoritmo de programación para el Enlace de Avance (FL) de un sistema que soporta operación lxEV-DO, es decir, que soporta la norma IS-856. En una modalidad, un algoritmo de programación toma ventaja de los diversos paquetes de múltiples usuarios y paquetes cortos para cumplir con los requerimientos de calidad QoS de varias aplicaciones al mismo tiempo que se intenta elevar al máximo la capacidad del FL. El algoritmo de programación también provee mecanismos para prioritizar varias aplicaciones. Dicha prioritización se puede basar en el tipo de flujo de aplicación, los requerimientos específicos de QoS, u otras características del flujo. En una modalidad, los flujos son programados para transmisión en el FL con base en la sensibilidad de retraso de la aplicación. En un aspecto, los flujos son diferenciados con base en la sensibilidad al retraso equilibrado con la sensibilidad del rendimiento. Aunque el siguiente análisis considera los medios de programación y métodos como ejecutados en el contexto de la Revisión A de la norma IxEV-DO, los medios de programación y métodos se pueden aplicar adicionalmente a sistemas alternos, en particular, los conceptos se pueden aplicar a sistemas en donde los usuarios son compatibles con un sub-conjunto determinado de sub-tipos como se define en la norma IS-856, específicamente "Norma de Interfaz Aérea de Datos en Paquete de Alta Velocidad cdma2000", 3GPP2 C.S0024 Ver. 4.0, octubre de 2002. En la siguiente descripción, los términos tal como "usuario Rev-A" o "usuario compatible con Rev-A" se utilizarán para hacer referencia a una Terminal de Acceso (AT) que soporta los sub-tipos de Capa de Canal de Acceso de Medio (MAC) y protocolo de Capa Física definidos en IS- 856, específicamente "Norma de Interfaz Aérea de Datos en Paquete de Alta Velocidad cdma2000", 3GPP2 C.S0024 Versión 1.0, marzo de 2004. En particular, un usuario Rev-A soporta el Protocolo MAC de Canal de Tráfico de Avance Mejorado. Los términos tales como "usuarios Rel-0" se utilizan para hacer referencia a AT que soportan los sub-tipos de Capa MAC y protocolo de Capa Física definidos en IS-856, pero los cuales no soportan sub-tipos más recientes definidos en la Revisión A. En un sistema de comunicación inalámbrica que emplea un esquema de Acceso Múltiple por División de Código, CDMA, un método de programación asigna a cada una de las unidades de suscriptor todos los canales de código a intervalos de tiempo designados en una base multiplexada de tiempo. Un nodo de comunicación central, tal como una Estación Base, BS, ejecuta la única frecuencia de portadora o código de canal asociado con el suscriptor para habilitar la comunicación exclusiva con el suscriptor. Los esquemas TDMA también se pueden ejecutar en sistemas de línea terrestre utilizando conmutación de relé de contacto físico o conmutación de paquete. Un sistema CDMA se puede designar para soportar una o más normas tal como: (1) "la Norma de Compatibilidad de Estación Móvil-Estación Base TIA/EIA/IS- 95-B para Sistema Celular de Espectro Ensanchado de Banda Ancha en Modo Dual" aquí denominada como la norma IS-95; (2) la norma ofrecida por un consorcio denominado "Proyecto de Sociedad de 3era Generación" aqui denominado como 3GPP; e incorporado en un conjunto de documentos que incluyen los Documentos Número 3G TS 25.211, 3G TS 25.212, 3G TS 25.213, y 3G TS 25.214, 3G TS 25.302, aqui denominados como la norma W-CDMA; (3) la norma ofrecida por un consorcio denominado "Proyecto 2 de Sociedad de 3era Generación" aquí denominado como 3GPP2, y TR-45.5 aquí denominado como la norma cdma2000, anteriormente denominada IS-2000 MC, ó (4) alguna otra norma inalámbrica. El sistema CDMA permite las comunicaciones de voz y datos entre usuarios en un enlace terrestre. En un sistema CDMA, las comunicaciones entre usuarios se realizan a través de una o más estaciones base. En sistemas de comunicación inalámbrica, el enlace de avance se refiere al canal a través del cual las señales se desplazan desde una estación base a una estación de suscriptor, y el enlace inverso se refiere a un canal, a través del cual, las señales se desplazan desde una estación de suscriptor a una estación base. Al transmitir datos en un enlace inverso a una estación base, un primer usuario en una estación de suscriptor se comunica con un segundo usuario en una segunda estación de suscriptor. La estación base recibe los datos desde la primera estación de suscriptor y enruta los datos a una estación base que proporciona servicio a la segunda estación de suscriptor. Dependiendo de la ubicación de las estaciones de suscriptor, ambas pueden recibir servicio por una sola estación base o múltiples estaciones base. En cualquier caso, la estación base que proporciona servicio a la segunda estación de suscriptor envía los datos en el enlace de avance. En lugar de entablar comunicación con una segunda estación de suscriptor, una estación de suscriptor también puede establecer comunicación con Internet terrestre a través de una conexión con una estación base de servicio. En comunicaciones inalámbricas, tal como aquellas que se ajustan a IS-95, las señales de enlace de avance y enlace inverso son transmitidas dentro de bandas de frecuencia separadas . La figura 1A sirve como un ejemplo de un sistema de comunicaciones 100 que soporta un número de usuarios y tiene la capacidad para ejecutar por lo menos algunos aspectos y modalidades de la invención. Se puede emplear cualquiera de una variedad de algoritmos y métodos para programar transmisiones en el sistema 100. El sistema 100 provee comunicación para un número de células 102A a 102G, cada una de las cuales recibe servicio por parte de una estación base correspondiente 104A a 104G, respectivamente. En la modalidad ejemplar, algunas de las estaciones base 104 tienen múltiples antenas de recepción y otras solo tienen una antena de recepción. De manera similar, algunas de las estaciones base 104 tienen múltiples antenas de transmisión, y otras tienen antenas de transmisión sencillas. No hay restricciones en las combinaciones de las antenas de transmisión y las antenas de recepción. Por lo tanto, es posible que una estación base 104 tenga múltiples antenas de transmisión y una sola antena de recepción, o que tenga múltiples antenas de recepción y una sola antena de transmisión, o que tenga antenas de transmisión y recepción tanto múltiples como sencillas. La creciente demanda de transmisión de datos inalámbricos y la expansión de los servicios disponibles a través de tecnología de comunicación inalámbrica han conducido al desarrollo de servicios de datos específicos. Uno de esos servicios se denomina como Alta Velocidad de Datos (HDR) . Un servicio HDR ejemplar se propone en la "Norma de Interfaz de Aire de Datos en Paquete de Alta Velocidad cdma2000 EIA/TIA-IS856" denominada como "la norma HDR". El servicio HDR generalmente es un revestimiento para un sistema de comunicación de voz que provee un método eficiente para transmitir paquetes de datos en un sistema de comunicación inalámbrica. Conforme aumenta la cantidad de datos transmitidos y el número de transmisiones, el ancho de banda limitado disponible para las transmisiones de radio se convierte en un recurso crítico. La figura IB ilustra un modelo de referencia de arquitectura para un sistema de comunicación 120 que tiene una Red de Acceso, AN, 122 que se comunica con una Terminal de Acceso, AT, 126 a través de una interfaz de aire 124. En una modalidad, el sistema 10 es un sistema de Acceso Múltiple por División de Código, CDMA, que tiene una Velocidad de Datos Alta, HDR, sistema de recubrimiento, tal como lo especificado en el estándar HDR. La AN 122 establece comunicación con la AT 126, así como con cualesquiera otras AT dentro del sistema 120 (que no se muestran), por medio de la interfaz de aire 124. La AN 122 incluye múltiples sectores, en donde cada sector provee por lo menos un Canal. Un Canal se define como el conjunto de enlaces de comunicación para transmisiones entre la AN 122 y las AT dentro de una asignación de frecuencia determinada. Un Canal consta de un Enlace de Avance (FL) para transmisiones desde la AN 122 a la AT 126 y un Enlace Inverso (RL) para transmisiones desde la AT 126 a la AN 122. Para transmisiones de datos, la AN 122 recibe una solicitud de datos de la AT 126. La solicitud de datos especifica la velocidad de datos a la que los datos van a ser enviados, la longitud del paquete de datos transmitido, y el sector desde el cual se van a enviar los datos. La AT 126 determina la velocidad de datos con base en la calidad del Canal entre la AN 122 y la AT 126. En una modalidad, la calidad del Canal queda determinada por la relación Portadora-a-Interferencia, C/I. Modalidades alternas pueden utilizar otras métricas correspondientes a la calidad del Canal. La AT 126 provee solicitudes de transmisiones de datos enviando un mensaje de Control de Velocidad de Datos, DRC, a través de un canal especifico denominado como el canal DRC. El mensaje DRC incluye una porción de velocidad de datos y una porción de sector. La porción de velocidad de datos indica la velocidad de datos solicitada para que la AN 122 envíe los datos, y el sector indica el sector desde el cual la AN 122 va a enviar los datos. Típicamente se requiere tanto la información de velocidad de datos como del sector para procesar una transmisión de datos. La porción de velocidad de datos se denomina como un valor DRC, y la porción de sector se denomina como una cubierta DRC. El valor DRC es un mensaje enviado a la AN 122 a través de la interfaz de aire 124. En una modalidad, cada valor DRC corresponde a una velocidad de datos en kbits/segundo que tiene una longitud de paquete asociada de acuerdo con una asignación de valor DRC predeterminada. La asignación incluye un valor DRC que especifica una velocidad de datos nula. En la práctica, la velocidad de datos nula indica a la AN 122 que la AT 126 no puede recibir datos. En una situación, por ejemplo, la calidad del Canal es insuficiente para que la AT 126 reciba datos de manera precisa. En operación, la AT 126 continuamente monitorea la calidad del Canal para calcular una velocidad de datos a la que la AT 126 puede recibir una siguiente transmisión de paquete de datos. La AT 126 entonces genera un valor DRC correspondiente; el valor DRC es transmitido a la AN 122 para solicitar una transmisión de datos. Se puede apreciar que, típicamente, las transmisiones de datos se dividen en paquetes. El tiempo que se requiere para transmitir un paquete de datos es una función de la velocidad de datos aplicada. La señal DRC también provee la información, la cual es utilizada por el programador de canal para determinar la velocidad instantánea para consumir información (o recibir datos transmitidos) para cada una de las estaciones remotas asociada con cada cola. De acuerdo con una modalidad, una señal DRC transmitida desde cualquier estación remota indica que la estación remota tiene la capacidad para recibir datos en cualquiera de múltiples velocidades de datos efectivas. Un ejemplo de un sistema de comunicación que soporta las transmisiones HDR y que está adaptado para programar transmisiones a múltiples usuarios se ilustra en la figura 2. La figura 2 se detalla a continuación, en donde específicamente, una estación base 820 y controlador de estación base 810 se conectan en interfaz con una interfaz de red de paquete 806. El controlador de estación base 810 incluye un programador de canal 812 para ejecutar un algoritmo de programación para transmisiones en el sistema 800. El programador de canal 812 determina la longitud de un intervalo de servicio durante el cual los datos van a ser transmitidos a cualquier estación remota particular con base en la velocidad instantánea asociada de la estación remota para recibir datos (tal como se indica en la señal DRC más recientemente recibida) . El intervalo de servicio puede no ser contiguo en tiempo pero puede ocurrir una vez cada n ranuras. De acuerdo con una modalidad, la primera porción de un paquete es transmitida durante una primera ranura en un primer tiempo y la segunda porción es transmitida 4 ranuras más tarde en un periodo posterior. También, cualesquiera porciones posteriores del paquete se transmiten en múltiples ranuras que tienen un ensanchamiento similar de 4 ranuras, es decir, 4 ranuras de separación entre sí. De acuerdo con una modalidad, la velocidad instantánea para recibir datos Ri determina la longitud de intervalo de servicio Li asociada con una cola de datos particular. Además, el programador de canal 812 selecciona la cola de datos particular para transmisión. La cantidad de datos asociada que se va a transmitir es entonces recuperada de una cola de datos 830 y provista al elemento de canal 826 para transmisión a la estación remota asociada con la cola de datos 830. Como se analiza a continuación, el programador de canal 812 selecciona la cola para proveer los datos, los cuales son transmitidos en un siguiente intervalo de servicio utilizando información que incluye el peso asociado con cada una de las colas. El peso asociado con la cola transmitida es entonces actualizado. El controlador de estación base 810 se conecta en interfaz con la interfaz de red en paquete 806, la Red de Telefonía Pública Conmutada (PSTN) , 808, y las estaciones base en el sistema de comunicación (en la figura 3 solo se muestra una estación base 820 por simplicidad) . El controlador de estación base 810 coordina la comunicación entre las estaciones remotas en el sistema de comunicación y otros usuarios conectados a la interfaz de red de paquete 806 y la PSTN 808. La PSTN 808 se conecta en interfaz con usuarios a través de una red telefónica estándar (que no se muestra en la figura 3) . El controlador de estación base 810 contiene muchos elementos de selector 816, aunque solo se muestra uno en la figura 2 por simplicidad. Cada elemento selector 816 es asignado para controlar la comunicación entre una o más estaciones base 820 y una estación remota (que no se muestra) . Si el elemento selector 816 no ha sido asignado a una estación remota determinada, el procesador de control de llamadas 818 es informado sobre la necesidad de localizar a la estación remota. El procesador de control de llamadas 818 entonces ordena a la estación base 820 localizar a la estación remota. La fuente de datos 802 contiene una cantidad de datos, la cual va a ser transmitida a una estación remota determinada. La fuente de datos 802 provee los datos a una interfaz de red de paquete 806. La interfaz de red de paquete 806 recibe los datos y enruta los datos al elemento selector 816. El elemento selector 816 entonces transmite los datos a cada estación base 820 en comunicación con la estación remota objetivo. En la modalidad ejemplar, cada estación base 820 mantiene una cola de datos 830, la cual almacena los datos que van a ser transmitidos a la estación remota. Los datos son transmitidos en paquetes de datos desde la cola de datos 830 al elemento de canal 826. En la modalidad ejemplar, en el enlace de avance, un "paquete de datos" se refiere a una cantidad de datos la cual tiene un máximo de 1024 bits y una cantidad de datos que va a ser transmitida a una estación remota destino dentro de una "ranura de tiempo" predeterminada (tal como ~ 1.667 msegundos) . Para cada paquete de datos, el elemento de canal 826 inserta los campos de control necesarios. En la modalidad ejemplar, el elemento de canal 826 ejecuta una codificación de Chequeo de Redundancia Cíclica, CRC, del paquete de datos y campos de control e inserta un conjunto de bits de cola de código. El paquete de datos, los campos de control, los bits de paridad CRC, y los bits de cola de código comprenden un paquete formateado. En la modalidad ejemplar, el elemento de canal 826 entonces codifica el paquete formateado e intercala (o reordena) los símbolos dentro del paquete codificado. En la modalidad ejemplar, el paquete intercalado es cubierto con un código Walsh, y propagado con los códigos PNQ y PNI cortos. Los datos propagados son provistos a una unidad RF 828, la cual modula en cuadratura, filtra y amplifica la señal. La señal de enlace de avance es transmitida en el aire a través de una antena al enlace de avance. En la estación remota, la señal de enlace de avance es recibida por una antena y enrutada a un receptor. El receptor filtra, amplifica, desmodula en cuadratura, y cuantifíca la señal. La señal digitalizada es provista a un desmodulador (DEMOD) en donde es aglutinada con los códigos PNQ y PNI cortos y descubierta con la cubierta Walsh. Los datos desmodulados son provistos a un decodificador el cual ejecuta lo contrario a lo que realizan las funciones de procesamiento de señal en la estación base 820, específicamente, las funciones de des-intercalación, decodificación y chequeo CRC. Los datos decodificados son provistos a un depósito de datos. El hardware, tal como se indicó anteriormente, soporta transmisiones de velocidad variable de datos, envío de mensajes, voz, video y otras comunicaciones en el enlace de avance. La velocidad de los datos transmitidos desde la cola de datos 830 varía para permitir cambios en la intensidad de señal y el ambiente de ruido en la estación remota. Cada una de las estaciones remotas de preferencia transmite una señal de Control de Velocidad de Datos, DRC, a una estación base asociada 820 en cada ranura de tiempo. La señal DRC provee información a la estación base 820, la cual incluye la identidad de la estación remota y la velocidad a la cual la estación remota va a recibir datos provenientes de su cola de datos asociada. Por consiguiente, circuitería en la estación remota mide la intensidad de señal y estima el ambiente de ruido en la estación remota para determinar la información de velocidad que va a ser transmitida en la señal DRC. La señal DRC transmitida por cada estación remota se desplaza a través de un canal de enlace inverso y es recibida en la estación base 820 a través de una antena recibida acoplada a la unidad RF 828. En la modalidad ejemplar, la información DRC es desmodulada en el elemento de canal 826 y provista a un programador de canal 812 ubicado en el controlador de estación base 810 o a un programador de canal 832 ubicado en la estación base 820. En una primera modalidad ejemplar, el programador de canal 832 está ubicado en la estación base 820. En una modalidad alterna, el programador de canal 812 está ubicado en el controlador de estación base 810, y se conecta a elementos selectores 816 dentro del controlador de estación base 810. La programación de transmisión en un sistema de circuito conmutado puede involucrar un algoritmo proporcional justo, en donde una función de prioridad queda definida para cada usuario. A continuación se muestra un ejemplo de un algoritmo proporcional justo. La función de prioridad puede tomar en consideración la velocidad de datos solicitada para un usuario determinado, típicamente una función de calidad de canal de enlace de avance para el usuario, y el rendimiento para el usuario. La capacidad es entonces equilibrada brindando servicio primero a aquellos usuarios que tienen altas velocidades de datos solicitados en comparación con el rendimiento. La programación de transmisión en un sistema de paquete conmutado, de acuerdo con una modalidad, equilibra la capacidad con el retraso de usuario. Los flujos de la aplicación se transmiten como datagramas, los cuales son menajes auto-contenidos independientes enviados en una red. Generalmente no se garantiza la llegada del datagrama, el tiempo de llegada y el contenido. Los datagramas asociados con un mismo flujo de aplicación pueden ser transmitidos por diferentes rutas a un mismo usuario. Los datagramas se vuelven a ensamblar en el receptor. El retraso de extremo-a-extremo en un sistema de paquete conmutado no es fijo, y por lo tanto, el programador puede utilizar esta diferencia en retraso y ajustar el retraso para que los diversos usuarios aumenten su capacidad. Por ejemplo, el programador puede reducir el retraso experimentado por los usuarios que solicitan datos que tienen límites de bajo retraso y/o límites de variación de retraso. Dichas aplicaciones incluyen, pero no se limitan a VolP, video, etc. Las transmisiones pueden tener requerimientos específicos de Grado de Servicio (GoS) o QoS. Una comunicación tipo VolP, por ejemplo, requiere que los paquetes lleguen con una latencia definida, o dentro de un periodo de retraso permisible. Por lo tanto, puede ser deseable prioritizar esas comunicaciones o aplicaciones que tienen un requerimiento de latencia inferior u otras especificaciones GoS. Las transferencias de conferencias de multimedia, corrientes de video, exploración por la web, de Protocolo de Transferencia de Archivo tiene, cada una, requerimientos GoS específicos. Para ejecutar un esquema de clasificación de prioridad, a cada flujo se le asigna una función de prioridad. En una modalidad, una Función de Prioridad (PF) para un programador de paquete conmutado puede entonces ser proporcionada como: PF=f (retraso) En donde f ( ) es una función, y la PF se determina entonces con base en el requerimiento de retraso de un usuario determinado o una aplicación determinada para un usuario. La PF se calcula para cada datagrama en cada cola; las diversas PF se comparan para identificar los casos de flujo de prioridad superiores . Las comunicaciones de paquete conmutado permiten la programación para incorporar gestión de retraso adaptivo, ya que el retraso de extremo-a-extremo de una comunicación determinada no es fijo. Esto está en contraste con una conmutación de circuito conmutado, en donde el retraso de extremo-a-extremo es fijo. Se puede apreciar que el siguiente análisis considera un sistema cdma2000 que soporta servicios de Datos de Paquete de Alta Velocidad (HRPD) como se describe en IS-856. Este sistema se utiliza como un ejemplo. La presente invención se puede aplicar a otros sistemas en donde los usuarios son seleccionados para servicio de acuerdo a un algoritmo de programación. En un sistema HRPD, la interfaz de aire puede soportar hasta cuatro corrientes de aplicación paralela. La primera corriente porta información de señalización, y las otras tres se pueden utilizar para portar aplicaciones con diferentes requerimientos QoS u otras aplicaciones. El siguiente glosario se provee para entender con claridad una modalidad que se muestra a continuación. El siguiente glosario no pretende ser exhaustivo. El siguiente glosario no pretende limitar la presente invención al mismo, sino más bien se provee para claridad y entendimiento con respecto a una modalidad de un sistema de comunicación que soporta un algoritmo de programación ponderado adaptivo.

Glosario Red de Acceso (AN) - el equipo de red que provee conectividad de datos entre una red celular y una red de datos de paquete conmutado (típicamente la Internet) y las AT. Una AN en un sistema HRPD es equivalente a una estación base en un sistema de comunicación celular. Terminal de Acceso (AT) - un dispositivo que provee conectividad de datos a un usuario. Una AT en un sistema HRPD corresponde a una estación móvil en un sistema de comunicación celular. Una AT se puede comunicar con un dispositivo de cómputo tal como una computadora personal portátil o puede ser un dispositivo de datos auto-contenidos tal como un Asistente Digital Personal (PDA) . Flujo de Aplicación - la trayectoria de transmisión designada desde la fuente a la AT para una corriente de aplicación determinada. Cada flujo de aplicación es identificado por una fuente, destino, perfil de tráfico y calidad del perfil de servicio. Corriente de Aplicación - una comunicación de datos que corresponde a una aplicación. La mayoría de las corrientes de aplicaciones tienen requerimientos designados de calidad de servicio. Solicitud de Repetición Automática (ARQ) - un mecanismo por medio del cual el transmisor inicia una retransmisión de datos con base en la ocurrencia o no ocurrencia de un evento. Velocidad de Datos Promedio - la velocidad de datos de entrada promedio en tiempo para un flujo de aplicación determinado. Ráfaga (s) - medición de la ráfaga o densidad y relación en tiempo de los paquetes en un flujo de aplicación. Mejor Esfuerzo (BE) - flujos de aplicación que, en general, tienen un volumen relativamente grande de datos para recibir en el aire, pero la naturaleza del tráfico es tal que, se pueden tolerar retrasos relativamente grandes, pero la velocidad de pérdida de datos deberá ser extremadamente pequeña. Control de Velocidad de Datos (DRC) - un mecanismo por medio del cual una AT transmite una velocidad de datos solicitada a la AN. Bits de Déficit (def its) - número de bits correspondientes a los paquetes de déficit. Límite de Retraso - tiempo especificado (límite de retraso) permitido para la transmisión de un paquete de datos desde la AN a la AT. Reenvío Acelerado (EF) - los flujos de solicitud típicamente tienen pequeñas cantidades de tráfico que llegan desde la Internet a la Red de Acceso; sin embargo, la naturaleza del tráfico es tal que los paquetes de datos deberían ser entregados al usuario dentro de un Límite de Retraso relativamente pequeño, con velocidad de pérdida de datos razonable. Enlace de Avance (FL) - enlace aéreo de transmisión desde la AN a la AT. Paquete de Encabezado (HOL) - primer paquete en una cola. Datos de Paquete de Alta Velocidad (HRPD) - un servicio de datos que transmite comunicaciones de datos en paquete a una velocidad de datos alta. También denominada Velocidad de Datos Alta (HDR) , y especificada en la norma IS-856 titulada "Norma de Interfaz Aérea de Datos en Paquete de Alta Velocidad cdma2000". Inestabilidad - variación en tiempo entre los paquetes sucesivos recibidos. Límite de Inestabilidad - límite en la inestabilidad para un flujo de aplicación determinado. Grupo de Expertos de Imágenes en Movimiento (MPEG) - protocolo para transmisión de materiales de multimedia.

Algoritmo Proporcional Justo (PF) - un algoritmo de programación en donde las comunicaciones de datos son programadas de acuerdo con un factor de selección calculado para cada AT como una relación de una velocidad de datos solicitada a rendimiento. Calidad de Servicio (QoS) - requerimientos relacionados con la transmisión de una comunicación de datos en paquete, incluyendo pero no limitado a, retraso, velocidad requerida e inestabilidad. Enlace Inverso (RL) - enlace aéreo de transmisión desde AT a AN. Cola de Transmisión - Cola de transmisión que almacena los flujos de aplicación para una BTS determinada. Muchas comunicaciones inalámbricas pueden sacar ventaja del Protocolo de Internet (IP) para aprovechar el Comportamiento Por Salto (PHB) diferente y diferentes enrutamientos para procesamiento de datos en paquete. Por lo general, la Internet está formada por una multitud de redes construidas a partir de varias tecnologías de capa de enlace las cuales se basan en IP para ínter-operar. IP ofrece un servicio de capa de red sin conexión el cual está sujeto a pérdida de paquete y retraso que aumenta con la carga de la red. El modelo de entrega IP básico se denomina como Mejor-Esfuerzo (BE) . Sin embargo, algunas aplicaciones pueden requerir un mejor servicio que el simple servicio BE. Por ejemplo, aplicaciones de multimedia pueden especificar un ancho de banda fijo, un retraso bajo y poca inestabilidad. Otro tipo de prioridad es un comportamiento de reenvío denominado como Reenvío Asegurado (AF) el cual garantiza un nivel de rendimiento. Existen varios aspectos en la gestión de QoS. Algunas consideraciones de gestión de QoS son la asignación de ancho de banda, y ancho de banda garantizado en medios compartidos también conocidos como redes de difusión, por ejemplo, una red de Ethernet o una Red de Área Local inalámbrica (LAN) . Aunque existe una demanda creciente para incluir capacidades inalámbricas en computadoras portátiles y otros dispositivos de cómputo. Sin embargo, las redes inalámbricas están limitadas en su ancho de banda y, por lo tanto, la conservación y optimización de capacidad se convierte en una consideración de suma importancia. La figura 3 ilustra un método de programación el cual prioritiza las transmisiones con base en requerimientos de Grado de Servicio (GoS) o QoS. En la AN, los datos para transmisión son almacenados en una unidad de almacenamiento de memoria adaptada para almacenar las colas de datos correspondientes a flujos de aplicación entrantes. Una cola es almacenada para cada caso de un flujo de aplicación. De acuerdo con la presente invención, un flujo de aplicación se divide en casos, en donde cada caso es un octeto de datos. Por lo tanto, un flujo de aplicación puede tener, y con frecuencia tendrá, múltiples colas asociadas con el mismo. Cada cola entonces tiene un tipo de prioridad QoS y/o GoS asociado definido por los requerimientos de transmisión y recepción. Por ejemplo, el tipo de prioridad se puede basar en un requerimiento de retraso de extremo-a-extremo o en algunos otros criterios de calidad. Se puede apreciar que, una transmisión determinada puede caer en uno de múltiples tipos de prioridad GoS. Por ejemplo, algunos servicios permiten que los paquetes de datos sean transmitidos individualmente y después reunidos en el receptor en un momento posterior sin pérdida de continuidad, es decir, tipo de prioridad BE. En contraste, las aplicaciones designadas para proporcionarle al usuario una experiencia en tiempo real, tal como VolP, tienen un tipo de prioridad superior y se denomina como tipo de prioridad de Reenvío Acelerado (EF) . El tipo de prioridad EF incluye aplicaciones que tienen límites en el límite de retraso y variación de retraso. En el presente ejemplo, el programador prioritiza las comunicaciones EF. El tipo de prioridad QoS o GoS también se puede denominar como una clase QoS. Además, cada cola tiene una sensibilidad asociada con la misma. Por ejemplo, un flujo de aplicación EF típicamente es sensible al retraso, lo que significa que la transmisión del flujo de aplicación EF tiene requerimientos de retraso los cuales se van a cumplir. En muchos casos, si los requerimientos de retraso no se cumplen, los datos se descartan y no se transmiten. En contraste, un flujo de aplicación BE típicamente es sensible al rendimiento, lo que significa que la transmisión del flujo de aplicación BE tiene requerimientos de rendimiento objetivo, pero no necesariamente tiene los requerimientos de retraso estrictos de un flujo de aplicación EF. La figura 3 ilustra un método de programación 200 que ejecuta gestión de retraso adaptivo de acuerdo con una modalidad. Dentro de una AN, un programador ejecuta un algoritmo de programación, proveyendo transmisiones de datos en paquete de alta velocidad a múltiples usuarios. El programador revisa la cola de datos para determinar el tipo GoS para datos. Si cualquiera de los datos es de un tipo de prioridad GoS determinado, es decir, tipo de prioridad que define requerimientos más específicos que BE, en el diamante de decisión 202, el proceso continúa con el paso 204 para encontrar los datos más antiguos de un tipo de prioridad superior en la cola. Como se utiliza en la presente invención, un tipo de prioridad superior se refiere a un tipo de prioridad GoS definido por una especificación más estricta. Por ejemplo, un tipo de prioridad puede especificar un límite de retraso, mientras que otro puede especificar un límite de inestabilidad. En este caso, el tipo de prioridad que especifica el límite de retraso se considera una prioridad superior y, por lo tanto, se considera primero. De acuerdo con la presente modalidad, el programador primero ordena los bits en paquetes para transmisión basada en requerimientos de retraso. Una vez que los datos de alta prioridad son programados, se puede aplicar otro algoritmo para programar los paquetes restantes. Por ejemplo, cuando los datos EF están en la cola, el programador comienza a formar paquetes para transmisión utilizando los datos EF. Los datos EF se seleccionan con base en la antigüedad de los datos en la cola, paso 204. En una modalidad, conforme los datos son ingresados en la cola, en ese momento °los datos reciben un sello con fecha y hora. El programador encuentra los datos EF que tienen el sello con fecha y hora más temprana y los coloca en un primer paquete. El programador continúa entonces colocando los datos EF en paquetes de acuerdo con la antigüedad en la cola, paso 206. Una vez que todos los datos EF han sido colocados en paquetes para transmisión, el programador entonces aplica otro algoritmo para el resto de los datos. En la presente modalidad, el programador aplica un algoritmo proporcional justo al resto de los datos, los cuales pueden ser datos de Mejor Esfuerzo (BE) , paso 208. Los datos BE son entonces ingresados en paquetes de acuerdo con el algoritmo proporcional justo, paso 210. Se puede apreciar que, conforme aumenta la condición del canal, los usuarios solicitan datos a velocidades más altas, lo cual tiene el efecto de reducir el límite de retraso. Por lo tanto, incluso cuando el programador prioritiza los datos EF, el límite de retraso puede ser una función de la condición de canal. Para la transmisión de datos BE, el programador selecciona el paquete para elevar al máximo el rendimiento.

El rendimiento generalmente se calcula como: Rendimiento = (bits por paquete) / (ranuras por paquete) . De acuerdo con una modalidad, PF se puede proporcionar como: PF = f (antigüedad de paquete) *g (condición de canal) *h (carga de célula), que considera la antigüedad del paquete así como la condición del canal y la carga de la célula en la programación de transmisiones. Dicho cálculo se puede utilizar para programa datos EF o datos BE. Refiriéndose nuevamente a la figura 2, en una modalidad, el programador de canal 832 recibe información desde una cola de datos 830 que indica la cantidad de datos en cola para cada estación remota, también denominada tamaño de cola. El programador de canal 832 entonces realiza la programación con base en la información DRC y el tamaño de cola para cada estación remota que recibe servicio por parte de la estación base 820. Si se requiere el tamaño de cola para un algoritmo de programación utilizado en la modalidad alterna, el programador de canal 812 puede recibir información del tamaño de cola desde el elemento selector 816. Durante la transmisión de un paquete a uno o más usuarios, los usuarios transmiten una señal de reconocimiento "ACK" después de cada ranura de tiempo que contiene una porción del paquete transmitido. La señal ACK transmitida por cada usuario se desplaza a través de un canal de enlace inverso y es recibida en la estación base 820 a través de una antena de recepción acoplada a la unidad RF 828. En la modalidad ejemplar, la información ACK es desmodulada en el elemento de canal 826 y provista a un programador de canal 812 ubicado en el controlador de estación base 810 o a un programador de canal 832 ubicado en la estación base 820. En una primera modalidad ejemplar, el programador de canal 832 está ubicado en la estación base 820. En una modalidad alterna, el programador de canal 812 está ubicado en el controlador de estación base 810, y se conecta a los elementos selectores 816 dentro del controlador de estación base 810. Las modalidades de la presente invención se pueden aplicar a otras arquitecturas de hardware, las cuales pueden soportar transmisiones de velocidad variable. La presente invención se puede extender fácilmente para cubrir transmisiones de velocidad variable en el enlace inverso. Por ejemplo, en lugar de determinar la velocidad de la recepción de datos en la estación base 820 con base en una señal DRC proveniente de las estaciones remotas, la estación base 820 mide la intensidad de la señal recibida proveniente de las estaciones remotas y calcula el ambiente de ruido para determinar una velocidad de recepción de datos provenientes de la estación remota. La estación base 820 entonces transmite a cada estación remota asociada la velocidad a la que los datos van a ser transmitidos en el enlace inverso desde la estación remota. La estación base 820 puede entonces programar transmisiones en el enlace inverso con base en las diferentes velocidades de datos en el enlace inverso en una forma similar a aquella descrita aquí para el enlace de avance. También, una estación base 820 de la modalidad analizada anteriormente, transmite a una estación seleccionada, o estaciones seleccionadas, de las estaciones remotas excluyendo las estaciones remotas restantes asociadas con la estación base 820 utilizando un esquema de Acceso Múltiple por División de Código, CDMA. En cualquier momento particular, la estación base 820 transmite a la estación seleccionada, o estaciones seleccionadas, de las estaciones remotas utilizando un código, el cual es asignado a las estaciones base de recepción 820. Sin embargo, la presente invención también se puede aplicar a otros sistemas que emplean diferentes métodos de Acceso Múltiple por División de Tiempo, TDMA para proveer datos a estaciones base seleccionadas 820, excluyendo otras estaciones base 820, para asignar recursos de transmisión de manera óptima. El programador de canal 812 programa las transmisiones de velocidad variable en el enlace de avance. El programador de canal 812 recibe el tamaño de cola, el cual es indicativo de la cantidad de datos a transmitir a una estación remota, y mensajes desde las estaciones remotas. El programador de canal 812 de preferencia programa transmisiones de datos para lograr el objetivo del sistema de máximo rendimiento de datos mientras se ajusta a una restricción justa. Como se muestra en la figura ÍA, las estaciones remotas están dispersadas a través del sistema de comunicación y pueden estar en comunicación con cero o una estación base en el enlace de avance. En la modalidad ejemplar, el programador de canal 812 coordina las transmisiones de datos del enlace de avance en todo el sistema de comunicación. De acuerdo con una modalidad, el programador de canal 812 de la figura 2 se ejecuta en un sistema de cómputo, el cual incluye un procesador, Memoria de Acceso Aleatorio, RAM, y una memoria de programa para almacenar instrucciones que van a ser ejecutadas por el procesador (que no se muestra) . El procesador, RAM y memoria de programa se pueden dedicar para las funciones del programador de canal 812. En otras modalidades, el procesador, RAM y memoria de programa pueden ser parte de un recurso de cómputo compartido para realizar funciones adicionales en el controlador de estación base 810. En la modalidad ejemplar, un programador generalizado se aplica al sistema 800 que se ilustra en la figura 2 y se detalla a continuación. Esos módulos dentro del BSC 810 y BS 820 que se utilizan para ejecutar una función de prioridad para programar las transmisiones de datos se analizan después de establecer los puntos específicos del programador generalizado. Debido a la creciente demanda de aplicaciones de datos inalámbricas, la demanda de sistemas de datos de comunicación inalámbrica muy eficientes ha aumentado significativamente. El estándar IS-95 tiene la capacidad de transmitir datos de tráfico y datos de voz en los enlaces de avance e inverso. De acuerdo con la norma IS-95, los datos de tráfico o datos de voz son divididos en tramas de canal de código que tienen 20 milisegundos de ancho con velocidades de datos tan elevadas como 14.4 Kbps. En un sistema IS-95, a cada estación de suscriptor se le asigna por lo menos uno de un número limitado de canales de enlace de avance ortogonales. Aunque la comunicación entre una estación base y una estación de suscriptor está en curso, el canal de enlace de avance permanece asignado a la estación de suscriptor. Cuando servicios de datos son provistos en un sistema IS-95, un canal de enlace de avance permanece asignado a una estación de suscriptor incluso durante tiempos en que no existen datos de enlace de avance para ser enviados a la estación de suscriptor. Una diferencia importante entre servicios de voz y servicios de datos es el hecho de que el primero impone requerimientos de retraso estrictos y fijos. Típicamente, el retraso de una vía general para tramas de diálogo es especificado para que sea menor de 100 milisegundos. En contraste, el retraso de datos se puede convertir en parámetro variable utilizado para optimizar la eficiencia del sistema de comunicación de datos. Otra diferencia importante entre los servicios de voz y los servicios de datos es que el primero requiere un grado de servicio (GoS) fijo y común para todos los usuarios. Típicamente, para sistemas digitales que proveen servicios de voz, esto se traduce en una velocidad de transmisión fija e igual para todos los usuarios y un valor tolerable máximo para las velocidades de error de las tramas de diálogo. En contraste, para servicios de datos, el GOS puede ser diferente de usuario a usuario y puede ser un parámetro optimizado para aumentar la eficiencia general del sistema de comunicación de datos. El GOS de un sistema de comunicación de datos típicamente se define como el retraso total incurrido en la transferencia de una cantidad de datos predeterminada, en lo sucesivo denominada como un paquete de datos . Otra diferencia importante todavía entre los servicios de voz y los servicios de datos es que los primeros requieren un enlace de comunicación confiable el cual, en el sistema de comunicación CDMA ejemplar, es provisto por transferencia suave. La transferencia suave produce como resultado transmisiones redundantes desde dos o más estaciones base para mejorar la confiabilidad. Sin embargo, esta confiabilidad adicional no se requiere para transmisión de datos debido a que los paquetes de datos recibidos en error pueden ser retransmitidos. Para servicios de datos, la energía de transmisión utilizada para soportar transferencias suaves puede ser utilizada de manera más eficiente para transmitir datos adicionales.

El retraso de transmisión que se requiere para transferir un paquete de datos y la velocidad de rendimiento promedio son dos atributos utilizados para definir la calidad y efectividad de un sistema de comunicación de datos. El retraso de transmisión no tiene el mismo impacto en la comunicación de datos que para la comunicación de voz, pero es una métrica para medir la calidad del sistema de comunicación de datos. La velocidad de rendimiento promedio es una medida de la eficiencia de la capacidad de transmisión de datos del sistema de comunicación. Existe la necesidad en la técnica de sistemas de comunicación que provean rendimiento de datos mejorado al mismo tiempo que se provee un GOS que es apropiado para los tipos de servicio que se están proveyendo en un canal inalámbrico. La necesidad de un programador generalizado se basa en los requerimientos y objetivos de transmisión de datos en un sistema inalámbrico. Para transmisiones de datos, el rendimiento se define en términos de los retrasos incurridos en la transmisión de paquetes de datos en lugar de definirse en términos de bits o bytes individuales. Un paquete de datos, tal como un Protocolo de Internet, IP, datagrama, es una unidad indivisible ya que, en la mayoría de los casos, la recepción únicamente de una porción de un paquete no contiene suficiente información para que el usuario decodifique y utilice todo el paquete, es decir, el paquete es inútil para el usuario final. El usuario final recibe el paquete de datos, realiza un Chequeo de Redundancia Cíclica, CRC, en el paquete de datos, y procesa los datos. Por lo tanto, el usuario está más preocupado por el tiempo de llegada del último bit de un paquete y no está tan preocupado por el retraso de bits individuales en el paquete de datos. Esto permite flexibilidad considerable en las asignaciones de velocidad para diferentes usuarios en escalas de tiempo más pequeñas que el tiempo de transmisión de un paquete de datos. Además, en la conexión de tipo Protocolo de Control de Transmisión, TCP, cierta variación de retrasos de paquetes es aceptable siempre y cuando la variación no sea tan impredecible que ocasione retransmisiones TCP innecesarias. Otra característica del canal inalámbrico es la variabilidad del canal mismo. En un sistema tipo HDR, esta variabilidad resulta en variaciones de la velocidad solicitada en un periodo de tiempo. Para elevar al máximo el uso del canal, el programador es diseñado para servir a usuarios de alta velocidad, es decir, usuarios que solicitan las velocidades de datos más altas. Esto significa que, ocasionalmente, los usuarios pueden no recibir servicio durante periodos de tiempo en que sus velocidades solicitadas son inferiores. El rendimiento general se 'elevará al máximo cuando el programador no proporcione servicio a usuarios de baja velocidad durante periodos de tiempo prolongados. Sin embargo, de manera ideal, el programador equilibra esto contra el deseo de retrasos de paquete y variaciones de retraso que serán relativamente consistentes como se explicó anteriormente. Otro aspecto considera la imparcialidad para los múltiples usuarios en un sistema. Para lograr un método de programación justo, el programador, de manera ideal, distribuye el rendimiento general entre diferentes usuarios. Diferentes bases de imparcialidad (o injustita permisible) son utilizadas por diferentes sistemas para afectar las necesidades y deseos de los sistemas individuales. El concepto de imparcialidad es un concepto clave en muchos algoritmos de programación. La imparcialidad provee diferentes cantidades de flexibilidad al momento de proporcionar servicio a diferentes usuarios y, por lo tanto, tiene un impacto en el rendimiento general de un sector. De acuerdo con una modalidad, un método y aparato para programar transmisiones en un sistema de comunicación con aplicación a múltiples clases de usuarios, incorpora un programador generalizado. El programador generalizado acomoda una variedad de diferentes prioridades de programación. Diferentes clases de usuarios, cada uno con requerimientos de transmisión específicos, reciben servicio por parte de un programador generalizado, el cual mantiene un alto rendimiento sobre todos los usuarios. En una modalidad, la operación de un programador generalizado ejecuta una función de prioridad de una métrica de condición de canal y un criterio de imparcialidad, en donde la función de prioridad se define como: en donde Ai(t) se refiere como la métrica de condición de canal y C7¿(t) se refiere como la métrica de imparcialidad de usuario. La función A¿(t) especifica el deseo de dar servicio al usuario i en el tiempo t con base en una condición de canal actual. La función U± (t ) especifica el deseo de dar servicio a un usuario i en el tiempo t con base en el historial pasado del servicio recibido. La función de prioridad f ( ) combina las dos métricas deseables, A¿(t) y ¡i(t) para determinar un nivel de prioridad para cada usuario. De acuerdo con una modalidad, un programador generalizado provee servicio al usuario con la función de prioridad más elevada /(vi,(/),£/_()), dentro de una clase o tipo determinado de usuarios. En la modalidad ejemplar, el valor tomado por la función de prioridad aumenta conforme aumenta la función de condición de canal Ai(t) y disminuye conforme se reduce la función de imparcialidad U± (t ) . Por consiguiente, se determinan las funciones Ai(t) y O± (t ) . Además, la función de prioridad f ( ) es una función por lo menos de un periodo de tiempo en el que se mide la métrica de condición de canal y la métrica de imparcialidad de usuario. En una modalidad alterna, la función de prioridad f ( ) puede ser una función dependiente del tiempo por usuario. Sin embargo, por simplicidad, un programador puede utilizar una función de combinador común para todos los usuarios y modificar la métrica de imparcialidad del usuario para reflejar los requerimientos del usuario. Una clase genérica de programadores de múltiples usuarios, clasifica a los usuarios que reciben servicio desde una AN por lo menos en dos categorías de amplias, BE y EF. También se pueden ejecutar otras categorías de transmisiones, tal como AF, etc. BE y EF son como aquí se define. Específicamente, las aplicaciones de Mejor Esfuerzo (BE) en general tienen un volumen relativamente grande de datos para recibir en el aire, pero la naturaleza del tráfico es tal que, se pueden tolerar retrasos relativamente grandes, pero la velocidad de pérdida de datos debería ser extremadamente pequeña; los flujos de aplicación de Reenvío Acelerado (EF) típicamente tienen pequeñas cantidades de tráfico que llegan desde la Internet a la Red de Acceso; sin embargo, la naturaleza del tráfico es tal que, los paquetes de datos deberían ser entregados al usuario dentro de un Límite de Retraso relativamente pequeño, con velocidad de pérdida de datos razonable. En un sistema de datos en paquete, tal como lxEV-DO, el programador tiene la flexibilidad para permitir un desempeño de retraso variable para que usuarios individuales eleven al máximo la capacidad. Aquí, la capacidad se refiere al rendimiento para usuarios BE y al número de usuarios servidos con desempeño aceptable en el caso de tráfico sensible al retraso tal como VolP (usuarios EF) . En IxEV-DO generalmente, el aumento del Límite de Retraso de un usuario, mejora la utilización del FL, aumentando así la capacidad BE y EF del sistema. Este aumento de capacidad sigue de varios factores que incluye, pero no se limitan a, eficiencia de empaque superior y la habilidad para sacar ventaja de las condiciones del canal local y ganancia de diversidad de múltiples usuarios. En el caso de tráfico BE únicamente, un programador típico es el programador Justo Proporcional (PF) . El programador es proporcionalmente justo en el sentido de que el rendimiento provisto a usuarios individuales sería aproximadamente proporcional a la geometría del usuario, es decir, condición de canal promedio. El programador justo proporcional ha sido el programador de elección para tráfico BE únicamente debido a los beneficios de rendimiento para las compensaciones de imparcialidad. Además, el algoritmo PF está diseñado para sacar provecho de los picos de canal local mientras se provee ganancia de diversidad de múltiples usuarios. Como se utiliza en la presente invención, dicho programador PF se denominará como el "programador de rendimiento proporcionalmente justo". Se puede apreciar que, en el caso de tráfico BE únicamente, existe otra clase de programadores : El programador "igual grado de servicio". Este programador ayuda a proveer igual rendimiento a todos los usuarios. Por este motivo, la capacidad del sistema es determinada por los usuarios más débiles. Aunque el programador de igual grado de servicio podría ser deseable en algunas aplicaciones, dichos programadores típicamente no utilizan el enlace aéreo de manera eficiente. Estos programadores se denominan aquí como "programadores de igual rendimiento". Los programadores de rendimiento PF y los programadores de igual rendimiento descritos anteriormente son útiles en el contexto de tráfico BE únicamente. Para tráfico EF sensible al retraso, estos programadores pueden no ser suficientes ya que carecen de un mecanismo para el control de retraso. Lo siguiente presenta medios y métodos de programación sensibles al retraso, los cuales operan en paralelo con los dos enfoques par tráfico BE únicamente, es decir, programadores de rendimiento PF e igual rendimiento. En el caso de tráfico sensible al retraso, la imparcialidad "proporcional" contra la imparcialidad "igual" aplica no solo al rendimiento provisto a usuarios individuales, sino al rendimiento de "retraso" provisto a usuarios individuales. El rendimiento de retraso puede ser cuantificado en términos de retraso promedio o peso de cola de retraso, etc. Se puede apreciar que modalidades alternas pueden incorporar la programación BE y EF en un método común, mientras se cumple con los requerimientos de rendimiento y sensibilidad al retraso, respectivamente. En una modalidad, un rendimiento de retraso aproximadamente igual puede ser provisto a cada usuario. Este enfoque es similar al rendimiento igual y para la simetría de terminología, se denomina como el "programador de igual retraso". Un programador de igual rendimiento intenta proveer un rendimiento igual a todos los usuarios, por lo tanto, la capacidad del sistema puede ser determinada por los usuarios que tienen la cobertura más débil. Un programador de igual retraso intenta proveer un desempeño de igual retraso, tal como retraso medio igual o peso de cola de retraso igual, a todos los usuarios y por lo tanto, la capacidad del sistema es determinada de manera similar por los usuarios que tienen la cobertura más débil. En otra modalidad, el desempeño de retraso provisto a un usuario es proporcional a la geometría promedio del usuario. Este enfoque es similar al programador de rendimiento proporcionalmente justo y se denomina como el "programador de retraso proporcionalmente justo". El programador de rendimiento justo proporcional trata de proveer un rendimiento a usuarios individuales proporcional a su geometría promedio, mejorando así significativamente la capacidad del sistema en comparación con un programador de igual rendimiento. De manera similar, un programador de retraso proporcionalmente justo proveería un desempeño de retraso, a cada usuario individual, proporcional a la geometría promedio del usuario, elevando así al máximo la capacidad EF. Las cuatro categorías de la programación de paquete se ilustran en la figura 4. Cada categoría se ilustra con el equilibrio de las consideraciones QoS. Específicamente, el programador de rendimiento PF equilibra el control de rendimiento con la imparcialidad proporcional. El programador de igual rendimiento equilibra el control de rendimiento con igual imparcialidad. El programador de retraso PF equilibra el control de retraso con imparcialidad proporcional. El programador de igual retraso equilibra el control de retraso con igual imparcialidad. Aunque algunos métodos de programación son útiles en sistemas de circuito conmutado, otros aplican más para sistemas de datos en paquete, tal como IxEV-DO. Los medios de programación de retraso proporcionalmente justo y métodos aquí presentados pueden proveer una ventaja de sistemas de paquete conmutado en sistemas de circuito conmutado. Además de mejorar la capacidad del sistema, el programador de retraso PF también puede mejorar la experiencia del usuario. Por ejemplo, los usuarios en proximidad estrecha a las BS tienen más probabilidades de recibir un mejor desempeño de retraso que los usuarios que están lejos de las BS . Esto es en contraste al desempeño de retraso, el cual no depende de la proximidad del usuario a la AN. Además, para usuarios en alta geometría, en proximidad estrecha a una BS, el desempeño puede ser predecible con un alto nivel de confianza; mientras que para un programador de igual retraso, el desempeño puede ser imprevisible dependiendo de la carga actual en el sistema. Por lo tanto, es deseable que un programador provea aumentos de calidad de servicio con aumentos en la geometría de los usuarios individuales.

Un programador que sirve a usuarios tanto BE como EF puede utilizar una combinación apropiada de rendimiento proporcionalmente justo y programación de retraso. Dicho programador se denominará como un "programador de retraso/rendimiento proporcionalmente justo". Se puede apreciar que, en una modalidad, la programación de retraso/rendimiento proporcionalmente justo se basa implícitamente en geometrías relativas de usuarios servidos para un solo sector. Esto se denomina como "imparcialidad intra-sector" . Otro asunto a considerar en el diseño de un programador es la imparcialidad "inter-células", la cual puede ser descrita como el nivel de servicio promedio, el cual puede ser cuantificado en términos de rendimiento provisto a usuarios BE y el retraso promedio provisto a usuarios EF, etc., provistos por diferentes sectores a los usurarios servidos por esos sectores. Para continuar la analogía entre el programador de rendimiento proporcionalmente justo y el programador de retraso proporcionalmente justo, se puede apreciar que el rendimiento provisto a usuarios BE individuales por un sector que utiliza programador de rendimiento proporcionalmente justo disminuye conforme aumenta el número de usuarios servidos por ese sector. Sin embargo, se mantiene la imparcialidad intra-sector. De manera similar, se puede permitir que aumente el desempeño de retraso provisto a usuarios EF individuales provisto por un sector que utiliza programador de retraso proporcionalmente justo conforme aumenta el número de usuarios servidos por el sector. El programador de retraso/rendimiento proporcionalmente justo utiliza una métrica de decisión de la siguiente forma para seleccionar a cuáles usuarios dar servicio en cualquier decisión de programación: Métrica de Decisión = f (Antigüedad de Paquete, Condición de Canal , Carga de Sector) en donde Antigüedad de Paquete se refiere a la diferencia entre el tiempo actual y una fecha y hora apropiada definida por cada paquete que está esperando en la cola de la estación base, la condición del canal se refiere a la calidad del enlace de radio entre la BS y la AT, y la Carga de Sector se refiere al volumen y perfil del tráfico total que está recibiendo servicio por parte del sector en un lapso de tiempo corto alrededor del tiempo actual. La función f ( ) depende de la ejecución particular del programador. También, la Métrica de Decisión se puede referir a una métrica de bits, una métrica de paquete, una métrica de datagrama, o cualquier otro medio para proveer al programador un método de selección de caso de transmisión. La información de la Condición de Canal se puede incorporar en el programador en varias formas. Por ejemplo, el programador de rendimiento proporcionalmente justo utiliza el Control de Velocidad de Datos (DRC) /Rendimiento Promedio, el cual tiende a estar en su punto máximo durante picos de canal local. Otro enfoque podría ser el uso de DRC/AvgDRC (DRC promedio) , pero en aplicación puede favorecer a usuarios con fluctuaciones de canal más grandes. Otra posibilidad podría ser utilizar un lazo de retroalimentación para indicar un percentil de picos de canal. Otro lazo 300 se muestra en la figura 5. Una modalidad, como se ilustra en la figura 5, es un lazo 300 diseñado para determinar la calidad de canal aceptable con respecto a un umbral. La entrada, IDRC, es una función o índice del valor DRC, por ejemplo, una función en aumento de la velocidad de datos asociada con el DRC, en donde IDRC aumenta conforme aumenta la velocidad de datos solicitada. El IDRC es provisto para comparar la unidad 302 con un filtro de Respuesta de Impulso Infinito (IIR) 306. En un ejemplo, la constante de tiempo se fija en ls, sin embargo, se pueden ejecutar constantes de tiempo alternas. La salida filtrada del filtro IIR 306 se provee a una unidad sumadora 312, la cual provee el valor de umbral a la unidad de comparación 302. La unidad de comparación 302 compara el IDRC con el umbral. El resultado de la comparación indica si la calidad del canal actual es aceptable o no. El sistema determina un porcentaje de tiempo objetivo cuando la calidad de canal debería ser aceptable. En el presente ejemplo, el objetivo se fija al 30%. El objetivo es variable y se puede ajustar durante la operación. Sistemas alternos pueden ejecutar otros valores o esquemas objetivo. La salida de la unidad de comparación 302 es binaria {1,0}, en donde un 1 indica calidad de canal aceptable y un 0 inaceptable, es decir, por debajo de un umbral . Continuando con la figura 5, la salida de la unidad de comparación 302 se provee a un filtro IIR 304, en donde en el presente ejemplo, la constante de tiempo se establece en 0.5 s. Se podrían ejecutar constantes de tiempo alternas. A partir del filtro IIR 304, la salida filtrada es provista a una unidad de comparación 310 para comparación con un valor de entrada, en el presente ejemplo el valor de entrada es 0.3. Si el resultado de comparación es por arriba del valor de entrada, se provee una señal para que el acumulador ascendente/descendente 308 aumente el umbral para determinar la calidad de canal. Esto indica que el indicador de calidad de canal de la unidad de comparación 302 es 1 más que 30%. Además, si la comparación es por debajo del valor de entrada, entonces la señal provista al acumulador ascendente/descendente 308 ordena aumentar el umbral . La salida del acumulador ascendente/descendente 308 es provista a la unidad sumadora 312. La unidad sumadora 312 suma las salidas del acumulador ascendente/descendente 308 y el filtro IIR 306, en donde la entrada del filtro IIR 306 provee una desviación general para el umbral a la unidad de comparación 302. El resultado de la suma se provee a la unidad de comparación 302. El indicador de estimado de canal se toma de la salida de la unidad de comparación 302. De esta forma, el programador mantiene el indicador de estimado de canal o la Información de Condición de Canal para identificar el porcentaje de tiempos buenos cuando la condición del canal es buena, es decir, los picos de canal. La Carga de Sector se puede incorporar en el programador midiendo la cantidad de flujos de BE y EF. Finalmente, la métrica de decisión real utilizada por el programador puede no incluir, de manera explícita, las mediciones de Condición de Canal y Carga de Sector. El Límite de Retraso requerido por usuario puede ser seleccionado, de manera adaptiva, midiendo la fracción de usuarios EF que pueden no cumplir sus límites de retraso para una cierta fracción de paquetes IP transmitidos. Un parámetro utilizado por algunos programadores se denomina como el "índice de clase QoS" de un flujo, el cual define la prioridad relativa para ese flujo. Existe una variedad de métodos por medio de los cuales se pueden determinar las clases QoS. Con una clase determinada QoS, diferentes flujos pueden tener tipos de tráfico muy diferentes. El índice de clase QoS es una indicación para el nivel de prioridad requerido por un flujo, y no un indicador para el comportamiento estadístico del tráfico. En una modalidad, el índice de clase QoS es un valor entero no negativo seleccionado para que el programador provea prioridad superior a flujos que tienen índices de clase QoS superiores. Aquí, el índice de clase QoS de 0 corresponde a flujos BE/AF; en donde los flujos BE son casos especiales de flujos AF donde el valor de rendimiento mínimo requerido se establece en cero. Los índices de clase QoS de 1 y superiores corresponden a flujos EF. Se puede apreciar que a las clases superiores de QoS se les proporciona mayor prioridad; sin embargo, los datos BE no necesariamente serán programados para ser transmitidos después que sean transmitidos todos los datos EF que están esperando en las colas. Como un ejemplo, el programador puede programar un paquete de múltiples usuarios para transmitir un número de bits EF que se están aproximando a un tope. En el mismo caso de transmisión, el programador también puede incluir datos BE de usuarios con DRC compatibles, es decir, formatos de transmisión, mientras que no incluyen bits EF de los usuarios con DRC incompatibles . Un flujo QoS puede ser caracterizado aproximadamente por tres parámetros: (1) distribución del tamaño de datagrama IP, (2) distribución del tiempo de inter-llegada entre datagramas IP, y (3) límite de retraso con relación a la marca de fecha y hora del datagrama IP después del cual, el contenido del datagrama se vuelve inútil. Para flujos BE/AF, el límite de retraso es mucho menos estricto que los flujos EF, de manera que no será considerado para flujos BE/AF, en donde AF es flujos de Reenvío Asegurado. Para flujos EF que tienen un mismo límite de retraso pero que difieren en distribución del tamaño de datagrama IP y tiempo de inter-llegada, el programador es diseñado para que de comporte casi de manera lineal. Por ejemplo, un flujo determinado que tiene el mismo límite de retraso y la distribución de tamaño de paquete que un flujo VolP, pero que tiene la mitad de la distribución del tiempo de inter-llegada se comportaría aproximadamente igual que los dos flujos VolP. De manera similar, un flujo que tiene el mismo límite de retraso y la distribución de tiempo de inter-llegada, pero dos veces la distribución del tamaño de datagrama que un flujo VolP, también se comportaría aproximadamente igual que dos flujos VolP para el programador. Múltiples no enteros de tamaño de paquete y tiempo de inter-llegada se pueden contemplar fácilmente para que se agreguen a un tipo de flujo de "unidad" básica. Sin embargo, el límite de retraso tiene un efecto muy diferente en el programador que el tamaño de datagrama y las distribuciones de tiempo de inter-llegada. El programador trata los flujos con límites de retraso inferiores con prioridad superior. En cierto sentido, la fijación del límite de retraso de un flujo a un valor inferior es una forma suave de aumentar su índice de clase QoS. Como se analizó previamente, la programación de transmisiones está relacionada con el control de admisión, en donde el control de admisión determina cuándo un usuario o flujo es aceptado para procesamiento y programación, después determina cuándo y cómo esos flujos serán transmitidos. En otras palabras, el control de admisión determina cuáles datos serán idóneos para inclusión en un caso de transmisión, y la programación entonces determina los datos específicos, formatos y orden de los casos de transmisión. Por lo tanto, la operación del programador puede impactar el esquema de control de admisión utilizado en un sistema determinado.

De acuerdo con una modalidad, conforme aumenta la carga del sistema, típicamente los flujos BE/AF son programados para que cada uno sufra una degradación de manera justa. Sin embargo, para flujos EF, la degradación típicamente es desigual. De manera más específica, las clases inferiores de QoS se degradan primero en un intento por mantener clases superiores de QoS funcionando de manera adecuada. Dentro de una clase QoS EF determinada, e ignorando las diferencias en las configuraciones del límite de retraso, los usuarios con geometrías inferiores se degradan para mantener la mayor cantidad de usuarios posibles recibiendo el desempeño deseado. Este enfoque se toma para elevar al máximo el número de usuarios RF soportado. Para flujos EF homogéneos, los usuarios EF son degradados de manera desigual comenzando con los usuarios de geometría más baja y propagándose a los usuarios de geometría superior. Este enfoque tiene varias consecuencias, las cuales son tratadas fuera del programador, y muy específicamente, por el procesamiento de control de admisión. Algunas de estas consecuencias se ilustran en los siguientes ejemplos. Esta funcionalidad del programador se ilustra en la figura 6, en donde los flujos se muestran en orden clasificado de acuerdo con su geometría, en donde la geometría aumenta a la derecha. Debido a la carga del sistema actual, el programador proporciona prioridad inferior a los usuarios de geometría inferior para elevar al máximo el número de flujos de QoS que reciben un QoS deseado. El nivel de usuarios de geometría baja se propaga a la derecha con creciente congestión. El programador degrada el servicio recibido por dichos usuarios proporcionándoles menor prioridad. Sin embargo, no es responsable de sacar completamente un flujo, el cual típicamente sería la función del control de admisión y otros bloques de monitoreo de desempeño. Considerar una situación en donde todos los usuarios tienen un solo flujo y tienen la misma clase de QoS, tal como un flujo VolP, y el usuario con la geometría más elevada solicita un flujo EF de rendimiento muy alto. El programador puede asignar todas las ranuras FL al usuario de geometría superior, incluso si esto significa que no haya transmisiones a otro usuario. Generalmente, una decisión de admisión para el flujo es manejada por el procesamiento de control de admisión, el cual considera la carga actual del sistema. Cuando el control de admisión admite el flujo, el programador ejecuta cualquier funcionalidad básica y asigna todas las ranuras FL a ese usuario. Se puede apreciar que, si se degrada primero a los usuarios con geometría inferior, esto no necesariamente significa que el programador eleve al máximo el número de usuarios EF que tienen desempeño de recepción aceptable. El programador puede elevar al máximo dicho número si todos los usuarios tienen un mismo parámetro QoS y un mismo tipo de tráfico (por ejemplo, VolP únicamente) . Si un usuario de baja geometría, cuyo servicio es degradado por el programador debido a la ligera congestión, está solicitando un rendimiento muy bajo (por ejemplo, 1 Byte cada segundo) , el programador puede no proporcionar el rendimiento solicitado o deseado a este usuario, incluso cuando esto no afectara el desempeño del FL. Una vez más, es responsabilidad del control de admisión anticipar la operación del programador con respecto a este usuario debido a la carga del sistema actual. En este caso, el control de admisión puede forzar al programador a proveer servicio a este usuario aumentando su índice de clase QoS. Para el siguiente análisis, considerar el tráfico EF homogéneo como un escenario en donde todos los usuarios son usuarios EF con un mismo modelo de tráfico. El programador primero crea una lista de casos de transmisión candidatos para un conjunto de formatos de transmisión de múltiples usuarios y un solo usuario. Los formatos de un solo usuario son rellenados con bits de las colas de usuarios que tienen DRC compatibles. El programador entonces asigna una métrica de paquete a cada uno de los casos candidato y selecciona el caso de transmisión candidato correspondiente a la métrica de paquete más grande. La métrica de paquete puede ser un "polinomio de rendimiento", en donde una operación de comparación queda definida como la comparación "léxica" proveyendo una maximización bien definida. Considerar la métrica de paquete para el caso especial en donde todos los usuarios son usuarios EF y cada usuario tiene un flujo EF del mismo tipo, por ejemplo, sistema VolP únicamente, y un formato de transmisión de múltiples usuarios, en donde para crear un caso de transmisión de múltiples usuarios para este formato, los bits son rellenados de las colas de los usuarios con DRC compatibles. Entre estos usuarios, los bits son seleccionados con base en el sello de fecha y hora de los datagramas IP correspondientes sobre una base primero en entrar, primero en salir. Se asume que los límites de retraso son los mismos para este ejemplo. Entre los bits que tienen el mismo sello de fecha y hora, la selección sigue el orden en el paquete IP, y entre usuarios diferentes, la selección se realiza en una forma que reduzca al mínimo el número de usuarios que tienen datos en el paquete. El polinomio de carga útil de un caso de transmisión se puede entonces proporcionar como: p(x) = BDZ~D + BD_,Z~M + - --BlZ'1 + B0 en donde Bn representa el número de bits incluido en el caso de transmisión candidato que incurre en un retraso de n ranuras. El valor de D puede ser igual al límite de retraso ya que los bits pueden ser sacados de la cola cuando dichos bits han estado en la cola durante un periodo de tiempo que excede el límite de retraso, y por lo tanto incurrir más de D ranuras de retraso. El polinomio de rendimiento se obtiene filtrando y sub-muestreando el polinomio de carga útil. Un método es segmentar el vector de coeficiente del polinomio de carga útil en N grupos y después sumar los coeficientes dentro de cada grupo para obtener una representación condensada del polinomio de carga útil. El polinomio de rendimiento se obtiene entonces dividiendo el polinomio de carga útil condensado entre el número esperado de ranuras para el caso de transmisión candidato que va a ser decodificado por todos los usuarios de interés. El procedimiento se ilustra en la figura 7, en donde la fila superior es el polinomio de carga útil p(x), y la fila inferior es c(x) el cual es la representación condensada del polinomio de carga útil. La variable x es un índice de caso de transmisión. El polinomio de rendimiento es proporcionado entonces como: T(z) = c z)/Ng en donde Ng es un lapso "genérico" para el formato de transmisión bajo consideración y el método de su cálculo se analiza a continuación. El polinomio de rendimiento resultante se utiliza entonces como la métrica de paquete en la selección de un caso de transmisión candidato entre un conjunto de otras alternativas, cada una obtenida de manera similar. Se puede apreciar que la métrica de paquete arriba descrita sugiere una compensación entre el cumplimiento de latencia y el rendimiento. Si N-l fuera seleccionado para ser igual a D, es decir, si c(x)=p(x), entonces la métrica de paquete haría valer la transmisión de los bits que incurren en el primer retraso más grande. Posteriormente, los bits que incurren en el siguiente retraso más grande serían considerados en la selección de un caso de transmisión candidato. Este es un resultado de la comparación "léxica" utilizada para comprar las métricas de paquete (es decir, los polinomios de rendimiento) . De esta forma, la comparación comienza identificando el orden más elevado de cada polinomio. Si un polinomio es de un orden superior, entonces ese polinomio queda definido como el polinomio más grande. Si ambos tienen un mismo orden, entonces los coeficientes se comparan empezando con el orden más elevado; cuando se encuentra un coeficiente superior en un polinomio, ese polinomio es definido como el polinomio más grande. La segmentación de los coeficientes de p(x) para obtener c(x), implícitamente ignora diferencias en el retraso incurrido correspondiente a los bits dentro de cada segmento. A cambio, existe una maximización del rendimiento, la cual ahora tiene más flexibilidad. La mayor flexibilidad en la maximización del rendimiento se obtendría si todos los coeficientes de p(x) se combinaran en un solo segmento (por ejemplo c(x) de orden cero). En un ejemplo, dos segmentos (por ejemplo, c(x) de orden uno) proveen un equilibrio. El término de orden más grande tiene el mayor impacto. Cuando existe un vínculo entre varios casos candidato, se considerarían los términos de c(x) . Por lo tanto, pudiera no ser necesario segmentar los coeficientes de p(x) en más de dos segmentos. Esto produce como resultado un solo parámetro a optimizar, el cual quedará denotado por a y se llamará "la fracción de retraso". En resumen, con dos segmentos, c(x)=(hi2)z-l+(hi), en donde "hi2" y "hi" son el número de bits en cada segmento, respectivamente. De manera más específica, hi2 es el número de bits incluido en el caso de transmisión candidato que incurre en un retraso más grande que a veces el límite de retraso; y "hi" es el número de bits que incurre en un retraso más pequeño. Para el caso de usuarios que tiene todo el tráfico EF, pero con diferentes modelos de tráfico (por ejemplo, diferentes límites de retraso) , el argumento es modificado. Los bits con límites de retraso más pequeños van a ser parte del segmento hi2 más pronto que los bits con límites de retraso más grandes. Una forma natural de lograr esto es utilizar ß veces el retraso, en oposición al "retraso" solo, para rellenar bits en los casos de transmisión candidato y para determinar cuándo los bits se convertirán en parte del engranaje hi2. En general, ß está diseñada para que sea proporcional a uno en el límite de retraso. Un resultado de esto es que los bits EF con límites de retraso inferiores tenderán a tener prioridad sobre bits EF con límites de retraso más grandes. La figura 8 ilustra un programador de acuerdo con una modalidad. El programador 600 incluye una unidad de control de retraso 602 acoplada a una unidad de almacenamiento de memoria 604 adaptada para almacenar y mantener información de cola. La unidad de almacenamiento de memoria 604 también almacena información relacionada con cada cola, incluyendo sensibilidad de retraso y/o rendimiento, clase de prioridad, tal como EF, BE, etc., y otra información la cual se puede diseñar en el programador, tal como otra información QoS. Los datos de cola y la información almacenada en la unidad de almacenamiento de memoria 604 es provista a la unidad de cálculo de métrica de bits 608 y la unidad de cálculo de métrica de relleno de bits 606. Estas unidades generan una métrica de bits y una métrica de relleno de bits, respectivamente. La métrica de bits calculada es provista a la unidad de cálculo de métrica de bits 608, la unidad de cálculo de métrica de paquete 616, y la unidad de selección de cola 610. La métrica de relleno de bits y las colas seleccionadas son provistas al generador de caso de transmisión candidato 612. La métrica de paquete de la unidad de cálculo de métrica de paquete 616 y el conjunto de casos de transmisión candidato generados por el generador 612 se proveen a la unidad de selección de caso de transmisión 614. La figura 9 detalla la unidad de almacenamiento de memoria 604 como múltiples colas de almacenamiento que tienen datos pendientes. Los datos en cola son almacenados por flujo como datos en cola 620. Para cada cola 620 existe una clase QoS correspondiente o clase de prioridad 622 y un designador de sensibilidad 624. La figura 10 es un diagrama de flujo que ilustra el método de programación de acuerdo con una modalidad. El método 500 primero determina, en el diamante de decisión 502, si el FL está ocupado, es decir, si la ranura de tiempo está disponible para una nueva transmisión de paquete. Si la ranura está disponible para una nueva transmisión de paquete, el programador genera una lista de casos de transmisión candidato con base en un sub-co unto de formatos de transmisión definidos y derivados en el paso 504. La métrica de paquete correspondiente a cada caso de transmisión de candidato se calcula en el paso 506. En el paso 508, el programador selecciona un caso de transmisión que tiene un valor mayor para la métrica de paquete. En el paso 510, el caso de transmisión es formateado para transmisión. La figura 11 ilustra una modalidad para generar un conjunto de casos de transmisión candidato y ejecutar el paso 504 en el método 500. En el paso 520, el programador calcula una métrica de bits para cada entrada de cola. En el paso 522, el programador calcula una métrica de relleno de bits para cada cola. Los valores de métrica de bits se comparan para seleccionar un conjunto de colas para un caso de transmisión, paso 524. La métrica de relleno de bits se utiliza para generar casos de transmisión candidato utilizando el conjunto de colas, paso 526. Ejemplos de métodos y medios para dichos cálculos y comparaciones se proveen a continuación.

En una modalidad se puede apreciar que, un caso de transmisión candidato con un formato de un solo usuario es generado para cada usuario que tiene datos pendientes. El formato de transmisión se establece al formato canónico correspondiente a ese DRC de usuario. Para usuarios, de los cuales se ha recibido DRC NULO, un caso de transmisión candidato es creado únicamente si el usuario tiene datos "EF" pendientes. Para usuarios BE/AF, los DRC NULOS no reciben servicio debido a que estos usuarios tratan de mantener velocidades de baja caída en la capa de Protocolo de Capa de Radio (RLP) . Un caso de transmisión candidato con un formato de múltiples usuarios es generado para cada formato de múltiples usuarios "canónico" derivado. Se puede utilizar un indicador para permitir formatos derivados en esta etapa. Se puede apreciar que, el conjunto de casos de transmisión candidato generados en el paso 506 se basan en formatos "canónicos". Es decir, los paquetes cortos no están incluidos en este paso. El propósito es ayudar a desviar el programador hacia usuarios de geometría superior y evitar que los usuarios de baja geometría abusen de los paquetes cortes y reduzcan, por lo tanto, el rendimiento del FL. Los paquetes cortos se utilizan en un paso de maximización de eficiencia de empaque (como se ilustra en la figura 12) cuando el caso de transmisión candidato seleccionado tiene una carga útil que se ajuste en un paquete corto. Un paso de maximización de eficiencia de empaque puede ser ejecutado consistente con la figura 12. En este paso, el caso de transmisión candidato seleccionado puede experimentar un cambio de formato de transmisión de acuerdo con las siguientes reglas. (1) Si el caso de transmisión candidato seleccionado contiene datos de un solo usuario, se permite que el formato re-seleccionado sea un formato de un solo usuario compatible con el DRC del usuario o un formato de múltiples usuarios. (2) Si el caso de transmisión candidato seleccionado contiene datos de dos o más usuarios, el formato re-seleccionado solo puede ser otro formato de múltiples usuarios. En cualquier caso, se selecciona el formato más pequeño que tenga la capacidad de portar la carga útil. Esta post-conversión es controlada adicionalmente por indicadores que pueden evitar conversiones a algunos formatos de múltiples usuarios. En una modalidad, el paso 510 para formatear el caso de transmisión además incluye un paso 530 en donde el programador eleva al máximo una eficiencia de empaque del caso de transmisión, y un paso 532 en donde el programador ejecuta un cálculo ACK a priori, ver figura 12. Adicionalmente, el paso 530 puede incluir el método como se ilustró en la figura 13. El caso de transmisión primero es evaluado para determinar si se utiliza un formato de un solo usuario, diamante de decisión 540. Si se utiliza un formato de un solo usuario, cada paso se detalla adicionalmente a continuación. En una modalidad, el programador determina el lapso máximo correspondiente a los DRC de los usuarios para los cuales el caso de transmisión seleccionado estará portando bits de datos. El programador cuenta el número designado de ranuras de transmisión. Si existen cualesquiera usuarios que aún no hayan reconocido la recepción correcta de la información transmitida, es decir, un mensaje ACK transmitido, y si existen datos pendientes en cualquiera de las colas, la AN termina la transmisión. Una modalidad alterna incluye medios específicos y métodos para completar el método 500 que se ilustra en la figura 10, incluyendo, pero no limitado a, rellenado de bits para crear cada caso de transmisión candidato y cálculo de una métrica de paquete. Los cálculos de la métrica de paquete se realizan en el paso 508, mientras que el rellenado de bits es parte del formateo del caso de transmisión del paso 508. En general, un caso de transmisión de un solo usuario puede ser rellenado con bits de uno o más flujos del mismo usuario. Un caso de múltiples usuarios con un formato "definido", tal como uno definido en el Cuadro 1, puede ser rellenado con bits de uno o más usuarios, en donde dichos usuarios tienen DRC transmitidos compatibles con el formato de múltiples usuarios. Un caso de múltiples usuarios con un formato "derivado" puede ser rellenado con bits provenientes de uno o más usuarios los cuales transmitieron DRC compatibles con el formato de múltiples usuarios y los cuales satisfacen el requerimiento adicional de "compatibilidad suave". Un DRC se considera en compatibilidad suave con un formato de múltiples usuarios derivado si el número esperado de ranuras para decodificar el formato "definido" correspondiente es menor que o igual al lapso del formato derivado. El número esperado de ranuras se puede obtener comparando la Relación Señal-a-Interferencia y Ruido (SINR) que se requiere para el DRC recibido con la SINR que se requiere para decodificar el formato derivado exitosamente (por ejemplo, bajo condiciones de Ruido Gausiano Blanco Promedio (AWGN) ) . Alternativamente, el número esperado de ranuras se puede determinar comparando la velocidad solicitada con la velocidad de datos efectiva del formato derivado. La siguiente descripción asume las clases QoS incluyendo: i) BE/AF; y una clase de EF. El método también permite la extensión a múltiples clases EF. De acuerdo con la presente modalidad, a cada bit pendiente en la cola se le asigna una métrica de bits la cual se proporciona como un polinomio de la forma: b, (z) = [hi2]z~2 + [híz~ + [lo] en donde i es un índice del bit, y solo se permite que uno de los tres coeficientes {hi2, hi, lo} sea no cero. Se puede apreciar que, aunque la descripción es proporcionada como nivel de bits, típicamente todos los bits en un datagrama IP tienen la misma métrica y los cálculos de métrica de paquete pueden no necesariamente involucrar acumulaciones del nivel de bits. Asumir que d es el retraso actual asociado con un bit proveniente de un flujo EF. Establecer las siguientes definiciones para hi2 y hi : Hi2=ßd+µ si d>a Límite de Retraso y hi=ßd+µ si d<a Límite de Retraso en donde ß es un parámetro asociado con el flujo EF y está inversamente relacionado con el límite de retraso; en donde µ es un número grande; y en donde a es un escalar fijo, por ejemplo 0.25, y es independiente del tipo de flujo EF.

Para un flujo BE/AF, establecer lo de la siguiente manera : lo = - RendimientoPromedio - RendimientoObjetivo en donde el Rendimiento Promedio es el rendimiento promedio del usuario correspondiente, y Rendimiento Objetivo es el rendimiento mínimo deseado para ese usuario. Para un usuario BE, el Rendimiento Objetivo se configura en cero. La métrica de paquete (por ejemplo, el polinomio de rendimiento) se obtiene entonces de la siguiente forma: Métrica de Paquete = Métrica de Bits Acumulados /Ng en donde Ng es el lapso genérico del caso de transmisión candidato derivado bajo consideración y la métrica de bits acumulados (Métrica de Bits Acumulados) es la suma de las métricas de bits correspondientes a todos los bits incluidos (o rellenados) en el caso candidato. El valor Ng se puede establecer al lapso nominal del tipo definido o derivado. Alternativamente, se puede establecer a uno, en cuyo caso la métrica de paquete será igual a la métrica de bits acumulados. En este caso, el programador funcionará para elevar al máximo la carga útil por caso de transmisión en lugar de rendimiento por caso de transmisión. Esto puede tener el efecto indeseable de crear insensibilidad del DRC, ocasionando así un desempeño degradado, en donde dicha degradación puede no seguir el comportamiento que se ilustra en la figura 6. Otro enfoque es establecer Ng a un "seudo-lapso" el cual se puede establecer en uno para paquetes de alta velocidad de 1 y 2 ranuras, establecer en dos para paquetes de 4 ranuras, etc., distinguiendo así los paquetes de alta velocidad en base a la carga útil, mientras que los formatos de baja velocidad se frenan estableciendo Ng a valores más grandes. Las siguientes propiedades proveen una desviación hacia usuarios de geometría elevada para el programador: (1) Si un DRC es compatible con un formato de múltiples usuarios, también es compatible con todos los formatos de múltiples usuarios de velocidad de datos nominal inferior; y (2) El programador utiliza el polinomio de "rendimiento" como un dispositivo de selección. Un diseño utiliza un término de valor grande u en la definición de los coeficientes hi y hi2 para las métricas de bits. Los bits son rellenados en orden de acuerdo con el valor de ßd debido a que µ es común a todos los bits. La métrica de paquete se calcula como si la entrada correspondiente de la métrica de bits se cambiara a uno, produciendo así como resultado una métrica de paquete proporcional al polinomio de rendimiento. Esto elimina el efecto de ßd en la métrica de paquete para el cálculo de la métrica de paquete. Se puede apreciar que, como se describió anteriormente, el programador aplica un Límite de Retraso fijo a todos los usuarios. Típicamente, los usuarios que experimentan buena cobertura solo requieren una fracción del Límite de Retraso. Conforme aumenta el número de usuarios, la degradación primero comienza en los usuarios más débiles, mientras que los usuarios en geometrías altas pueden no verse afectados fuertemente por la carga. Una modalidad establece, de manera adaptiva, el límite de retraso y parámetros relacionados (por ejemplo, a) midiendo la fracción de usuarios RF buenos. El Límite de Retraso utilizado por el programador puede ser aumentado o reducido, de manera iterativa, para mantener la fracción de usuarios buenos en un nivel deseable. En una modalidad se ejecuta un simple lazo de primer orden con un límite inferior para Límite de Retraso. En el programador descrito anteriormente, el método que define la métrica de bits para usuarios BE/AF utiliza el siguiente cálculo: Métrica de bits = 1/ [Rendimiento Promedio -Rendimiento Objetivo] Se pueden ejecutar otras definiciones de métrica de bits para diferentes sistemas, objetivos operativos y diseño. Los formatos de transmisión FL compatibles con el índice DRC también se listan en el Cuadro 1 para dos conjuntos de sub-tipos de protocolo en las especificaciones de lxEV-DO Rel-0 y Revisión A, respectivamente, incluyendo cambios propuestos en contribuciones recientes para Rev-A que definen formatos de múltiples usuarios compatibles para índices DRC de 0x0, 0x1, y 0x2. Un formato de transmisión, como en la especificación Rev. A, está representado por el triplete (Tamaño de Paquete, Lapso, Longitud de Preámbulo) . "0" es el número de bits que el formato de transmisión porta incluyendo el Código de Redundancia Cíclica (CRC) y cola. "Lapso" es el número nominal (por ejemplo, máximo) de ranuras que un caso de transmisión tomaría en el enlace de avance. "Longitud de Preámbulo" es el número total de chips de preámbulo. Tal como en la especificación Revisión A de lxEV-DO, los formatos de transmisión "canónica" para cada DRC quedan indicados en negritas. Se puede apreciar que, Rel-0 define únicamente los formatos de transmisión de un solo usuario, mientras que algunos sub-tipos en la Revisión A definen formatos tanto de usuario sencillo como de múltiples usuarios. Además, en la Revisión A, múltiples formatos de transmisión se pueden definir para cada índice DRC. La AT trata de recibir paquetes en cada uno de estos formatos. Los formatos de múltiples usuarios se distinguen por sus índices MAC únicos, es decir, el preámbulo para cada formato de múltiples usuarios utiliza una cubierta Walsh distinta. Los formatos de usuario sencillo utilizan el índice MAC asignado a un usuario.

CUADRO 1 Formatos de transmisión para IxEV-DO Rel.O y Rev.A Como un recordatorio, un caso de transmisión se refiere a un formato de transmisión con un conjunto particular de bits de una o más colas seleccionadas para que sean transportadas por éste. Un caso de transmisión candidato se refiere a un caso de transmisión que va a ser evaluado por un algoritmo de programación para posible transmisión. Los formatos de transmisión de múltiples usuarios (1024,4,256), (2048,4,128), (3072,2,64), (4096,2,64) y (5120,2,64) se denominan como los formatos de transmisión de múltiples usuarios canónicos. Los formatos de transmisión de múltiples usuarios (128,4,256), (256,4,256) y (512,4,256) se denominan "formatos de múltiples usuarios no canónicos". Los formatos de transmisión derivados se obtienen simplemente estableciendo un lapso del formato definido correspondiente a valores más pequeños que el valor nominal, como si se obtuvieran de los formatos definidos por la terminación anticipada. En resumen, los formatos de transmisión y casos pueden ser canónicos o no canónicos; de usuario sencillo o múltiples usuarios; y definidos o derivados. El término "número nominal de ranuras" se utilizará para hacer referencia al número máximo de ranuras para un formato de transmisión definido y el número máximo redefinido de ranuras para un formato de transmisión derivado. La siguiente descripción del medio de programación y métodos considera una programación basada en octeto, en donde los octetos pendientes en varias colas pueden ser servidos en cualquier cantidad (en unidades de octetos). Típicamente, cada flujo será almacenado por lo menos como una cola de datos. Por lo tanto, cada cola tiene requerimientos QoS específicos asociados con la misma. Los datos son almacenados en cada cola en octetos. La programación se puede realizar en donde menos de un octeto completo de datos es puesto en un caso de transmisión o paquete de capa física para transmisión en el FL. Se puede apreciar que, algunas aplicaciones pueden requerir programación basada en trama, en donde los datagramas (encapsulados) del flujo van a ser servidos sin fragmentación dentro de los paquetes de capa física. Los medios y métodos de programación basados en octeto también se pueden extender a programación basada en tramas. Se puede apreciar también que, el control de admisión está estrechamente relacionado con la programación, en donde el control de admisión sirve para admitir/rechazar los flujos entrantes con base en la carga del sistema actual y pronosticando si el flujo entrante puede ser servido satisfactoriamente (es decir, cumplir los objetivos QoS) sin ocasionar una degradación inaceptable a los flujos ya admitidos. Como se utiliza en la presente invención, "flujo" se refiere a una corriente de datos dirigida a un usuario determinado. La fuente de un flujo puede ser una o más aplicaciones de usuario, incluyendo, pero no limitado a, descargas de archivo (ftp) , exploración por la web (http) , juegos en línea, o VolP, entre muchos otros. Un flujo también puede ser generado por el sistema de comunicación mismo, tal como flujos de señalización, los cuales sirven para mantener el sistema en operación mientras se mantiene la sesión de usuario de forma adecuada. Otro ejemplo de un flujo es una corriente de datos generada por una aplicación de prueba, en donde la corriente de datos se utiliza para probar por lo menos una porción del sistema de comunicación. En otras palabras, un flujo es una corriente de datos, y es parte de una comunicación por lo menos con un usuario. Existe una variedad de flujos de aplicación, cada uno con tolerancias y requerimientos QoS específicos. Cada flujo puede tener un conjunto diferente de requerimientos QoS, tal como un rendimiento objetivo y límite de retraso. Ejemplos de dichos requerimientos se analizan específicamente a continuación. Un usuario puede tener múltiples flujos simultáneos con diferentes requerimientos de QoS. Cada flujo puede ser generado ya sea por una sola aplicación, tal como para VolP, ftp, señalización, etc. o puede ser generada por múltiples aplicaciones que son agregadas en un solo flujo por el Controlador de Estación Base (BSC) . Si el BSC agrega flujos en esta forma, el flujo agregado puede aparecer ante el programador como un solo flujo con requerimientos QoS bien definidos . El programador puede no tener la capacidad para distinguir entre datos generados por diferentes aplicaciones pero contenidos en un flujo agregado. A continuación se muestra otro tipo de agregación que puede ser realizada por el programador. Cada flujo tiene por lo menos una cola que mantiene datos para la transmisión por Primera Vez (denominada como FTx) y puede tener colas adicionales para retransmisiones, tal como la cola de Retransmisión (cola RTx del flujo x) de Protocolo de Capa de Radio (RLP) y/o la cola de retransmisión de capa MAC (solicitud de Repetición Automática retrasada (ARQ) , o cola ARQ Retrasada (DARQ) ) . En una modalidad, cada octeto en cada cola tiene un sello de fecha y hora bien definido., a través del cual, el programador puede determinar el retraso actual incurrido por el octeto. A los sellos de fecha y hora se les asignan ráfagas de datos tal como datagramas (encapsulados) , implicando que cada octeto de la ráfaga de datos tiene el mismo sello de fecha y hora. Datagramas individuales pueden portar múltiples tramas de nivel de aplicación, las cuales pudieran haber sido generadas por una aplicación en diferentes tiempos. Se asume que los sellos de fecha y hora de la trama de aplicación no son conocidos por el programador. Esta suposición es apropiada, debido a que el datagrama completo va a ser recibido exitosamente por un usuario antes que cualquiera de las tramas de aplicación portadas por éste pueda ser analizada sintácticamente por la aplicación de extremo de recepción. En el diseño de un programador de acuerdo con una modalidad, se consideran tres clases QoS principales. El Mejor Esfuerzo (BE) queda definido como en el glosario, y específicamente se refiere a flujos que típicamente pueden soportar retrasos relativamente altos de extremo-a-extremo, pero que requieren una Velocidad de Error de Bits baja (BER) . Aunque no existe un requerimiento de rendimiento mínimo, el tamaño de los datos que se van a transmitir puede ser alto. Ejemplos de flujos que se pueden considerar BE incluyen descargas de archivo (ftp) y exploración por la web (http) . El Reenvío Asegurado (AF) se refiere a flujos que, en general, son similares a los flujos BE ya que toleran cierto nivel de retraso; sin embargo, los flujos AF difieren de los flujos BE ya que los flujos AF típicamente tienen un rendimiento promedio mínimo. Un ejemplo de una aplicación clasificada como un flujo AF es la corriente de video generada por una aplicación de videoconferencia. El Reenvío Acelerado (EF) se refiere a los flujos que típicamente, pero no necesariamente, tienen un bajo requerimiento de rendimiento, y tienen requerimientos estrictos de retraso de extremo-a-extremo. El requerimiento de confiabilidad puede no ser tan estricto como para flujos BE; puede ser aceptable para perder una pequeña fracción de datos de aplicación, tal como, por ejemplo 1 ó 2%. Ejemplos de aplicaciones clasificadas como flujos EF incluyen, pero no se limitan a, VolP y juegos en línea.

Con respecto a los medios y métodos de programación, la diferencia entre flujos BE y AF se ubica en el requerimiento de rendimiento mínimo, el cual es cero para flujos BE. De otra forma, estas dos clases de QoS son similares. Para diferenciar adicionalmente flujos específicos, considerar la clase EF, las cuales pueden incluir una variedad de diferentes tipos de aplicaciones. Dentro de la clase de flujos EF, puede haber flujos con diferentes prioridades. Como un ejemplo, las aplicaciones tal como VolP y la parte de audio de una aplicación de videoconferencia se puede considerar como de prioridad superior que la parte de video de la aplicación de videoconferencia. Se puede considerar que los juegos en línea tienen una prioridad menor que las aplicaciones de audio y video. Además de los flujos generados por las aplicaciones de usuarios, un sistema que soporta IS-856 tiene flujos internamente generados, tal como el flujo de señalización que se requiere para mantener el sistema en operación, y los flujos generados por las aplicaciones de prueba que se utilizan para probar el sistema. Típicamente, los requerimientos QoS se pueden establecer en términos de una variedad de consideraciones descritas por variables, incluyendo pero no limitado a, límite de retraso, rendimiento objetivo, confiabilidad, inestabilidad, etc. El límite de retraso es identificado por la variable denominada como "Límite de Retraso", el cual es un parámetro especificado para cada flujo que se refiere al retraso mínimo dentro del cual, el datagrama va a ser entregado exitosamente al usuario. El Límite de Retraso se mide con relación al sello de fecha y hora de un datagrama, el cual, en la presente modalidad, es un octeto. Se puede apreciar que, éste es diferente del límite de retraso de extremo-a-extremo el cual involucraría componentes de retraso-presupuestario que no sean el retraso FL. En una modalidad, una vez que se alcanza el Límite de Retraso de un datagrama, el datagrama es sacado de la cola. En otras palabras, si el datagrama no puede ser enviado dentro del límite de retraso especificado, el datagrama se descarta. El rendimiento objetivo queda definido por la variable a la que se hace referencia como "Rendimiento Objetivo" la cual es otro parámetro QoS especificado. El rendimiento objetivo se refiere al rendimiento promedio mínimo requerido para un flujo. La ponderación del rendimiento se puede definir a través de un filtro de Respuesta de Impulso Infinito de primer orden (IIR) con una constante de tiempo apropiada. En una modalidad, la constante de tiempo se establece en 1 ms. Un tercer requerimiento de QoS puede ser la confiabilidad. Por lo regular, la capa física del sistema provee 1% de Velocidad de Error de Paquete (PER) el cual puede no ser suficiente para aplicaciones que requieren una velocidad de error excepcionalmente baja, tal como descargas de archivo. Por lo tanto, para reducir adicionalmente las pérdidas en el aire, se pueden utilizar mecanismos de retransmisión. Los mecanismos de retransmisión típicos son retransmisiones RLP y retransmisiones de capa MAC, tal como colas RTx y DARQ, respectivamente. Más allá de esto, el Protocolo de Control de Transmisión (TCP) se puede utilizar como un protocolo de capa de transporte para que una aplicación provea confiabilidad adicional. En una modalidad, el programador está diseñado para elevar al máximo la capacidad del sistema mientras se provee imparcialidad a través de los flujos y se cumplen ciertos requerimientos de prioridad y QoS para cada uno de los flujos. Los conceptos de capacidad e imparcialidad dependen de los requerimientos QoS de flujos individuales. Para flujos BE, la capacidad se puede definir como el rendimiento BE total transmitido por un sector. Para flujos EF de un tipo particular, la capacidad se puede definir como el número de usuarios que pueden ser soportados mientras se cumplen los requerimientos QoS. En un ejemplo de programación de flujo EF, el sistema define la capacidad VolP para que el número de usuarios VolP sea seleccionado como el número que logrará el 95% de los usuarios, en promedio, recibiendo el 98% de las tramas de datos de aplicación (u octetos) exitosamente. En un ejemplo, el éxito queda determinado por las tramas recibidas dentro del Límite de Retraso especificado y libres de errores de transmisión. También se pueden utilizar criterios de éxito alternos. Para lograr la imparcialidad a través de flujos, se puede utilizar un criterio de Imparcialidad Proporcional (PF) para programar flujos BE, y programar flujos EF de acuerdo con un criterio de prioridad. De esta forma, conforme la carga del sistema aumenta, los flujos BE sufren una degradación uniforme, es decir, los flujos BE se degradan sin diferenciación. Para flujos EF, es deseable tener una degradación desigual a través de los usuarios conforme aumenta la carga del sistema u ocurre la congestión. La degradación primero es sentida por aquellos flujos EF considerados como de prioridad más baja. Entre los flujos EF que tienen requerimientos QoS similares y un mismo nivel de prioridad, la degradación primero va a afectar los flujos para usuarios que tienen las peores condiciones de canal. Con este enfoque, conforme aumenta la congestión del sistema, el número más grande posible de flujos EF puede satisfacer sus requerimientos QoS. Este enfoque por lo regular produce como resultado una relación aproximadamente inversa entre la condición de canal de un usuario y las estadísticas de retraso de sus flujos EF. Esta propiedad se denomina como "Imparcialidad de Retraso". Un "formato de transmisión" es un triplete de la forma (Tamaño de Paquete, Lapso, Longitud de Preámbulo) la cual describe algunos parámetros de un paquete FL. El Tamaño de Paquete se refiere al tamaño de carga útil de capa física en bits, Lapso se refiere al número máximo de ranuras que un paquete de ese formato puede transmitir, y Longitud de Preámbulo se refiere a la duración en chips del preámbulo. En un sistema que soporta IS-856, la adaptación de enlace se utiliza para determinar la velocidad de datos de transmisión FL para cada usuario. Cada AT transmite una solicitud de datos que indica una velocidad de datos máxima a la que la AT puede recibir datos. La solicitud de datos se denomina como un mensaje de Control de Velocidad de Datos (DRC) . El formato de mensaje DRC utiliza una variedad de índices DRC, cada uno especifica un formato de transmisión. La AT envía el mensaje DRC en un canal DRC. Para cada índica DRC válido, excepto DRC NULO en IS-856 Rel-0, existe uno o más formatos de transmisión de usuario sencillo y cero o más múltiples usuarios, los cuales pueden ser servidos en el FL para portar datos a un usuario. El cuadro 1 detalla los índices DRC tal como se define en IS-856. Adicionalmente, el cuadro 1 además incluye formatos de transmisión compatibles para cada índice DRC. En la especificación lxEV-DO Rev-A, para cada índice DRC, uno de los formatos de transmisión compatibles de usuario sencillo se define para ser el formato canónico para ese DRC. Se puede apreciar que, tal como se utiliza en la presente invención, el DRC corresponde al formato específico solicitado por la AT e identificado por el índice DRC. Generalmente, si una AT decodifica exitosamente un paquete transmitido utilizando el formato canónico correspondiente a un DRC determinado, entonces dicha AT también tendría posibilidades de decodificar con éxito un paquete transmitido con cualquiera de los formatos de usuario sencillo no canónicos compatibles o cualquiera de los formatos de múltiples usuarios compatibles. Esto es con excepción de los índices DRC: 0x0; 0x1; y 0x2. Se puede apreciar que, conforme los formatos de múltiples usuarios compatibles con un DRC determinado pueden tener longitudes de preámbulo más grandes en comparación con el formato canónico, éstos no necesariamente resultan en una ganancia de procesamiento de datos. Para cualquier DRC, excluyendo todos los formatos compatibles con el índice DRC 0x0 y los formatos de múltiples usuarios compatibles con los índices DRC de 0x1 y 0x2, el tamaño de carga útil de un formato no canónico típicamente es menor que, o igual a aquel del formato canónico. Adicionalmente, el lapso de un formato no canónico típicamente es más grande que, o igual al lapso del formato canónico. Si un usuario desde el cual se ha recibido un índice DRC de 0x0 (por ejemplo, solicitud de velocidad NULA) es servido en cualquier formato, en general, no existe garantía de recepción confiable del paquete. También, para índices DRC de 0x1 y 0x2, los formatos compatibles de transmisión de múltiples usuarios pueden no asegurar de manera suficiente la recepción confiable, debido a que el tamaño de carga útil y el lapso de estos formatos no satisfacen esta propiedad. En una modalidad, el programador puede no utilizar paquetes de múltiples usuarios para servir a usuarios desde los cuales el DRC recibido es 0x0, 0x1 ó 0x2. También, el servicio a los usuarios desde los cuales se recibe un DRC NULO (0x0) puede estar limitado a ciertas condiciones. Esas condiciones se pueden diseñar en el sistema. Para formatos de transmisión de múltiples usuarios, si un DRC determinado es compatible con un formato de múltiples usuarios determinado, entonces el mismo DRC es compatible con todos los formatos de múltiples usuarios de velocidades de datos inferiores.

Un "caso de transmisión" se refiere a la combinación de un formato de transmisión y las identidades de octetos de datos que pueden ser portados por un paquete de ese formato. Por ejemplo, el conjunto de índices MAC para los usuarios a quienes el paquete va a portar octetos de datos y un conjunto de indicadores para las colas correspondientes que indiquen exactamente cuáles octetos van a ser portados en el paquete pueden definir el formato de transmisión. El programador puede generar un conjunto de casos de transmisión hipotética, y entonces seleccionar uno de estos casos de transmisión en el FL. El término utilizado en este documento para hacer referencia a cualquiera de estos casos de transmisión hipotética es un "caso de transmisión candidato". En una modalidad de un programador que incorpora una gestión de retraso adaptiva, varias métricas son utilizadas por el programador e incluyen: 1) una métrica de relleno de bits; 2) una métrica de bits; y 3) una métrica de paquete. La métrica de bits se utiliza para seleccionar colas, las cuales son idóneas para incorporación en un caso de transmisión actual. Las métricas de relleno de bits determinan el orden en el que los bits (u octetos) , los cuales están pendientes en varias colas, son incluidos en un caso de transmisión candidato determinado. Una vez que se crea un caso de transmisión candidato, se calcula una métrica de paquete para el caso de transmisión candidato. La métrica de paquete se utiliza entonces para seleccionar un caso de transmisión decisivo a partir de un conjunto de casos de transmisión candidato similarmente creados. La métrica de paquete de un caso de transmisión candidato queda determinada sumando simplemente las métricas de bit de todos los octetos incluidos en el caso de transmisión candidato y dividiendo la suma entre el lapso del formato de transmisión del caso de transmisión candidato: Métrica de Paquete[k] = Métrica de Bits[i] Lapso[k]¡^k] en donde k representa un índice para un caso de transmisión candidato particular dentro de un conjunto de alternativas, Lapso [k] representa el lapso definido para el formato de transmisión correspondiente, P[k] representa el conjunto de octetos que se incluyen en el caso de transmisión candidato, y Métrica de Bits [i] representa la métrica de bits del iavo octeto incluido en el caso candidato. Por lo tanto, la métrica de paquete puede ser interpretada como un estimado del "rendimiento instantáneo de la métrica de bits" si el caso de transmisión candidato fuera en realidad servido en el FL. En general, si la métrica de relleno de bits de un octeto i es más grande que la métrica de relleno de bits de otro octeto j , entonces la métrica de bits del octeto i se puede establecer más grande o igual a la métrica de bits del octeto j . En este caso, los octetos pueden provenir de diferentes colas. De manera similar, si la métrica de bits de un octeto i es más grande que de otro octeto j , entonces la métrica de relleno de bits del octeto i se debería establecer más grande que, o igual a aquella del octeto j, es decir: Métrica de Bits [i]> Métrica de BitsßJ ? Métrica de Relleno de Bits JAMétrica de Relleno de BitsßJ Métrica de Relleno de Bits [i] > Métrica de Relleno de BitsßJ ? Métrica de Bits ßj> Métrica de BitsßJ Este lineamiento general asegura que un octeto rellenado en un caso de transmisión candidato contribuye a la métrica de paquete por lo menos por la misma cantidad que otro octeto el cual es rellenado más tarde. Todas las métricas aquí descritas, así como métricas alternas, pueden ser representadas en forma de polinomio de la siguiente forma: Mé tri ca : [MCO] + [MCI ] x+ [MC2] x2++ [MC3 ] x3++ [MC4 ] x4++ [MCb] x5 + [ C6] x6++ [MCI ] x7 en donde la Métrica puede ser cualquiera de los tipos de métrica y MCO,... MC7 representa los coeficientes de métrica. La adición de dos métricas y la multiplicación (o división) de una métrica por un escalar, quedan definidas como en álgebra de polinomios; en donde, cuando dos métricas son sumadas, los coeficientes correspondientes de los dos polinomios se suman. Cuando una métrica es multiplicada (o dividida) por un escalar, cada uno de los coeficientes es multiplicado (o dividido) entre el mismo escalar. Esto permite el cálculo de las métricas de paquete que utilizan las métricas de bits calculadas como se proporcionó anteriormente. Los operadores de comparación ">, >=, =, <=, <" quedan definidos en el sentido léxico, es decir, cuando se comparan dos métricas, primero de comparan los coeficientes de los términos de grado más elevado. Si son iguales, entonces se comparan los coeficientes de los siguientes términos de grado más alto, etc. Dos métricas son iguales, si todos los coeficientes correspondientes de las dos representaciones de polinomios son iguales. Las operaciones de comparación se utilizan para comparar las métricas de relleno de bits así como para comparar las métricas de paquete.

Métrica de Bits, Relleno de Bits y Métricas de Paquete Para métricas de bits y métricas de relleno de bits, solo un término de las representaciones correspondientes de polinomio son no cero en cualquier momento determinado. El grado del término no cero es el mismo para la métrica de bits y la métrica de relleno de bits para un octeto determinado. El grado de este término no cero, el cual generalmente se referirá por el nombre del coeficiente correspondiente. MCO, ... MC7 se denominará el "estado de prioridad" de la métrica (o el octeto correspondiente) de bits (relleno) . La definición de la operación de comparación implica que el término MCO corresponde a los octetos de prioridad inferior, y el término MC7 corresponde a los octetos de prioridad superior. El estado de prioridad de una métrica de bits (relleno) para un octeto i queda determinado por el retraso actual incurrido por el octeto proporcionado como: Retraso Actual [ i] =Tiempo Actual-Sello de Fecha y Hora [i] y utilizando un conjunto ordenado de umbrales conocidos como los "umbrales de prioridad" definidos para el flujo al que pertenece el octeto. El Sello de Fecha y Hora [i] es un sello de fecha y hora apropiadamente definido para el octeto i. Cada intervalo definido por los umbrales de prioridad se traza a un estado de prioridad. Los umbrales de prioridad y el trazado de los intervalos así definidos para los estados de prioridad se pueden especificar al programador para cada flujo por separado. El Retraso Actual [i] del octeto se compara con aquellos conjuntos ordenados de umbrales para determinar el intervalo en el que cae. A su vez, esto define el estado de prioridad de la métrica de bits (relleno) . La operación anterior utiliza M umbrales de prioridad y M+l estados de prioridad para cada flujo. El valor de M se fija en 2 en una modalidad la cual es una ejecución de software de un programador. Para cada flujo, se definen dos umbrales de prioridad y tres estados de prioridad. Estos umbrales de prioridad y estados de prioridad típicamente pueden permanecer sin cambios durante el tiempo de vida del flujo, aunque cada uno se puede cambiar durante la operación a través de un comando DSP_Accionador apropiado. Para flujos de tráfico sensible al rendimiento, la métrica de bits se establece para: ___ FactorGoS • Factor BMConvRetrasoRendimientol max(e, R endimientoPromedio — R endimientoObjetivó) y la métrica de relleno de bits se establece para: FactorGoS • FactorBSMConvRetrasoR endimientol max(e, R endimientoPromedio — R endimientoObj etivo) 1. - El FactorGoS es un parámetro definido basado en por-flujo que se utiliza para proveer varios niveles de grado de servicio a través de los flujos. 2.- El RendimientoPromedio es el rendimiento total filtrado (promediado) del flujo, incluyendo las colas FTx, RTx y DARQ del flujo. Un filtro de Respuesta de Impulso Infinito de primer orden (IIR) con una constante de tiempo, por ejemplo, 600 ranuras (1 segundo) , se utiliza para ponderación. 3.- El RendimientoObj etivo es un parámetro definido por-flujo-basado. 4.- El FactorBMConvRetrasoRendimiento2 es un parámetro definido por-flujo-basado. 5.- El FactorBSMConvRetrasoRendimiento2 es un parámetro definido por-flujo-basado. 6.- e representa un número positivo muy pequeño. Para la métrica de relleno de bits de los flujos sensibles al retraso, el coeficiente de polinomio para el estado de prioridad se establece de la siguiente manera: DSBSM = Factor de Aceleración * Retraso Actual + Compensación de Aceleración en donde el Factor de Aceleración es un parámetro definido por-flujo. El Factor de Aceleración normaliza el Límite de Retraso que puede ser diferente para diferentes flujos.

Como un ejemplo, considerar dos juegos en línea diferentes. Debido a las diferentes características de las dos aplicaciones, éstos pueden tener diferentes configuraciones de Límite de Retraso especificadas para el programador; sin embargo, un juego no necesariamente tiene una prioridad superior que la otra aplicación. Puede ser deseable que el programador trate ambas aplicaciones con igual prioridad. Asumir que el primer juego tiene 300 ms de límite de retraso y el segundo juego tiene 150 ms . Entonces, en cualquier momento no habrá octetos, que pertenezcan al segundo juego, más antiguos que 150 ms, ya que el programador los descarta. Sin embargo, pueden ser octetos que pertenezcan al primer juego, los cuales pueden ser más antiguos que 150 ms . Sin el Factor de Aceleración, esto resultaría en octetos de la prioridad de ganancia del primer juego sobre octetos del segundo juego. Al establecer el Factor de Aceleración de cada aplicación inversamente proporcional a las configuraciones de Límite de Retraso respectivas, el programador puede normalizar este efecto indeseado. La Compensación de Aceleración es un parámetro definido por-flujo-basado. El valor de Compensación de Aceleración se puede establecer a un múltiplo entero del valor más grande que puede tomar el Factor de Aceleración. Este valor más grande es independiente de los flujos y se puede determinar a través de la ejecución de software. Como un ejemplo, entre dos flujos, uno con una Compensación de Aceleración de cero y el otro con una Compensación de Aceleración positiva, los octetos del último flujo se incluirán en cualquier caso de transmisión candidato antes que cualesquiera octetos del flujo anterior, asumiendo que ambos flujos son DRC compatibles con el formato de transmisión del caso candidato determinado Para la métrica de bits, el coeficiente de polinomio para el estado de prioridad se establece a un valor constante de la siguiente forma: DSBM = ValorMétricaBi tsDS en donde el Valor de Métrica de Bits DS es un parámetro-definido por flujo gue se utiliza para prioritización suave. Adicionalmente, cuando dos aplicaciones tienen aproximadamente igual prioridad, pero diferente rendimiento de entrada promedio (por ejemplo, de Internet a la cola), el Valor de Métrica de Bits DS para cada flujo se puede establecer inversamente con respecto al rendimiento típico del flujo para evitar la aplicación con la prioridad de ganancia de rendimiento superior simplemente teniendo más datos para llenar, de manera eficiente los paquetes FL. Cada flujo de tráfico se clasifica en clase sensible al rendimiento o clase sensible al retraso con base en el parámetro de Clase de Flujo. La métrica de bits MCX (en donde X es un elemento de {0,...7} queda definida de la siguiente forma: si ClaseFlujo = SensibleAlRendimiento si ClaseFlujo = Sensible AlRett -aso De manera similar, la métrica de relleno de bits se define como: {T r,<,u , si ClaseFlujo = SensibleAlRendimiento MCX = \ BSM \ SBSM , si ClaseFlujo = SensibleÁlRetraso En una modalidad, el programador se ejecuta por lo menos parcialmente como una ejecución de software. De acuerdo con esta modalidad, las métricas de relleno de bits son representadas por cantidades de 16 bits las cuales pueden ser denotadas como [B15...B0] . Los tres bits más significativos determinan el estado de prioridad (por ejemplo, "000" traza para MCO y "111" traza para MC7) . Los restantes 13 bits menos significativos mantienen el valor de coeficiente en sí. Con esta representación, las operaciones de comparación entre las métricas de relleno de bits se pueden ejecutar directamente entre estas cantidades de 16 bits.

Las métricas de bit no quedan explícitamente representadas en la ejecución de software, ya que la información puede ser derivada de la métrica de relleno de bits. El estado de prioridad de una métrica de bits es la misma que aquella de la métrica de relleno de bits. La métrica de paquete de un caso de transmisión candidato se calcula a través de la aplicación de: n Métrica de Paquete[k] = Métrica de Bits¡i] x u Lapso[k] ,^k] como se describió anteriormente. Se puede apreciar que, incluso cuando solo un término de la métrica de bits de un octeto puede ser no cero, en general, los coeficientes de 15 la métrica de paquete resultante pueden ser no cero. Muchos DRC son compatibles con formatos de usuario sencillo no canónicos con tamaños de carga útil más pequeños, por lo tanto no es deseable convertir los candidatos de usuario sencillo en formatos de múltiples 20 usuarios para lograr ganancias ARQ. Si el caso de transmisión candidato decisivo en el paso de selección del programador es de formato de múltiples usuarios, solo la conversión del formato (1024,4,256) a cualquiera de los tres formatos 25 ( {128, 256, 512} , 4, 256) es soportada en la presente modalidad (es decir, se utiliza el formato de velocidad inferior que puede portar los octetos de datos seleccionados) . En análisis de bit y métricas de relleno de bits anteriormente proporcionado considera el caso general en donde a cada octeto en cada cola se le asigna una métrica individual. La métrica es entonces recalculada cada ranura. Modalidades alternas reducen la complejidad de dichos cálculos. Asumiendo que las colas están ordenadas por sello de fecha y hora, una modalidad calcula una métrica de bits (relleno) por flujo con base en el sello de fecha y hora más antiguo entre los octetos que encabezan la cola de las colas del flujo. Esta métrica se puede entonces utilizar para octetos actualmente pendientes del flujo. Dicha simplificación asume que la métrica es una función monotónicamente en aumento del Retraso Actual de un octeto. De otra forma, existe un riesgo de que el octeto que encabeza la cola pueda evitar que octetos consecutivos reciban servicio. Con esta simplificación, la métrica de relleno de bits también se puede denominar como una métrica de flujo. Además, cualquier octeto que encabeza la cola pendiente en la cola RTx de un flujo tiene probabilidades se ser más antiguo que cualesquiera octetos que encabecen la cola que pudieran estar pendientes en las colas FTx y DARQ. De manera similar, cualquier octeto que encabeza la cola que pueda estar pendiente en la cola DARQ, tiene probabilidades de ser más antiguo que el octeto que encabeza la cola de la cola FTx. Por este motivo, en lugar de encontrar el sello de fecha y hora más antiguo entre estas tres colas, una modalidad utiliza un orden fijo de cola RTx, DARQ, y después FTx para encontrar la primera cola no vacía a fin de determinar el sello de hora y fecha que se va a utilizar en el cálculo de la métrica para el flujo. Las colas del flujo también pueden recibir servicio en el orden de RTx, DARQ y después FTx. De acuerdo con una modalidad, la programación tal como se ilustra en la figura 10, se ejecuta siempre que FL está disponible para una nueva transmisión. Se puede observar que, ejecuciones específicas pueden ejecutar algunos o todos los cálculos en cada ranura, incluyendo ranuras no disponibles. Esto se debe a que, en el momento en que la red de acceso determina que el FL está disponible para una nueva transmisión, por lo regular no hay mucho tiempo libre para realizar los cálculos involucrados ene. Método de programación para determinar un caso de transmisión. El método de programador que se ilustra en la figura 10 consta de los cuatro pasos básicos: 1) generación de un conjunto de casos de transmisión candidato; 2) selección de un candidato entre el conjunto; 3) maximización de la eficiencia de empaque; y 4) a priori o cálculo PACK. El cálculo de PACK determina una probabilidad que tiene una AT de decodificar exitosamente un paquete. Refiriéndose nuevamente a la figura 10, en el paso 504 el programador genera una lista de casos de transmisión candidato. Un caso de transmisión candidato de un solo usuario con un formato de un solo usuario corresponde a cada usuario disponible, en donde un usuario disponible es uno que actualmente no tiene prohibido el servicio por parte del sub-tipo de protocolo por motivo alguno. Además, el DRC recibido desde el usuario va a ser no NULO, de otra forma, el usuario habrá negociado un protocolo de capa MAC que permita a uno o más formatos de transmisión recibir servicio en DRC NULO. Si se crea un caso de transmisión candidato para un usuario del cual se ha recibido un DRC NULO, al caso candidato solo se le permite portar datos que pertenecen a un flujo con un Límite de Retraso finito y solo des la cola FTx del flujo. El formato de transmisión del caso candidato es el formato canónico correspondiente al DRC de usuario, como se destalló en el cuadro 1. Un caso de transmisión de múltiples usuarios candidato es generado para cada uno de los cinco formatos de transmisión de múltiples usuarios: (1024,4,256), (2048,4,128), (3072,2,64), (4096,2,64) y (5120,2,64).

Aquellos usuarios que han solicitado 153.6 Kbps o más, reciben servicio en formatos de múltiples usuarios. Además, el DRC de un usuario va a ser compatible con el formato del caso de transmisión candidato. Además, un caso de transmisión candidato de múltiples usuarios va a satisfacer una o ambas de las siguientes condiciones, o de otra forma, se descarta de consideración adicional; éste portará los datos de dos o más usuarios, o por lo menos los datos de un usuario cuyo DRC se borró. Un caso de transmisión candidato en cualquiera de los grupos es generado rellenando bits provenientes de uno o más flujos, en donde 1) formatos de un solo usuario solo pueden ser rellenados con bits provenientes de flujos del mismo usuario; 2) formatos de múltiples usuarios son rellenados con bits provenientes de los flujos de usuarios con DRC compatibles . El relleno de bits se realiza en orden descendente de métricas de relleno de bits. Como se mencionó anteriormente, los reguerimientos computacionales pueden resultar en el cómputo de una métrica de relleno de bits por flujo, el cual después se utiliza para octetos actualmente pendientes en colas del flujo. En este caso, la métrica de relleno de bits ayuda a determinar cuáles flujos serán servidos primero; sin embargo, no determina cómo serán servidos los octetos de un flujo determinado. Esto asume que los octetos pendientes en las colas de un flujo aparecen en el orden del sello de fecha y hora, y los octetos de un flujo son servidos en el orden que aparecen en las colas. Esto se utiliza para colas FTx, pero no necesariamente para colas RTx/DARQ. Como se mencionó anteriormente, cada flujo puede tener múltiples colas, una cola para los datos transmitidos por primera vez (FTx) , y otras colas para retransmisiones (cola RTx para retransmisiones RLP y/o una cola DARQ para las retransmisiones de capa MAC) . Si un flujo no tiene colas vacías RTx y/o DARQ, la métrica de relleno de bits para el flujo se calcula con base en los sellos de fecha y hora más antiguos de los sellos de fecha y hora que encabezan la cola entre cualesquiera colas no vacías FTx/RTx/DARQ. Solo se calcula una métrica de relleno de bits para colas de un flujo. El relleno de bits, a partir de un flujo determinado, también debería ser ejecutado con base en el orden ascendente de los sellos de fecha y hora que encabezan la cola entre las colas FTx/RTx/DARQ. El orden basado en el sello de fecha y hora de las colas de un flujo, puede ser aproximado a un orden fijo de colas RTx/DARQ/FTx. Se puede apreciar que, al generar casos de transmisión candidato, no se consideran los formatos de usuario sencillo no canónicos y los formatos cortos de múltiples usuarios que portan menos de 1024 bits. Estos formatos serán considerados en el paso de maximización de eficiencia de empaque. El método de programación busca reducir la complejidad y empacar la mayor cantidad posible de datos por paquete. Para evitar la situación de un usuario que tiene una condición de canal débil pero una cantidad grande de datos para prioridad relativa de ganancia de transmisión rellenando paquetes cortos de manera eficiente. Otro beneficio de no considerar paquetes cortos y no canónicos en esta etapa incluye, pero no se limita a, evitar algunos efectos de cuantificación que pueden surgir en la programación basada en tramas. Al crear candidatos de múltiples usuarios, es posible tomar precauciones adicionales para aligerar los efectos potencialmente adversos del problema de continuación que se analiza más adelante. Dicho método es evitar servir a un paquete de múltiples usuarios en el mismo entrelazado con un paquete de múltiples usuarios previamente iniciado y finalizado para un cierto número de ranuras (por ejemplo, contadas en el entrelazado determinado) después del inicio del primer paquete de múltiples usuarios. Este número de ranuras se puede establecer al mínimo de los lapsos de dos paquetes de múltiples usuarios o posiblemente al lapso del primer paquete de múltiples usuarios. Este enfoque ayuda a permitir a los usuarios a volverse aptos rápidamente para recibir servicio en un nuevo paquete de múltiples usuarios, evitando así largas carreras de inelegibilidad. Con respecto al paso 508, después que se crea la lista de casos de transmisión candidato de usuario sencillo y múltiples usuarios, el programador selecciona uno de estos candidatos (asumiendo que la lista antes generada contiene por lo menos un caso de transmisión candidato) . Esto se realiza calculando la métrica de paquete para cada uno de los candidatos en la lista, y seleccionando el candidato con la métrica de paquete más grande como el candidato decisivo. Si ocurren empates, es deseable preferir los formatos de usuario sencillo sobre formatos de múltiples usuarios. También, es deseable elegir formatos de múltiples usuarios con velocidad superior sobre formatos de múltiples usuarios de velocidad inferior. En el paso 510, el formato de transmisión del caso de transmisión candidato decisivo es reconsiderado y puede ser modificado para elevar al máximo su eficiencia de empaque sin cambiar el conjunto de octetos de datos seleccionados para ser portados por éste. La finalización del paso 510 puede proveer ganancias ARQ. Si el caso de transmisión de candidato decisivo es de formato de un solo usuario, entonces el formato puede ser convertido al formato de usuario sencillo no canónico de velocidad más baja que sea compatible con el DRC del usuario servido, el cual puede portar los octetos de datos seleccionados. Otras modalidades también pueden cambiar el formato de caso de transmisión de un solo usuario a formato de múltiples usuarios . El mecanismo de control de velocidad adaptivo dentro de la AT probablemente esté adaptado para soportar paquetes de usuario sencillo. Muchos DRC son compatibles con formatos de usuario sencillo no canónicos con tamaños de carga útil más pequeñas; por lo tanto, no es deseable convertir los candidatos de usuario sencillo en formatos de múltiples usuarios para lograr ganancias ARQ. Aunque los formatos de múltiples usuarios se pueden convertir a cualquiera de los formatos de múltiples usuarios de velocidad más baja (siempre y cuando se ajuste la carga útil) , es aconsejable evitar dichas conversiones de formato de esparcimiento amplio debido a los efectos potencialmente adversos del problema que a continuación se menciona. Refiriéndose a la figura 12, el programador puede determinar un número máximo de ranuras (por ejemplo, menos del lapso nominal del caso de transmisión seleccionado) más allá del cual éste no transmitirá el caso de transmisión incluso cuando puede no detectar ACK de los usuarios servidos en el caso de transmisión. Debido a que este paso es opcional, éste se puede apagar de manera que la red de acceso finalice la transmisión de paquetes después de detectar un ACK de usuarios servidos en el paquete, o después de transmitir el lapso completo del paquete. Un método para ejecutar este paso es establecer el número máximo de ranuras del caso de transmisión para: -LapsoMáx±ms^min (LapsoFormatoTXProgramado,maXieusuaxiosservidos (LapsoDRC[i] ) ) en donde LapsoFormatoTXProgramado es el lapso del formato de transmisión programado y LapsoDRC[i] es el lapso del formato de transmisión canónico correspondiente al DRC decodificado del iavo usuario servido en el paquete. Varios de los parámetros utilizados por el programador han sido analizados anteriormente. Aquí se muestran los parámetros provistos al programador en la Interfaz DSP-Accionador . Los parámetros globales se refieren a aquellos parámetros que aplican a todos los flujos, y los parámetros de Flujo se refieren a aquellos parámetros especificados para cada flujo por separado: 1.- Parámetros Globales: a. FlowTPutFilterTimeConst- define la constante de tiempo del filtro IIR de primer orden que se utiliza para generar el rendimiento promedio, AvgThroughput, variable gue se mantiene para cada flujo. El filtro es repetido una vez cada ranura. La entrada al filtro es el número de octetos servidos desde las colas del flujo determinado en un paquete que inicia en esa ranura. El filtro es actualizado con entrada cero en ranuras en donde no empieza ningún nuevo paquete de transmisión. b. Thrghpt2DelayConvFactorBM - factor de conversión para métrica sensible al rendimiento para métrica sensible al retraso para el cálculo de la métrica de bits. c. Thrghpt2DelayConvFactorBSM - factor de conversión para métrica sensible al rendimiento para métrica sensible al retraso para el cálculo de la métrica de relleno de bits. d. FlowClass - describe si el flujo es de tipo sensible al rendimiento o del tipo sensible al retraso. e. FlowEligibleForDRCErasureMapping - a ser utilizado por el algoritmo de mapeo de borrado DRC. f. ErasureMapDelayThreshold - a ser utilizado por el algoritmo de mapeo de borrado DRC. 2.- Parámetros de flujo a. Userld, Flowld - provee un medio para indexar y determinar el propietario de cada flujo. b. QoSMetricState, PriorityThol [2] - estos describen el estado de prioridad de la métrica de bits (relleno) como una función del retraso actual. Los elementos de la disposición PriorityThold [ ] son estructuras que contienen las variables DelayThold y QoSMetricState. Cuando CurrentDelay de un flujo es menor que PriorityThold [0] . DelayThold, el estado de prioridad se establece a QoSMetricState. Si CurrentDelay es mayor que PriorityThold [0] . DelayThold, pero menor que PriorityThold [1] . DelayThold, entonces el estado de prioridad se establece en PriorityThold [0] .QoSMetricState. Si CurrentDelay es mayor que PriorityThold [1] . DelayThold, entonces el estado de prioridad se establece igual a PriorityThold [1] .QoSMetricState. Las variables de QoSMetricState toman los valores {0, ...,7} correspondientes a los estados de prioridad de {MCO, ...,MC7} respectivamente. c. AccelerationFactor d. AccelerationOffset e. DelayBound - 0 representa infinito, (es decir, nunca descarta un octeto antes de darle servicio) : de lo contrario, representa la cantidad de retraso, con relación al sello de fecha y hora de un octeto determinado, después de lo cual el octeto es descartado de una cola. f. TargetThroughput - Un parámetro utilizado en la métrica de bits (relleno) de flujos sensibles al rendimiento; g. FlowAggregatelndex - flujos con FlowAggregatelndex establecidos en 0 no son agregados por el programador. De lo contrario, los flujos con el mismo valor (no cero) de FlowAggregatelndex se agregan en el programador. El alcance de FlowAggregatelndex se limita a un usuario, es decir, el mismo índice se puede volver a utilizar para flujos de otro usuario sin confusión. h. IntraFlowPriority - flujos de contribución en un flujo agregado (por el programador) reciben servicio en el orden de IntraFlowPriority . Entre los flujos de contribución con el mismo IntraFlowPriority, el orden gueda determinado por el sello de fecha y hora del flujo de contribución . i. GoSFactor - se utiliza para proporcionar niveles de grado de servicio entre flujos. j . DSBitMetricValue - valor del coeficiente de métrica de bits en estados de prioridad en MCX. Se puede apreciar que, en la interfaz DSP-Accionador, los flujos no están especificados como BE, AF, EF, o por cualquier otro descriptor de alto nivel. Más bien, la interfaz DSP-Accionador utiliza una descripción uniforme de bajo nivel para todos los flujos. A un nivel superior, tal como en el BSC, descriptores de alto nivel específico de flujos, tal como requerimientos QoS y categorizaciones BE/EF/AF, se van a trazar para los parámetros básicos definidos en la interfaz DSP-Accionador para cada flujo. Dichos cuadros de trazado son generados para tipos de flujo concebibles por simulación y prueba suficiente . Los siguientes so ejemplos que ilustran el uso de varios parámetros. Para flujos BE, se pueden utilizar los siguientes parámetros : a. QoSMetricState = 0 (MCO) b. PriorityThold [] .QoSMetricState = {cualquiera, cualquiera} c. PriorityThold [] .DelayThold = {0,0} (infinito) d. DelayBound = 0 (infinito) e. TargetThroughput = 0 f. FlowAggregatelndex = 1 (agregar todos los flujos BE de un usuario) . g. Thrghpt2DelayConvFactorBM = 16 h. Thrghpt2DelayConvFactorBSM = 128 i. FlowClass = ThrputSensitive j . FlowEligibleForDRCErasureMapping = 0 k. ErasureMapDelayThreshold = 0 {infinito} Para flujos AF, se pueden utilizar los siguientes parámetros : a. QoSMetricState = 0 (MCO) b. PriorityThold [] .QosMetricState = {cualquiera, cualquiera} c. PriorityThold [] .DelayThold = {0,0} (infinito) d. DelayBound = 0 (infinito) e. TargetThroughput = Un valor positivo f . FlowAggregatelndex = 0 (sin agregado) . g. Thrghpt2DelayConvFactorBM = 16 h. Thrghpt2DelayConvFactorBSM = 128 i. FlowClass = ThrputSensitive j . FlowEligibleForDRCErasureMapping = 0 k. ErasureMapDelayThreshold = 0 {infinito} Para flujos EF, se pueden utilizar los siguientes parámetros: a. QoSMetricState = 0 (MCO) b. PriorityThold [] .QoSMetricState = {2,3} c. PriorityThold [] .DelayThold = { 0.25*DelayBound, 0.5*DelayBound} d. DelayBound = depende de la Aplicación e. TargetThroughput = 0 f . FlowAggregatelndex = 0 (sin agregado) . g. Thrghpt2DelayConvFactorBM = 1 h. Thrghpt2DelayConvFactorBSM = 1 i. FlowClass = DelaySensitive j . FlowEligibleForDRCErasureMapping = 1 k. ErasureMapDelayThreshold = 0.25*DelayBound Un flujo de señalización se provee de la siguiente forma: a. QoSMetrícState = 7 (MC7, prioridad superior) b. PriorityThold [] .QoSMetricState = {7,7} c. PriorityThold [] .DelayThold = {0,0} (infinito) d. DelayBound = 0 (infinito) e . TargetThroughput = 0 f . Aggregatelndex = 0 (sin agregado) . g. Thrghpt2DelayConvFactorBM = 1 h. Thrghpt2DelayConvFactorBSM = 1 i. FlowClass = DelaySensitive j . FlowEligibleForDRCErasureMapping = 1 k. ErasureMapDelayThreshold = 0.25*DelayBound Los flujos BE/AF se pueden prioritizar utilizando una combinación apropiada de los siguientes parámetros: 1. Estados MC0,...MC7 permiten la prioritización estricta. 2. GoSFactor para prioritización suave. 3. TargetThroughput típicamente, para flujos AF que requieren cierto rendimiento mínimo. Los flujos EF se pueden prioritizar adicionalmente utilizando una combinación apropiada de los siguientes parámetros: 1. Estados MC0,...MC7 permiten la prioritización estricta. 2. AccelerationOffset provee prioritización durante el rellenado con bits entre octetos del mismo estado de prioridad, pero no afecta directamente la selección de paquete final (debido a que este último paso utiliza métricas de bit para calcular la métrica de paquete, lo cual no depende de AccelerationOffset) . Cuando dos flujos que pertenecen al mismo usuario o dos usuarios diferentes están compitiendo para ser incluidos en el mismo caso de transmisión candidato, el flujo con el AccelerationOffset más grande recibe la prioridad. 3. DSBitMetricValue afecta las métricas de bits de manera que tiene un efecto directo en la métrica de paquete. Este parámetro también se puede utilizar para prioritización suave. Actualmente, este parámetro no se ejecuta. La interfaz DSP-Accionador provee un método flexible para agregar flujos en el programador. Se puede apreciar que los agregados realizados por el programador son diferentes de los agregados que pueden ser realizados por el BSC. Cuando el BSC agrega un conjunto de flujos, este agregado aparece como un solo flujo para el programador, y el programador recibe un solo conjunto de parámetros para el flujo. El programador no puede diferenciar los flujos de contribución. Cuando se realiza la agregación en el programador, el programador naturalmente conocerá los flujos de contribución. La variable AvgThroughput incluye el rendimiento total del agregado. Algunos parámetros, tal como DelayBound, especificados para los flujos de contribución de un agregado se establecen al mismo valor en la interfaz DSP-Accionador. La lista de variables que se va a establecer igual para todos los flujos de contribución son: a. UserID b. Aggregatelndex c. QoSMetricState d. PriorityThold [2] e. AccelerationFactor f. AccelerationOffset g. DelayBound h. TargetThroughput i. GoSFactor j . DSBitMetricValue Un parámetro que puede ser establecido de manera diferente es IntraFlowPriority y un parámetro que se va a establecer de manera diferente es FlowID. En una modalidad, a un flujo agregado se le asigna una métrica de un solo bit- (relleno) . Esta métrica se basa en el sello de fecha y hora más antiguo entre los flujos de contribución de un flujo agregado. El sello de fecha y hora de un flujo de contribución se calcula con base en los sellos de fecha y hora que encabezan la cola de sus colas FTx/RTx/DARQ. Sin embargo, cuando se selecciona un flujo para relleno de bits, el orden en el que los flujos de contribución son servidos queda determinado principalmente por los parámetros IntraFlowPriority asignados a cada uno de los flujos de contribución, y en segundo lugar por los sellos de fecha y hora de los flujos de contribución. Al establecer los parámetros IntraFlowPriority al mismo nivel, el orden de selección de los flujos de contribución puede estar basado estrictamente en sus sellos de fecha y hora. El parámetro IntraFlowPriority la mayoría de las veces está destinado a flujos BE.

Como se analizó anteriormente, cada flujo tiene una cola FTx, y puede tener colas RTx y/o DARQ. En la ejecución de software, una métrica de relleno de un solo bit se calcula para cada flujo. Esta métrica aplica a octetos en la cola FTx, así como octetos en las colas RTx y DARQ. Si un flujo es seleccionado para ser servido, colas individuales también son servidas en el orden determinado. Una modalidad de software provee la capacidad para aumentar la prioridad de un flujo si las colas RTx y/o DARQ no están vacías. Esto se logra simplemente modificando el valor de MetricaTS proporcionado en la Ecuación (3.3-2) como: . ,, . FactorGoS * FactorPrioridadRetransmisi?n Métrica^ = - max(£-, RendimientoPromedio - RendimientoObj etivo) El factor RetransmissionPriorityFactor asume el valor de 1 si ambas colas RTx y DARQ están vacías. Este asume otro valor si la cola RTx está vacía pero la cola DARQ contiene datos. Y, otro valor si la cola RTx no está vacía. En la Revisión A de la especificación lxEV-DO, algunos sub-tipos de protocolo definen DRC NULO como compatible con un conjunto de formatos de transmisión de un solo usuario y múltiples usuarios. También, en Rel-0 de la especificación, los atributos de configuración se definen para ciertos sub-tipos de protocolo que permiten a la red de acceso proveer servicio a un usuario desde el cual se recibió un DRC NULO con un formato de transmisión de un solo usuario (1024,16,1024). En cualquier caso, el programador puede crear un caso de transmisión candidato que contiene datos para un usuario desde el cual se recibió un DRC NULO. Esto se denomina como una conversión NULO-a-Velocidad. El programador impone las siguientes restricciones sobre las conversiones NULO-a-Velocidad: a. Permitidas para servir a flujos con DelayBound finito. b. Las colas RTx/DARQ no pueden ser servidas. Restricciones diferentes a estas, el programador no distingue si el DRC recibido del usuario fue 0x0 (es decir, DRC NULO), ó Oxl (es decir, 38.4 Kbps), ambos están definidos para ser compatibles con los mismos formatos de transmisión en algunos sub-tipos de protocolo en Rev-A. Nuevamente, se hace referencia al Cuadro 1 para definiciones de sub-tipo de protocolo específico. Cuando un DRC NULO es recibido desde un usuario, no existe garantía de que el paquete servido será decodificado exitosamente por el usuario. Una mejora futura puede involucrar el monítoreo para saber si los usuarios que han enviado un DRC NULO y quienes después fueron servidos en un paquete están decodificando de manera razonable y exitosa. Dependiendo de las estadísticas de éxito, la conversión puede encender/apagar el flujo. Una modalidad clasifica los casos de transmisión candidato creados para usuarios que enviaron un DRC NULO por debajo de los casos de transmisión candidato creados para usuarios que enviaron DRC de 0x1. Se pueden realizar algunas aproximaciones razonables en una ejecución de software para facilitar la creación de los casos candidato de múltiples usuarios que contienen datos para flujos sensibles al rendimiento. Con respecto a la temporización del programador, la línea de tiempo dentro de una ranura es dividida entre dos partes; la primer parte es el segmento no crítico, y la última parte es el segmento crítico. Los valores DRC de los usuarios se vuelven disponibles durante el segmento crítico. Sin embargo, el segmento crítico puede no proveer suficientes ciclos de procesador para llevar a cabo los cálculos involucrados en el programador bajo carga en peor condición. Por lo tanto, algunos de estos cálculos se van a delegar al segmento no crítico. Debido a que los valores DRC de algunos usuarios pueden no ser conocidos durante el segmento no crítico, la ejecución de software utiliza los valores DRC de la ranura previa para construir casos de transmisión candidato y seleccionar al candidato decisivo. Es posible que los valores DRC de algunos usuarios puedan cambiar, y el candidato decisivo puede volverse inválido durante el segmento crítico. Para superar este problema, más de un candidato fuerte es seleccionado durante el segmento no crítico. Cuando los valores DRC reales son recibidos en el segmento crítico, este conjunto reducido de candidatos son reevaluados. El conjunto reducido de casos candidato puede contener: a. Un número pequeño (por ejemplo, cinco) de candidatos de usuario sencillo. b. Un candidato de múltiples usuarios (si hay alguno creado) con unos cuantos usuarios libres que pueden ser servidos en ese candidato, si algunos de los usuarios servidos en el candidato se vuelven incompatibles. En lxEV-DO Reí. 0, una AN no programa paquetes para una AT cuando se borra la información del DRC. Cuando una AN está dando servicio a múltiples AT con aplicaciones no sensibles al retraso, por ejemplo, tráfico de mejor esfuerzo, se pueden tolerar velocidades de borrado DRC relativamente grandes (por ejemplo, cuando es a causa de diversidad de múltiples usuarios) sin pérdida de la capacidad del sistema. Cuando la velocidad de borrado DRC es excesivamente alta, el bit de blogueo DRC sería establecido a cero por la AN, y después la AT puede elegir entre transferir a otro sector o cambiar a un modo de velocidad fija. Sin embargo, el método de generación de bits de bloqueo DRC tiene un retraso acumulado, el cual es por lo menos parcialmente causado por la filtración, para evitar transferencias innecesarias. Por lo tanto, longitudes recorridas relativamente largas de borrados DRC pueden seguir ocurriendo en el enlace inverso. Para aplicaciones sensibles al retraso, por ejemplo, tráfico EF, estos borrados pueden dar como resultado cantidades inaceptables de corte de servicio. Un algoritmo de trazado de borrado DRC busca reducir al mínimo los cortes de servicio en el FL. El algoritmo de línea base se describe en dos pasos. El primer paso explica la decisión en el trazado de borrado DRC. El segundo paso describe la modificación al programador FL de lxEV-DO Revisión A. La figura 14 describe el algoritmo de trazado de borrado DRC ejecutado por la AN en cada intervalo de ranura de tiempo para cada AT que está en modo de velocidad variable. Para cada AT, el algoritmo se corre en cada sector de una célula, la cual tiene una cola activa, establecida por el BSC, para ese usuario. Para simplicidad, el algoritmo es descrito para correr en cada intervalo de ranura, pero los parámetros serían actualizados únicamente en cada intervalo DRC_Longitud. La salida principal del algoritmo es el Borrar_Indicador_Trazado, el cual indica al programador gue el trazado de borrado del DRC es ejecutado, y que programación del FL limitada puede ser ejecutada para la AT. Almacenar_Indice_DRC se utiliza para almacenar el último índice válido, es decir, índice DRC exitosamente decodificado. Conteo_Borrado se utiliza para calcular la longitud recorrida de borrados DRC. El trazado de borrado DRC se realiza únicamente si la longitud de recorrido de borrado es mayor que Máxima__Longitud_Borrado . Este umbral asegura que el trazado de borrado DRC es ejecutado únicamente cuando la probabilidad del corte de servicio es relativamente alta. Sin embargo, los paquetes pueden ser programados a una AT cuando el retraso de paquete FL correspondiente es alto. Por lo tanto, Máxima_Longitud Borrado puede no ser demasiado alto. Para flujos EF, por ejemplo, configuraciones razonables para Máxima_Longitud_Borrado pueden estar en el rango de 0 a 16 ranuras . Como se ilustró en la figura 14, el método 700 primero revisa si el DRC es borrado en el diamante de decisión 702. Si el DRC es borrado, el Conteo_Borrado se incrementa en el paso 704. El Conteo_Borrado es entonces comparado con un valor máximo, Máxima_Longitud_Borrado en el paso 706. Si Conteo_Borrado es mayor que Máxima_Longitud_Borrado, el Borrar_Indicador_Trazado se establece en 1; además, el Borrar_Indicador_Trazado es despejado, es decir, se establece en 0 en el paso 712. Si el DRC no es borrado en el diamante de decisión 702, el Borrar_Indicador_Trazado se configura en 0, el Conteo_Borrado se configura en 0, y Almacenar_Indice_DRC se configura al Indice_DRC en el paso 708. El procesamiento continúa con el paso 712, en donde el Borrar_Indicador_Trazado se establece en 0. Los programadores FL descritos anteriormente se pueden modificar para funcionar con el algoritmo de trazado de borrado DRC. Para cada flujo de datos distinto de cada AT, el flujo es idóneo para programación FL limitada si: (Borrar IndicadorTrazado == 1 && FlujoIdoneoParaTrazadoBorradoDRC==l && RetrasoDeEncabezadoDeColaXBorrarUmbralRetrasoTrazado) en donde FlujoldoneoParaTrazadoBorradoDRC es un parámetro que indica la idoneidad de cada flujo de tráfico para trazado de borrado DRC. Por omisión, se asume que los flujos EF son idóneos para trazado mientras que los flujos BE y AF no lo son. RetrasoDeEncabezadoDeCola indica el valor de "Retraso_Actual" para el paquete en el frente de la cola FL (es decir, paquete más antiguo en la cola FTx, RTx ó DARQ) . BorrarUmbralRetrasoTrazado es el retraso mínimo requerido para el flujo particular a fin de borrar el trazado (tiene un efecto similar que "PriorityThold [i] . DelayHold" . Si un flujo es idóneo para programación FL limitada, se realizan las siguientes modificaciones en el programador de FL: a. El flujo no es idóneo como candidato para el caso de transmisión de usuario sencillo. b. El flujo es idóneo para el caso de transmisión de múltiples usuarios con índice DRC solicitado, Indi ce_DRC_T razado . Es posible cambiar dinámicamente el Indice_DRC_Trazado como una función de longitud de borrado. Esto se puede lograr utilizando Almacenar_Indice_DRC y Conteo_Borrado . La configuración por omisión para Indice_DRC se puede mapear a 0x3. Para el programador FL, el índice DRC 0x3 correspondería al formato de transmisión de múltiples usuarios (1024,4,256), lo que posiblemente se puede convertir a formatos ( {128, 256, 512} , 4, 256) . Todos estos formatos de múltiples usuarios son compatibles con todos los índices DRC, de manera que la AT debería poder decodificar el DRC trazado siempre y cuando tenga suficiente SINR (independiente del índice DRC solicitado real) . Algoritmos alternos pueden aplicar un formato más conservador, el cual limite los formatos de transmisión de múltiples usuarios disponibles a velocidades de datos inferiores conforme aumenta Conteo_Borrado . Se puede apreciar que, la opción DARQ se puede encender para VolP. Por lo tanto, en caso que una AT no haya decodificado el paquete transmitido de múltiples usuarios en el primer intento de transmisión, DARQ provee la posibilidad de un segundo intento de transmisión y reduce la velocidad de error de paquete residual. Sin embargo, el rendimiento DARQ está vinculado al rendimiento de canal ACK el cual puede no ser muy confiable cuando DRC esté en borrado. El umbral de decisión ACK/NAK se puede optimizar para DARQ, posiblemente dependiendo del índice DRC o estado de trazado de DRC. Otra modalidad hace un intento de transmisión DARQ compatible con formatos de paquete de múltiples usuarios de baja velocidad únicamente, por ejemplo, (512,4,1024) ó (256,4,1024), en el caso de trazado de borrado DRC. Modalidades alternas pueden proveer pasos y medios adicionales al programador aguí presentado. Por ejemplo, los flujos BE/AF típicamente utilizarían los estados de prioridad, los cuales estrictamente tienen prioridad inferior que los estados de prioridad. Esto puede producir como resultado una degradación del rendimiento BE/AF en la presencia de usuarios EF, los cuales con mayor probabilidad utilizarían los estados de prioridad superior. El rendimiento BE/AF puede ser estimulado aumentando la prioridad de los flujos BE/AF a estados superiores bajo ciertas condiciones. De acuerdo con una modalidad, la VelocidadSolictadaPromedio es la velocidad solicitada filtrada de un usuario, en donde los usuarios K están configurados como usuarios BE en el sistema. Si el rendimiento de un usuario para sus flujos BE, RendimientoPromedio satisface: RendimientoPromedio<~ a VelocidadSolic?tadaPromed?o k entonces el estado de prioridad del usuario para sus flujos BE puede ser estimulado a estados de prioridad superior. El valor de a. se puede elegir dependiendo de la carga EF del sistema, a más pequeño para carga superior. Además, se pueden imponer requerimientos mínimos de velocidad solicitada en los usuarios para esta promoción. Son posibles otros métodos para mejorar la capacidad BE/AF. El método anterior también sugiere que el estado de prioridad de una métrica de bits (relleno) de un flujo puede no solo ser una función de retraso de encabezado-de-la-cola, sino que también puede ser una función del rendimiento del flujo. Se puede apreciar que, en estados sensibles al retraso, la métrica de relleno de bits es estrictamente una función de retraso, y no tiene un mecanismo para sacar ventaja de los picos de canal local de un usuario. Aquí, el valor de métrica de relleno de bits en los estados sensibles al retraso se puede modificar para leerse: MBSDS=Factor Aceleración * [RetrasoActual+kCCI] + CompensaciónAceleración en donde el Indicador de Condición de Canal (CCI) asume los valores del conjunto {0,1} o el intervalo [0,1], los cuales pueden ser generados por separado, de manera que, cuando asume valores superiores, éste indica condiciones de canal relativamente buenas en comparación con la condición de canal a largo plaza del usuario. También, k es el factor de conversión de CCI-a-Retraso. Este indica cuánto estímulo, en términos de retraso, el flujo obtendrá cuando la condición del canal del usuario sea buena con relación a sus propias estadísticas de canal. Un método simple para generar CCI para el caso binario {0,1} es proporcionado de la siguiente forma. Suponiendo gue índice de Velocidad sea un entero asignado a los valores DRC en orden de velocidad creciente, en donde el valor DRC no se utiliza debido a que no aumenta de manera monotónica con la velocidad de datos. Suponiendo que índice de Velocidad Promedio sea el índice de Velocidad (filtrado) promedio de un usuario. Asumiendo que Umbral de de CCI es un parámetro tal como 1.2. Entonces si índice de Velocidad > Umbral de CCI * índice de Velocidad Promedio, el valor de CCI puede ser establecido para unidad. De otra forma, se establece en cero. En este ejemplo, el CCI indicara una condición de canal relativamente buena si el índice de Velocidad actual correspondiente al DRC recibido es 120% o superior que la calidad promedio. Apoderamiento se refiere a la absorción de una transmisión FL antes que sea decodificada por los usuarios destino. El apoderamiento se puede utilizar si aparecen datos de prioridad muy alta mientras los cuatro entrelazados en el FL son ocupados por usuarios de baja velocidad relativamente. El algoritmo del programador actualmente no provee una forma para apoderarse de transmisiones en curso. Un motivo para esto es que, a menos que los apoderamientos sean cuidadosamente monitoreados, los apoderamientos no controlados pueden conducir a pérdida de capacidad. El enfoque aquí tomado es evitar circunstancias que puedan requerir apoderamiento. Dicha condición es, como se mencionó anteriormente, los cuatro entrelazados ocupados por usuarios de baja velocidad. Para evitar esto, se pueden utilizar métodos simples. Uno de esos métodos es no permitir más de un número fijo de transmisiones simultáneas de formatos con lapsos de 16 ranuras y 8 ranuras. Como un ejemplo, este número se puede establecer en 2 ó 3. Una modalidad monitorea el rendimiento de decodificación de los usuarios que transmiten DRC NULO y son servidos en un paquete. Dependiendo del PER medido en estos casos de NULO-a-velocidad, es posible encender/apagar las conversiones NULO-a-velocidad para cada usuario. De manera similar, también es posible encender/apagar las restricciones al momento de dar servicio a colas RTx/DARQ, así como las colas de flujos con Límite de Retraso infinito en caso de NULO-a-velocidad, si las estadísticas recopiladas indican que la terminal de acceso está decodificando de manera confiable y suficiente estos paquetes . Los coeficientes de bits y métrica de relleno de bits para flujos sensibles al rendimiento proveen imparcialidad proporcional en un sistema BE-únicamente (por ejemplo, RendimientoObjetivo = 0 y FactorGoS = 1 para todos los flujos) en donde los usuarios tienen cantidades grandes de datos para recibir. La forma del coeficiente de métrica se puede aplicar en una forma similar a otros programadores. Para este propósito, el coeficiente de métrica para los flujos sensibles al rendimiento se pueden expresar como: Métricats = - f(RendimientoPromedi?)h(VelocidadSolicitadaPromedi?) en donde f(.) y h(.) son funciones genéricas, y Velocidad de Solicitud Promedio es la velocidad solicitada promedio de un usuario. La configuración f (x) = x y h(x) = x produce un programado GoS aproximadamente igual. El Protocolo MAC de Canal de Tráfico de Avance Mejorado definido en la Revisión A de la especificación IxEV-DO impone una restricción en cuanto al servicio a usuarios después de un paquete de múltiples usuarios, tal como se resume a continuación. La especificación Revisión A estipula que, la Ranura t queda definida para ser una continuación de una ranura previa s, si se cumplen las siguientes condiciones: c. La terminal de acceso es un objetivo potencial de un pagúete cuya transmisión comienza en la ranura s . d. La ranura t está en el mismo entrelazado FL que la ranura s, es decir, t-s = O ( od 4) . e. s<t<s+4N, en donde N denota el Lapso del índice DRC correspondiente al valor DRC que está vigente durante la ranura s . Si la terminal de acceso es un objetivo potencial de un paquete transmitido por un sector que inicia en la ranura s, la terminal de acceso no debería transmitir un nuevo paquete desde la misma fuente de datos FL a la terminal de acceso en ninguna ranura t que sea una continuación de la ranura s. La restricción antes mencionada impone limitaciones sobre las cuales los usuarios pueden recibir servicio después de un paquete de múltiples usuarios. Como un ejemplo, si la red de acceso proporciona servicio a un paquete de múltiples usuarios para un conjunto de usuarios el cual termina de manera temprana, entonces la red de acceso no puede dar servicio a ningún paquete (usuario sencillo o múltiples usuarios) durante la continuación del paquete servido a los usuarios que no fueron servidos en el paquete previo pero que fueron compatibles con su formato. En una situación, la red de acceso proporciona servicio a un paquete de múltiples usuarios de 153.6 Kbps y usuarios con datos portados por éste decodifican el paquete en menos de 4 ranuras. Si la red de acceso proporciona servicio inmediatamente a otro paquete de múltiples usuarios de 153.6 Kbps en el mismo entrelazado, entonces los usuarios que en realidad solicitaron 153.6 Kbps o cualquier DRC con un lapso de 4 ranuras, pero que no fueron servidos en el paquete previo, no se les permitirá recibir servicio en la nueva transmisión. 'Por lo tanto, solo aquellos usuarios quienes solicitaron DRC con lapso menor de 4 ranuras, es decir, típicamente usuarios en mejores condiciones de canal, pueden recibir servicio en la nueva transmisión. Pero esto hace más probable aún que el nuevo paquete se decodifique anticipadamente. Esta cadena puede continuar hasta que las colas de usuarios de geometría superior sean drenadas. Mientras tanto, usuarios de geometría inferior que están solicitando DRC con lapsos de 4 ranuras no recibirán servicio. El resultado sería un excesivo retraso para usuarios de geometría inferior y una ganancia posiblemente pequeña en retraso para usuarios de geometría superior. Se puede apreciar que, las modalidades, aspectos y ejemplos provistos en la descripción anterior se refieren a sistemas que soportan un protocolo de datos en paquete de alta velocidad. Dicho sistema se presenta para claridad y entendimiento de las ideas mostradas . Sistemas alternos pueden ejecutar el método y medio para la gestión y programación de retraso adaptivo aquí presentado. Por lo tanto, se ha descrito un método y aparato novedoso y mejorado para programación de transmisiones en un sistema de comunicaciones. Aquellos expertos en la técnica apreciarán que los datos, instrucciones, comandos, información, señales, bits, símbolos, y chips, a los que se puede hacer referencia en la descripción anterior, están convenientemente representados por voltajes, corrientes, ondas electromagnéticas, campos o partículas magnéticas, campos o partículas ópticas, o cualguier combinación de los mismos. Aquellos expertos en la técnica además apreciarán que los diversos bloques lógicos ilustrativos, módulos, circuitos y pasos de algoritmo descritos en relación con las modalidades aquí descritas se pueden ejecutar como hardware electrónico, software de cómputo, o combinaciones de ambos. Los diversos componentes ilustrativos, bloques, módulos, circuitos y pasos se han descrito de manera general en términos de su funcionalidad. El hecho que la funcionalidad sea ejecutada como hardware o software depende de la aplicación particular y restricciones de diseño impuestas sobre el sistema en general. Los expertos en la técnica reconocen la capacidad de intercambio de hardware y software bajo estas circunstancias, y la mejor forma de ejecutar la funcionalidad descrita para cada aplicación particular. Como ejemplos, los diversos bloques lógicos ilustrativos, módulos, circuitos, y pasos de algoritmo descritos en relación con las modalidades aquí mencionadas se pueden ejecutar o realizar con un procesador de señal digital (DSP) , un circuito integrado de aplicación específica (ASIC) , un arreglo de compuerta de campo programable (FPGA) u otro dispositivo de lógica programable, compuerta discreta o lógica de transistor, componentes de hardware discretos tal como, por ejemplo, registros y FIFO, un procesador que ejecute un conjunto de instrucciones de microprogramación cableada, cualquier módulo de software programable convencional y un procesador, o cualquier combinación de los mismos diseñada para ejecutar las funciones aquí descritas. El procesador puede ser, de manera conveniente, un microprocesador, pero en la alternativa, el procesador puede ser cualquier procesador convencional, controlador, microcontrolador, dispositivo de lógica programable, arreglo de elementos lógicos, o máquina de estado. El módulo de software podría residir en memoria RAM, memoria instantánea, memoria ROM, memoria EPROM, memoria EEPROM, registros, disco duro, un disco removible, un CD-ROM, o cualquier otra forma de medio de almacenamiento conocido en la técnica. Un procesador ejemplar está convenientemente acoplado al medio de almacenamiento a fin de leer información de, y escribir información en el medio de almacenamiento. En la alternativa, el medio de almacenamiento puede ser parte integral del procesador. El procesador y el medio de almacenamiento pueden residir en un ASIC. El ASIC puede residir en un teléfono u otra terminal de usuario. En la alternativa, el procesador se puede ejecutar como una combinación de un DSP y un microprocesador, o como dos microprocesadores en conjunto con un DSP central, etc. Por lo tanto, las modalidades preferidas de la presente invención se han mostrado y descrito. Sin embargo, resultará aparente para aguellos expertos en la técnica que se pueden realizar numerosas alteraciones a las modalidades aquí descritas, sin apartarse del espíritu o alcance de la invención. Por lo tanto, la presente invención no va a quedar limitada excepto de acuerdo con las siguientes reivindicaciones .

Claims (4)

NOVEDAD DE LA INVENCIÓN Habiendo descrito el presente invento, se considera como una novedad y, por lo tanto, se reclama como prioridad lo contenido en las siguientes: REIVINDICACIONES

1.- Un método para programar casos de transmisión en un sistema de comunicación inalámbrica, gue comprende: recibir indicadores de condición de canal a partir de una pluralidad de usuarios móviles, en donde los indicadores de condición de canal corresponden a comunicaciones de enlace de avance; determinar un criterio de retraso para la pluralidad de usuarios móviles; y determinar un programa de transmisión para la pluralidad de usuarios móviles, en donde el programa de transmisión es una función del criterio de retraso.

2. - Un método para programar casos de transmisión en un sistema de comunicación inalámbrica, que comprende: evaluar una pluralidad de colas de transmisión para identificar la sensibilidad de retraso y sensibilidad de rendimiento de un flujo de aplicación asociado con cada cola de transmisión; generar un conjunto de casos de transmisión candidato a partir de la pluralidad de colas de transmisión; seleccionar un caso de transmisión candidato a partir del conjunto; y preparar el caso de transmisión candidato seleccionado para transmisión.

3.- El método de conformidad con la reivindicación 2, caracterizado porgue la generación del conjunto de casos de transmisión candidato comprende: generar una métrica de bits para cada cola; y generar una métrica de relleno de bits para cada cola.

4. - El método de conformidad con la reivindicación 3, caracterizado porque la selección de un caso de transmisión candidato comprende: generar una métrica de pagúete como una función de la métrica de bits; y comparar las métricas de paquete para casos de transmisión candidato en el conjunto.