Aggregate CES versus technology-based approach

Para este análisis, se supone solo el enlace ascendente (TM-EB), considerando una sola celda para un sistema WCDMA. También es considerado un duplexado por división de frecuencia, con un control de potencia perfecto y un canal libre de errores, donde los paquetes arriban a los TMs de acuerdo a un proceso aleatorio. La Figura 31 ilustra el modelo propuesto para este análisis.

TMs con tráfico de vídeo TMs con tráfico de datos TMs con tráfico de voz . . . . . . . . . TM TM TM TM TM TM . . . . . . . . . . . . C₁ . . . C_N-1 C_N Petición de Códigos MAC Scheduler n_q n_d n_v T a b l a d e P e t i c i o n e s GPS Cálculo de Pesos

Figura 31. Modelo del sistema propuesto para un esquema de asignación de recursos CDMA/GPS-DW.

El funcionamiento del esquema de asignación de recursos para WCDMA de la

Figura 31 se puede analizar a través del diagrama a flujo que se ilustra en la Figura 32 [Mendez et al., 2003]. Hay que tomar en cuenta, que en este esquema se considera la etapa MAC estudiada en los capítulos anteriores.

El funcionamiento de este algoritmo se explica a continuación: cada TM en estado de vacío puede generar paquetes de acuerdo a sus modelos de fuentes de tráfico. Para esto, se debe que considerar el tipo de servicio a manejar, con sus respectivas calidades de servicio y sobre todo la característica del interfaz aire, que puede ser o no sensible al tipo de modelo de fuente de tráfico. De acuerdo al estándar UMTS, el tráfico para servicio de datos de tipo WWW, se modela como una distribución de Pareto [ETSI, 1997]. Para servicios de voz y vídeo (videophone) en tiempo real, se considera como el modelo de tráfico ON-OFF

Vacío

Activo

Petición de Código

Colisión

EB actualiza la Tabla de Peticiones: Tipo de Servicio

Información Generada Tiempo de Generación

Estado del Buffer

Ciclo de vida

Disminuye Prob. RTx para datos si

TMs Activos

Pesos para cada sesión

Ancho de banda mínimo para cada sesión

Asignación del ancho de banda restante

Selección y ajuste de ganancia de procesado para cada TM

TM Transmite no Libera Código si Buffer Vacío Etapa de Asignación de Recursos no vídeo BER Aceptado Rechazado no si voz BER Aceptado Rechazado no si datos BER Aceptado Rechazado no si

Generación de Tráfico Multimedia

Siguiendo con el funcionamiento del algoritmo propuesto, en el instante que un paquete es generado, el TM conmuta a un estado activo. En este estado el TM hace la petición para transmitir usando S-Aloha (canal RACH) como una parte del protocolo CDMA, donde un TM escoge aleatoriamente un código de un grupo disponible, mencionando que en el sistema hay más TMs que códigos. Una colisión ocurre cuando dos o más TMs escogen el mismo código y los TMs involucrados tendrán que contender en la siguiente ranura de tiempo disponible. Una petición para transmitir es rechazada cuando no haya códigos disponibles, o no garantice la BER para cada tipo de tráfico.

Para la asignación de códigos, la EB toma en cuenta la prioridad en los servicios, donde el servicio de vídeo tiene la prioridad más alta y los datos de tipo WWW la más baja. Con esta condición, lo primero que hace la EB, de acuerdo a la información que tiene en su tabla de peticiones (TP), es asignar los códigos a los TMs que tengan su memoria temporal llena, asignando primero recursos a los TMs con tráfico de vídeo. En caso de que haya más TMs de vídeo que códigos disponibles, el criterio a tomar por la EB es que de los TMs aún con memoria temporal llena, se le asignará recursos a aquellos TMs que no se les asignó código en las ranuras de tiempo previas. Si hubo suficientes códigos para los TMs con tráfico de vídeo, entonces los códigos restantes se asignan a los TMs con tráfico de voz, siguiendo la misma lógica que se aplicó al servicio de vídeo. Por último, se asignan códigos a datos tomando en cuenta lo mencionado anteriormente. Si después de asignar los códigos a los TMs que tenían su memoria temporal llena quedan aún códigos, se asignan los códigos restantes a los TMs próximos a expirar en su tiempo de vida, considerando el mismo proceso que se siguió para una memoria temporal llena. Por último, si todavía hay códigos después de asignarlos de acuerdo a los criterios de memoria temporal llena y tiempo de vida, los códigos restantes se irán asignando por prioridad de servicio, primero a vídeo, seguido de voz y por último datos. En esta asignación de cada código, la EB determina si se garantiza la BER para cada tipo de tráfico, y en el momento que no se garantice la BER para tráfico multimedia, la EB rechaza las peticiones de código a pesar de que haya códigos disponibles.

Una vez que la EB reconoce esta petición, usará un esquema de asignación de recursos centralizado similar a los descritos en [Karol et al., 1995], [Covarrubias, 1999].

Tan pronto como las peticiones de transmisión de los TMs han sido reconocidas, la EB actualiza la TP. Esta TP consiste de la siguiente información: número de paquetes en la memoria temporal del TM, tipo de servicio, tiempo de vida del paquete, y la ranura de tiempo específica en el cual fue generado el paquete.

Después de asignar los códigos a los TMs, la EB conoce cuantos TMs son de vídeo, voz y datos, además del ancho de banda que cada TM está solicitando, por lo tanto, a través del esquema GPS (controlador centralizado) [Parekh, 1993] se calcula el ancho de banda mínimo para cada servicio. Para obtener esto, es necesario calcular los pesos para cada sesión dinámicamente, tomando en cuenta la cantidad de TMs para vídeo, voz y datos, el ancho de banda y la BER para cada sesión. El ancho de banda restante se asigna en proporción al peso de cada sesión. Lo que resta es seleccionar y ajustar la ganancia de procesado de cada TM y transmitir en la ranura de tiempo correspondiente. Si después de transmitir el TM no hay más información en la memoria temporal del TM, éste libera el código y pasa a un estado de vacío. En caso de que el TM tenga más información que transmitir se lo indica a la EB, por lo que no debe de contender otra vez, solamente ajustará su ganancia de procesado en la siguiente ranura de tiempo para poder transmitir.

Como se mencionó previamente, la asignación de código para cada TM es hecha por la EB; por consiguiente, la EB conoce el número de TMs activos para cada servicio (vídeo, voz y datos). En el siguiente apartado se analiza cómo se lleva a cabo la aceptación o rechazo de la petición de código tomando en cuenta la BER.