En el presente apartado se presenta el escenario de pruebas junto
con las aproximaciones realizadas en la generación de tráfico de los
diferentes usuarios. También se aborda la configuración de las
RABs.
5.2.1 Escenario de simulación.
Para poder valorar el comportamiento del sistema con las RABs
Especificadas se ha buscado un sistema con las siguientes
características.
- Sistema al límite de capacidad para apreciar las diferentes mejoras al
especificar diferentes tasas de errores.
- Adaptación del control de admisión para permitir la asignación de la
totalidad de la capacidad del sistema en función del tipo de
escenario.
Para lograr estos objetivos el escenario de pruebas se ha definido con las
siguientes características:
- 30 usuarios de streaming a una velocidad de 50 km/h.
- Escenario de 1600 x 1600 metros.
- Shadowing de 7 dB.
- Simulaciones de 15 minutos repetidas 3 veces, recogiendo los
valores medios de las tres simulaciones.
5.2.2 Generación de tráfico.
Una de las tareas a realizar para la correcta simulación de los
usuarios de streaming de UMTS es implementar las funciones
encargadas de generar (lo mas realista posible) el tráfico de los
usuarios simulados. Partiendo de los puntos anteriores (véase 5.1 )
y atendiendo a las restricciones impuestas por el simulador se ha
aproximado la generación de tráfico de la forma siguiente:
Fig. 5.3 Esquema de la generación del tráfico.
En el sentido Downlink,
- Una primera componente que genera un paquete de 2560 bits
cada 320 ms. Este flujo genera una tasa de 8 kbps y simula la tasa
generada por la componente de tramas I en el sistema.
- La segunda componente genera 4480 bits cada 80 ms. Esta
Cadencia provoca la generación de una tasa de 56 kbps,
aproximándose al valor obtenido empíricamente presentado en el
apartado anterior.
En sentido Uplink,
1. Se aproxima el tráfico del Uplink en una única componente
De 1,28 kbps, generado mediante paquetes de 320 bits cada 250
ms. El tráfico generado corresponde básicamente a una
aproximación a la tasa generada por los paquetes RTCP, RTSP.
La aproximación realizada no contempla la generación de los flujos
de audio, dejando esta componente por similitud a estudios
realizados de voz sobre IP ofrecidos sobre UMTS.
5.2.3 Configuración de las RABS.
Para observar el comportamiento del sistema UMTS delante de la
Arquitectura planteada se realiza la configuración de 3 escenarios
diferentes que nos permiten evaluar los diferentes comportamientos
del sistema UMTS.
Para tal efecto se prepararán tres escenarios cada uno con las
Siguientes características.
- TTI Intervalo de tiempo entre transmisiones.
- TB SIZE Número de bits que componen un bloque radio.
- TFC Número máximo de TB que se pueden enviar en un
TTI.
- SF Spreading Factor.
- Code Rate Ganancia especifica debida a la codificación
de canal .
Los anteriores parámetros están ligados mediante las siguientes
ecuaciones.
Ecuación 5.1 Velocidad de la RAB relacionada con la velocidad de chip.
Ecuación 5.2 Velocidad de la RAB relacionada con el contexto.
Partiendo de estas ecuaciones definimos el escenario 1 con las
Siguientes características.
- RAB de 64 kbps, bloques radio de 320 bits, Spreading Factor
de 16, Code Rate de 3,75, nº ACKs igual a 8.
- El trafico generado del servició de streaming se sirve todo por la
RAB anterior, utilizando únicamente canales dedicados DCH.
- El tráfico garantizado para el servicio anterior es de 64 Kbps.
Fig. 5.4 Esquema del primer escenario
Para el caso del escenario 2 tenemos las siguientes configuraciones.
- RAB_1 de 8 kbps. bloques radio de 320 bits, Spreading
Factor de 128, Code Rate de 3,75, nº ACKs igual a 8
- RAB_2 de 8, 16, 32,64 o 128 Kbps. bloques radio de 320 bits, Spreading
Factor de 128, 64, 32, 16,8, Code Rate de 3,75., nº ACKs igual a 2.
- El trafico generado del servició de streaming es repartido por
las RABs anteriores, transportándose los fotogramas I sobre la
RAB_1 y el resto de contenidos sobre la RAB_2.
- El tráfico garantizado para el servicio anterior es de 8 Kbps
para la RAB_1 y 64 Kbps para la RAB_2.
Fig. 5.5 Esquema del segundo escenario.
Finalmente el tercer escenario tiene las siguientes características:
- RAB de 64 kbps, transportada sobre canales comunes
(DSCH, Downlink Shared Channel). bloques radio de 320 bits,
Spreading Factor de 16, Code Rate de 3,75., nº ACKs igual a 8.
- El trafico generado del servició de streaming se sirve por la
RAB anterior, utilizando únicamente canales comunes DSCH,
Teniendo que competir por los recursos entre los diferentes servicios
- El tráfico garantizado para el servicio anterior es de 64 Kbps.
Fig. 5.6 Configuración del tercer escenario de pruebas.
5.3 Resultados obtenidos.
Los resultados obtenidos en las simulaciones realizadas sobre el
Emulador anteriormente explicado se basan en el estudio del
comportamiento de los parámetros relacionados con el tráfico a
cursar, básicamente el SDU error ratio y el retardo observado por los
paquetes.
5.3.1 Resultado referentes al escenario 1.
En el escenario 1 todos los paquetes se transportan sobre la misma
RAB con una BLER deseada de un 1%. Este valor de BLER
corresponde al valor máximo permitido para ofrecer un vídeo con
QoS, valor a aplicar para los frames tipo I.
Retardo medio | Load BTS | BLER | SDU Error |
258 ms | 0,42 | 26,56 % | 7,23 % |
Tabla 5.1 Valores obtenidos para el escenario 1.
La BLER obtenida por UMTS es claramente superior a la deseada,
26 % vs un 1 % deseada. En este caso un gran porcentaje de los
TB que se transmiten erróneamente tienen que ser retransmitidos,
hasta un máximo de 8 veces. Este efecto provoca un aumento en el
retardo medio de los paquetes y provocando un aumento en la carga
de la estación base.
Con el SDU observado, 7.23 %, y basándonos en los resultados
obtenidos en el capítulo anterior, se concluye en la imposibilidad de
servir contenidos en streaming con una cierta calidad en el escenario
1. Este resultado se puede ligar mediante la SDU error con los
resultado obtenidos para perdidas constantes realizadas con el
programa anteriormente explicado (véase 4.5).
5.3.2 Resultado referentes al escenario 2.
En el escenario 2 la información de cada usuario de vídeo es
transportada en 2 RABs Para el trasporte de los paquetes que
contienen los frames I se emplea la configuración uno de la RAB,
denominada en esta memoria como RAB de streaming básica,
dejando los paquetes que transportan los frames P para la RAB 2,
denominada de streaming mejorada. La BLER deseada es de un
1 % para los frames tipo I y de un 10 % para los paquetes que
componen los frames P. A pesar de estas diferencias en la BLER la
calidad del vídeo observada por el usuario será semejante en un
escenario donde la BLER sea igual e inferior para ambas RAB.
En este segundo escenario existe una pieza clave para el
funcionamiento del sistema UMTS. Este es el planificador de
paquetes encargado de atender y asignar las prioridades de
transmisión de los diferentes paquetes procedentes de los usuarios.
En esta línea se presentan los resultados para dos variaciones en el
planificador implementado en el simulador.
5.3.2.1 Sin adaptación de la política de servicio.
Para poder garantizar una cierta calidad a un servicio interactivo,
como puede ser un servicio de vídeo streaming, han de crearse unas
directrices para la gestión de las prioridades y recursos en la
transmisión de los paquetes por la interfaz radio. Este efecto tendrá
su mayor importancia en entornos donde la carga de trabajo sea
elevada. En este sentido el planificador de paquetes del emulador
UMTS proviene de una ineficiente asignación del número de bloques
de transporte que se transmiten por la interfaz radio durante un
intervalo (TTI). A modo de ejemplo se puede imaginar una situación
donde en un TTI el usuario tiene la información correspondiente a 9
TB que debe ser transportados sobre la RAB de streaming
avanzada. En el proceso de asignación de TFC (formato de
transmisión), el planificador tiene que decidir el número de TB que
permite transmitir en un instante, tomando valores discretos
definidos en la especificación de la RAB. En la configuración
realizada el planificar puede escoger entre los siguientes valores: 0,
1, 2, 4, 8 o 16 TB de información correspondiendo cada uno de
estos valores a una velocidad instantánea de transmisión.
En la implementación original el valor seleccionado corresponde al
Valor mínimo de TB que permite transmitir toda la información, sin
importar ningún otro aspecto. Retomando el ejemplo anterior para
trasmitir 9 TB se selecciona el valor de 16 TB, decisión que obliga a
añadir 7 TB de relleno para llegar a transmitir los 16 TB. Esto
provoca un mal uso de los recursos repercutiendo directamente en
el tráfico del resto de usuarios, impidiendo cursar parte del tráfico por
falta de recursos.
Este efecto tiene su principal repercusión en el tráfico cursado sobre
la RAB de streaming avanzado, en la cual podemos observar como
la proporción de tramas erróneas se eleva hasta unos 37 %,
inadmisibles para el servicio a prestar.
Fig. 5.7 SDU error ratio para el escenario 2 sin adaptar el planificador.
En la grafica anterior la elevada tasa de error proviene de los
Paquetes descartados por la expiración del temporizador. El
temporizador expira a causa del masivo intento de retrasmisión de
los paquetes erróneos, a su vez provocado por valores de BLERs
alrededor del 10 %.
Estas retransmisiones provocan que el retardo medio en servir un
Paquete correctamente aumente hasta llegar a extremos donde se
descartan los paquetes por expiración del temporizador.
Para intentar solventar este desajuste se propone un decremento en
el número máximo de retransmisiones, fijando como valor máximo 2
retrasmisiones. Con la anterior configuración la tasa de error
conseguida aumenta hasta valores cercanos al 41 %, empeorando el
resultado anterior. A diferencia del caso anterior los paquetes son
descartados por la expiración del temporizador o por exceder el
número máximo de retransmisiones permitidas.
En este tipo de escenario y a pesar que los frames tipo I no sufren
ningún error, no podemos servir contenidos de vídeo debido a la
elevada tasa de perdidas en la RAB de streaming avanzada.
5.3.2.2 Adaptación de la política de servicio.
Para solventar el problema anterior se corrige el problema de
adaptación de formatos para la transmisión, tomando como regla el
transmitir el mayor número de TB que no provoque el efecto de
relleno. Como ejemplo si se requiere transmitir 9 TB se realizara la
transmisión en 2 TTI, el primero transmite 8 TB y el segundo
transmite 1 TB. El resultado de de esta asignación es un
aprovechamiento óptimo de los recursos del sistema.
Otro de los aspectos a decidir en la nueva política de planificación es
La decisión a tomar cuando la tasa de paquetes generados por el
usuario excede la tasa garantizada para el servicio. Cuando esto
ocurre se ha realizado dos aproximaciones, considerar RABs
totalmente diferentes o considerar la RAB de streaming como trafico
prioritario, reconduciendo el trafico excedente hacia la RAB de
streaming avanzada.
Fig. 5.8 Modificaciones del planificador.
5.3.2.2.1 RABs independientes.
La configuración implementada se corresponde gráficamente con la
Primera representación de la Fig. 5.8. Esta configuración considera
cada RAB como trafico independiente, no permitiendo que se cursen
los paquetes excedentes de la RAB de streaming en caso que la
tasa generada sea superior a la garantizada. Esta solución evita que
el tráfico excedente de la RAB de streaming tenga repercusiones en
el tráfico de la RAB de streaming avanzado.
Un aspecto importante en la configuración del escenario recae en las
Tasas medias de generación y garantizadas. Para un correcto
funcionamiento la tasa de generación ha de ser igual o inferior a la
tasa garantizada. De lo contrario los paquetes desbordan el buffer
provocando un incremento de la tasa de error.
En la simulación de este escenario se han obtenido los siguientes
resultados.
Tabla 5.2 Resultados obtenidos con RABs independientes.
Se puede observar como los paquetes de los frames I transportados
sobre la RAB de streaming observan un canal con un retardo
moderado y con bajos valores de BLER. Finalmente con el uso de
ACKs se corrige esta BLER obteniendo valores de un 0% de error
para las tramas importantes para la transmisión de vídeo en
streaming (Frames I).
Por otro lado en la RAB de streaming avanzado encontramos valores
De retardo más elevados, con una tasa de SDUs erróneas de un
15,39 %, valor elevado pero muy inferior a los obtenidos en el
escenario 1. Con la mejora de la adaptación del escenario y del
simulador se ha conseguido reducir la tasa de error en más de un
45%.
5.3.2.2.2 RABs conjuntas
La configuración implementada se corresponde gráficamente con la
Segunda representación de la Fig. 5.8. La RAB de streaming se
considera como trafico prioritario, permitiendo que se cursen los
paquetes excedentes en la RAB de streaming avanzada.
Tabla 5.3 Resultados obtenidos con RABs conjuntas.
En los resultados anteriores la RAB de streaming funciona
Correctamente proporcionando una tasa de error de SDU del 0%.
Al igual que en la simulación anterior la tasa de error para la RAB de
streaming avanzada esta alrededor del 15 -16 %. A diferencia
respecto del escenario anterior el retardo medio de los paquetes
asciende hasta valores de 4 seg, provocado por la necesidad
realizar más retransmisiones por cada paquete.
Analizando el elevado valor en la tasa de error encontramos un gran
número de paquetes descartados por la expiración del temporizador.
Este efecto tiene su origen en la alta BLER, provocando que muchos
paquetes se tengan que retransmitir para intentar minimizar la tasa
de error. Estas retransmisiones ocupan recursos destinados a
paquetes descartados por la expiración del temporizador, ya que el
sistema no tiene suficiente margen para retransmitir los paquetes
erróneos. Este efecto se observa claramente cuando se simula un
escenario con una diferencia entre la tasa generada y la tasa
garantizada superior a la BLER. En nuestro caso se ha realizado el
experimento con una generación a 48 Kbps y una tasa garantizada
de 56 Kbps, proporcionando un 14 % de la tasa para
retransmisiones frente al caso anterior donde se intentaba cursar
una tasa de 52 Kbps en una RAB que garantizaba 56 Kbps, dejando
únicamente un margen de retransmisión del 7,1 %
Fig. 5.9 Resultados de la tasa de error obtenida con los diferentes
planificadote y tasas.
Gracias a un margen de retransmisión suficientemente, la tasa de
error baja hasta un valor de 8,5%, permitiendo servir el vídeo con
calidad.
5.3.3 Resultado referentes al escenario 3.
El escenario 3 todos los paquetes se transportan sobre el canal
común, configurado para obtener una BLER de un 1 %, al igual que
el escenario 1.
Retardo medio | Load BTS | BLER | SDU Error |
3000 ms | 0,29 | 0,98 % | 17,61 % |
Tabla 5.4 Valores obtenidos para el escenario 3.
El hecho más destacable es la semejanza entre la BLER deseada y
La obtenida. En cambio el SDU error alcanza valores elevados
debido al alto porcentaje de paquetes descartados por expiración del
temporizador. El retardo medio también obtiene altos valores,
alcanzando un valor de 3 seg.
5.3.4 Visión general de los resultados.
Las pruebas de los escenarios anteriores sirven como punto de
partida para la obtención de una valoración general de la solución
propuesta. En esta línea presentamos las conclusiones extraídas.
Fijando como objetivo mantener la calidad de vídeo observada por el
usuario, tenemos diversas formas de transmitir la información de
vídeo. Si no priorizamos la información necesitamos una tasa de
error de paquetes en torno al 1% para obtener una relación en la
calidad MOS aceptable. De lo contrario, y como ya hemos visto
anteriormente, si descomponemos la parte visual del vídeo en
fotogramas I y P, podemos conseguir la misma calidad MOS pero
permitiendo diferentes valores para la tasa de error sufrida por cada
topología de datos. En este caso la configuración de la tasa de
perdidas máximas ha de tomar valores aproximados de un 1 % para
fotogramas I y un valor de 10 % para fotogramas P.
Con estos requerimientos si transportamos contenidos de vídeo
Sobre arquitecturas que transportan los datos sobre la misma RAB,
y para conseguir la SDU de un 1%, el sistema no puede ofrecer
servicio a más de 23-24 usuarios para el escenario de referencia.
Fig. 5.10 SDU experimentado para el escenario 1.
Realizando los mismos resultados sobre el escenario 2, y atendiendo
a las condiciones de SDU establecidas anteriormente, el número de
usuarios de aumenta hasta 30 aproximadamente usuarios. Este
resultado aumenta la capacidad en usuarios del sistema, pero sin
que el servicio se degrade.
Fig. 5.11 Usuarios soportados para el escenario 2 con RABs separadas.
En la gráfica anterior se puede observar como la tasa de error de las tramas I
es igual a la deseada, 0 %. También se observa como la tasa de
error para las tramas P esta en todo momento por debajo del valor
deseado, obteniendo una solución efectiva para el transporte de
información de vídeo.
Fig. 5.12 Usuarios soportados para el escenario 2 con RABs conjuntas.
La grafica anterior muestra los resultados del escenario 2 para el
caso de RABs conjuntas. En este caso encontramos el diferencial
en los valores de la tasa de error de las tramas P, siendo estos
ligeramente superiores a los obtenidos mediante el sistema de RABs
separadas.
En el tercer escenario las condiciones son similares a la del primer
escenario, exceptuando que el transporte de la información se
efectúa sobre un canal compartido, donde los usuarios compiten por
los recursos en el canal radio.
Fig. 5.13 SDU experimentado para el escenario 3.
Como conclusión de los resultados anteriores se puede observar un
Aumento en la capacidad de usuarios que aguanta el sistema. De
esta forma en un escenario donde se sirva el vídeo sobre diferentes
RAB podemos ofrecer el servicio a 6-7 usuarios más que si se
realiza el transporte de la información sobre una única RAB, sin
perder en la calidad observada por el usuario.
No hay comentarios:
Publicar un comentario