Estudio de QoS en WLANs IEEE e

Transcripción

1 Estudio de QoS en WLANs IEEE 82.e José Villalón Millán, Pedro Cuenca Castillo y Luis Orozco-Barbosa Instituto de Investigación en Informática Universidad de Castilla-La Mancha, Campus Universitario, 27 Albacete, España [josemvillalon, pcuenca, lorozco]@info-ab.uclm.es Resumen El IEEE 82. es el estándar de redes inalámbricas de área local (WLAN) más utilizado en la actualidad. Sin embargo, dicho estándar no proporciona soporte QoS para las aplicaciones multimedia. Esto ha llevado al IEEE a la creación de un grupo de trabajo encargado de diseñar un mecanismo que proporcionen buenos niveles de QoS a estas aplicaciones. Este artículo introduce ésta enmienda al estándar, llamada IEEE 82.e. En su descripción se muestran los mecanismos utilizados en 82.e para dar soporte de QoS. Finalmente se ha realizado un estudio sobre el comportamiento del esquema distribuido (EDCA) presentado en 82.e, cuando se utilizan aplicaciones con distintos requisitos, como es el caso de los tráficos de voz, vídeo, best-effort y background.. Introducción En la actualidad, las WLANs se encuentran en un periodo de gran expansión, debido principalmente a su bajo coste, su facilidad a la hora de desplegarse, y por supuesto, a la libertad de movimiento que otorgan a las estaciones dentro de su área de cobertura. Otro factor muy importante en este auge de las WLANs ha sido la aparición en 997 del estándar IEEE 82., con su posterior revisión en 999 [], y sus enmiendas. Gracias a las enmiendas a nivel físico presentadas al estándar (IEEE 82.a, b, c), se ha pasado de unas velocidades de envío de ó 2 Mbps a 54 Este trabajo ha sido apoyado por el Ministerio de Ciencia y Tecnología mediante el proyecto CICYT TIC C6_2, y la Consejería de Ciencia y Tecnología de Castilla-La Mancha a través del proyecto PBC-3- y de FEDER. Mbps. Sin embargo, las aplicaciones multimedia no solo se caracterizan por las altas necesidades de ancho de banda, sino que además imponen restricciones severas en cuanto a retardos, variación en los retardos (jitter) y tasas de descarte. Es decir, las aplicaciones multimedia necesitan soporte de QoS (Quality of Service). El estándar IEEE 82. [] define dos funciones de acceso al medio a nivel MAC. La primera de ellas recibe el nombre de DCF (Distributed Coordination Function) y utiliza un mecanismo de acceso al medio distribuido basado en CSMA/CA (Carrier Sense Multiple Access with a Collisions). La segunda de las funciones recibe el nombre de PCF (Point Coordination Function), y utiliza la anterior como base para su funcionamiento. PCF es opcional y usa un mecanismo de polling que requiere de un nodo central llamado PC (Point Coordinator) que lo coordine. Cuando DCF es usado, cualquier estación que tenga datos para transmitir debe determinar el estado del canal de transmisión. Si el canal permanece libre durante un intervalo de tiempo DIFS (DCF InterFrame Space) la estación obtiene los derechos para comenzar a transmitir. En caso contrario, la estación deberá ejecutar un algoritmo de backoff, que asignará un número aleatorio de slots de espera El valor de ese contador de backoff será decrementado en una unidad cada vez que el canal permanezca libre por un tiempo aslottime. Si en un instante cualquiera la estación detecta actividad en el canal, detendrá el decremento del contador, hasta que el canal este inactivo durante un intervalo DIFS. Después de este tiempo de espera, el contador reiniciará su cuenta atrás hasta llegar a, instante en el que comenzará la transmisión de la trama. El envío de una trama necesita la confirmación, por parte de la estación destino de que ha llegado correctamente. Si no es así, el emisor debe retransmitir la trama

2 duplicando el tamaño de la ventana. Si por el contrario la estación emisora recibe el ACK de la receptora, actualizará el valor de CW a CW min. DCF es un mecanismo simple, en el cual todas las estaciones que intentan acceder al canal lo hacen utilizando los mismos tiempos de espera, por lo que DCF no proporciona ningún soporte de QoS. Esto ha obligado al IEEE a la estandarización de métodos para proporcionar QoS. En este artículo, se ha realizado un estudio en profundidad sobre el nuevo método de acceso distribuido (EDCA) introducido en el estándar IEEE 82.e. Este artículo está organizado como sigue: La sección 2 presenta la enmienda IEEE 82.e, que pretende proporcionar QoS en WLANs. Una evaluación de prestaciones sobre el nuevo método de acceso distribuido en IEEE 82.e (EDCA) es mostrado en la sección 3. Por último, en la sección 4 se exponen las conclusiones de este artículo. 2. La enmienda IEEE 82.e El estándar IEEE 82.e [2] es una propuesta que define los mecanismos utilizados en una WLAN para proporcionar QoS a aplicaciones en tiempo real como voz y vídeo. En este nuevo estándar, se hace una distinción entre aquellas estaciones que no utilizan los servicios QoS, que se denominan nqsta, y aquellas que si los utilizan, llamadas QSTA. Para proporcionar soporte QoS, en IEEE 82.e se introduce una tercera función de coordinación, llamada HCF (Hybrid Coordination Function). HCF incorpora dos nuevos mecanismos de acceso al canal: EDCA (Enhanced Distributed Channel Access) y HCCA (HCF Controlled Channel Access). La principal característica de HCF es la definición de cuatro categorías de acceso (AC) y de ocho traffic stream (TS) a nivel MAC. Cuando un paquete procedente de las capas superiores llega a la capa MAC, es etiquetado con un identificador de prioridad de usuario (TID) acorde con sus necesidades de QoS. Este identificador puede tomar valores de a 5. Si el TID del paquete tiene valores de a 7, es mapeado con respecto a las cuatro AC, usando el método EDCA para acceder al canal. Si por el contrario el identificador TID tiene valores de 8 a 5, usará la función HCCA para acceder al medio, quedando almacenado el paquete en la cola de TS correspondiente a su TID. Otra característica incluida en este nuevo estándar es el concepto de TXOP (Transmisión Opportunity), que es un intervalo de tiempo en el cual la estación que lo posee tiene permiso para enviar sus tramas. 2.. EDCA (Enhanced Distributed Channel Access) El método de acceso al medio EDCA, pretende mejorar el funcionamiento de DCF, tratando de forma preferencial a las aplicaciones con restricciones en el tiempo. Para realizar esta diferenciación, EDCA introduce dos métodos: El primero de ellos es asignar distintos IFS a cada categoría de acceso. Para ello, el estándar introduce un nuevo tiempo de espera llamado AIFS (Arbitration InterFrame Space). El valor de AIFS es AIFS[AC] = AIFSN[AC] x aslottime + SIFS, donde AIFSN (Arbitration InterFrame Space Number), es utilizado para la diferenciación entre las distintas AC. El segundo método utilizado es asignar distintos tamaños de ventana CW para cada AC. Con este segundo método, el estándar pretende asignar menores tiempos de espera a las estaciones más prioritarias cuando estas tengan que efectuar el mecanismo de Backoff. Estos tamaños se obtendrán mediante la Figura. EDCA. ACs en EDCA. AIFS EDCA

3 asignación de distintos tamaños límite de ventana CW min y CW max. Otro factor utilizado para la distinción en EDCA, es la duración del TXOP (TXOPLimit). Este parámetro limita el tiempo en el que una estación tiene los derechos para transmitir, sin que el resto de estaciones le disputen el canal. La figura muestra el funcionamiento de este mecanismo distribuido. Si nos fijamos en ella, podemos observar como dos o más AC dentro de una misma QSTA pueden poner a su contador de Backoff en el mismo instante. Si esto ocurre, ambos flujos intentarán mandar los datos produciéndose una colisión, que en el estándar han denominado colisión interna. Siempre que esto se produzca, la capa MAC ofrecerá la oportunidad de transmisión al flujo más prioritario, tratando el de menor prioridad igual que si se hubiera producido una colisión real. 3. Evaluación de prestaciones En esta sección, se ha realizado un estudio en profundidad sobre el nuevo método de acceso distribuido EDCA. Se ha partido de los valores recomendados por el estándar (ver tabla ), y sobre ellos se han variado cada uno de los cuatro parámetros que intervienen en la diferenciación de servicio: AIFS, CW min, CW max y TXOPLimit (ver tabla 2). En nuestro escenario de simulación se ha considerado un escenario base, compuesto por cuatro clases de servicio: voz, vídeo, best-effort y background, y sobre el se ha evaluado el throughput y la tasa de colisiones de los paquetes de voz y vídeo. Tabla. Valores recomendados EDCA AC AIFSN CW min CW max TLimit Vo ms Vi ms Bk Be Escenario Para la realización de las simulaciones se ha utilizado el simulador de redes Opnet Modeler. [3]. Se ha modelado sobre la capa física IEEE 82.b, utilizando un ancho de banda de Mbps. Se han definido cuatro tipos de servicio, Tabla 2. AIFSN CWmin CWmax TXOP Limit Valores utilizados para el calibrado Vo Vi BE BK Voz (Vo), Vídeo (Vi), Best-effort (BE) y Background (BK), en línea de la especificación IEEE 82.D [4]. Se ha asumido el uso de una WLAN compuesta por un conjunto de estaciones inalámbricas y un punto de acceso conectado a una red cableada, formando así una red BSS. Con respecto a la capacidad del enlace cableado, se ha supuesto que es mucho mayor que la del inalámbrico, y que éste no puede ser el cuello de botella de la red. Como ya se ha comentado anteriormente, se han utilizado cuatro tipos de tráfico para realizar las simulaciones, y cada uno de ellos utiliza una fuente distinta para ser generado. Para el tráfico de voz, se ha asumido el uso de fuentes de caudal constante con una tasa de bits de 6 Kbps, acorde con el estándar de codificación de voz G.728 [5]. Los paquetes de voz tienen un tamaño de 68 bytes, incluyendo las cabeceras RTP/UDP/IP. Estas fuentes son activadas aleatoriamente dentro del intervalo [,.5] segundos después del comienzo de la simulación. Con respecto a las aplicaciones de vídeo, se han usado trazas VBR generadas mediante el codificador de vídeo H.264 [6]. Se ha usado la secuencia mobile calendar, codificada en formato CIF con una tasa de 25 frames/s. La tasa media de la transmisión de vídeo está alrededor de 48 kbps, con un tamaño de paquete 64 bytes (incluidas cabeceras RTP/UDP/IP). Está claro que este tipo de fuentes está caracterizado por un patrón de tráfico periódico, y tasas de envío muy

4 variables. Por ello cada aplicación de vídeo comienza a transmitir dentro de un periodo aleatorio asignado mediante f = uniform(; +2/f), siendo f la tasa de frames/s. De esta forma, las ráfagas de tráfico son distribuidas a lo largo de un GOP (Group of Pictures), representando así un comportamiento similar al real. La transmisión de un frame de vídeo está uniformemente distribuida a lo largo del intervalo de tiempo del frame (/f). Las fuentes de tráfico best-effort y background han sido creadas usando la distribución de Pareto, de forma que el tráfico generado se asemeje a su comportamiento irregular y variable. Para suavizar los picos de tráfico generados por este tipo de fuentes, en lugar de una única fuente por estación se han utilizado cinco. La tasa de inyección del tráfico best-effort es de 28 kbits/s, mientras que cada estación de tráfico background inyectará el doble (256 Kbits/s). Ambos tipos de tráfico utilizan paquetes de tamaño 552 bytes incluyendo en ellos las cabeceras TCP/IP, y comienzan a generar paquetes en el intervalo [,.5] segundos desde el comienzo de la simulación. El tiempo de simulación de todos los escenarios ha sido el mismo, dos minutos. Para medir las prestaciones de la red, se han seleccionado 3 métricas: Throughput, tasa de colisiones y tasa de pérdidas. Dado que cada una de las fuentes inyecta una cantidad distinta de datos, se ha optado por normalizar el throughput de cada tipo de tráfico con respecto al tráfico inyectado Resultados La figura 2 nos muestra el throughput, las colisiones y el número de paquetes descartados para los flujos de voz y vídeo, cuando se varían los valores de AIFSN. Los valores mostrados en las gráficas muestran el AIFSN asignado a BK- BE-Vi-Vo respectivamente. En 2.a se muestra el comportamiento del tráfico de voz. En ella se ve claramente la correspondencia entre número de colisiones de este flujo, y sus prestaciones. Esto se debe a que el tiempo que los paquetes se encuentran encolados en cargas altas de la red es muy alto en relación al deadline fijado ( ms). Por ello, un paquete que tenga que ser retransmitido tendrá una alta probabilidad de ser descartado. Los resultados de esta figura nos muestran que para este tipo de tráfico los valores recomendados por el estándar no son muy convenientes. En concreto, estos valores producen los peores resultados de todos los estudiados. En la figura se muestra como las prestaciones de este tipo de tráfico aumentan al asignar AIFSN distintos para los flujos de voz y vídeo. Este comportamiento es lógico ya que al asignar valores distintos se prioriza más al tráfico de voz, además de reducir la probabilidad de colisiones como queda plasmado en la figura. La figura 2.b muestra las prestaciones para el tráfico de vídeo. Al contrario que para la voz, este no se ve muy influenciado por la modificación de este parámetro. Si bien esto es cierto, la figura muestra un ligero aumento del throughput cuando el valor de AIFS asignado al tráfico BE está más alejado del AIFS del vídeo. El throughput, las colisiones y el número de paquetes descartados para voz y vídeo al variar el CW min son mostrados en la figura 3. Este parámetro nos indica el valor inicial de la ventana de Backoff, así como el valor que será incrementado después de una colisión. Los valores mostrados en las gráficas muestran el CW min asignado a BK-BE-Vi-Vo respectivamente. Al igual que ocurría en 2.a, en 3.a se ve claramente la dependencia del flujo de voz, del número de colisiones que presenta. Como era de esperar, el throughput de este tipo de tráfico aumenta, al asignar CW min mayores al resto de flujos. Con ello, además de aumentar su prioridad, se reducirá su número de colisiones (ver retransmisiones de voz). Además de esto, la figura nos muestra que el valor de CW min para este tipo de tráfico debe ser pequeño, reduciéndose sus prestaciones al aumentarlo. El comportamiento del tráfico de vídeo es mostrado en la figura 3.b. El throughput de en este tipo de tráfico no varía demasiado, aunque aumenta ligeramente al alejar los valores de CW min asignados a BE y BK del suyo. Por otro lado, la figura muestra que el aumento de su CW min no repercute negativamente en sus prestaciones. Es más, debido a que este tráfico es bastante más pesado, el aumentar levemente su CW min reducirá el número de colisiones sufridas por este tráfico, manteniendo o incrementando sus prestaciones.

5 Figura 2. Prestaciones de EDCA usando diferentes AIFSN. Voz. Vídeo Figura 3. Prestaciones de EDCA usando diferentes CW min. Voz. Vídeo

6 Figura 4. Prestaciones de EDCA usando diferentes CW max. Voz. Vídeo Figura 5. Prestaciones de EDCA usando diferentes TXOPLimit. Voz. Vídeo

7 Throughput Global Throughput Global Throughput Global Throughput Global Figura 6. Throughput global de la red al modificar cada uno de los cuatro parámetros La figura 4 muestra el estudio realizado cuando el factor modificado es CW max. Los valores mostrados en las gráficas muestran el CW max asignado a (BK y BE) - Vi - Vo respectivamente. Dado que este parámetro solo es utilizado cuando un paquete debe ser retransmitido varias veces, los resultados para cargas bajas son similares para todos los valores. A partir de una cercana al 8\% se empiezan a notar diferencias. En 4.a se muestran los resultados obtenidos para el tráfico de voz. A diferencia de los parámetros anteriores, al modificar este parámetro no se obtienes throughput muy distintos. Esto se debe a que al colisionar, los paquetes de voz tienen una alta probabilidad de ser descartados, por lo que pocas veces alcanzaran su CW max. De todas formas, al aumentar el CW max del resto de tráficos, los paquetes de voz se pueden ver ligeramente favorecidos. Las prestaciones del tráfico de vídeo se muestran en la figura 4.b. En ella se ve que a pesar de reducir el número de colisiones de los paquetes de vídeo, si se aumenta su CW max, el número de paquetes descartado aumentará, disminuyendo así su throughput. Esto se produce porque los paquetes de vídeo tienen un deadline mayor, y admiten varias retransmisiones, por lo que se alcanzará su CW max. Al asignarle un tamaño de ventana mayor, se reducirán las colisiones, pero por el contrario el resto de flujos tendrán más opciones de hacerse con el canal. Por último, en 5 se muestran el throughput, las colisiones y el número de paquetes descartados para los flujos de voz y vídeo, cuando se varían los TXOPLimit asignados. Las oportunidades de transmisión, que fueron descritas en el apartado 2, son asignadas solo a los tráficos real-time para intentar cumplir con sus requerimientos. A pesar de esto, dado que las fuentes de voz utilizadas inyectan paquetes cada 8 ms, y su deadline es únicamente de ms, nunca podrá haber dos paquetes en la cola de voz, por lo que este tráfico no se podrá beneficiar de la asignación de un TXOP. Por ello, la estaciones mandará únicamente una trama, y liberará el medio para que el resto de estaciones intenten ganarlo (igual que si no se le asignara un TXOP). En la figura 5.a se ve claramente este efecto. Si no se usan TXOP, el número de paquetes descartados de este tipo de tráfico es mucho menor, aumentando por ello el throughput. En la figura también se muestra la independencia del número de colisiones de este parámetro. Por el contrario, el tráfico de vídeo si inyecta una cantidad de paquetes más elevada, sobre todo cuando se encuentra con un frame de tipo I. Por ello, la utilización de TXOP maximiza su throughput. Esto queda reflejado en la figura 5.b. En ella se muestra el gran aumento de las colisiones, y como consecuencia, la reducción drástica del throughput cuando los TXOP no son utilizados. De los resultados también se puede intuir que un valor de TXOPLimit mayor de 6 ms para este tipo de tráfico tampoco es conveniente ya que no aumenta las prestaciones de para los paquetes de vídeo, y además repercute negativamente en el resto de tráficos. Para finalizar este estudio, en la figura 6 se muestra el throughput global de la red al modificar cada uno de los cuatro parámetros estudiados. En ella se muestra claramente como el throughput global de la red al modificar el AIFSN, CW min y CW max es prácticamente el mismo para todos los valores. Por ello, sería conveniente el uso de los valores que maximicen las prestaciones de los flujos real-time. Con respecto al la duración del TXOP, la figura 6 muestra que el uso de este

8 es necesario para que no decaigan las prestaciones de la red, y que el valor asignado a los flujos de vídeo no debe ser demasiado grande. 4. Conclusiones En este artículo se han descrito los mecanismos introducidos en la enmienda IEEE 82.e para proporcionar QoS. A continuación se ha realizado una evaluación de prestaciones de su modo distribuido (EDCA). Para ello se han modificado los valores asignados a los cuatro parámetros utilizados por el método para proporcionar QoS. Los resultados obtenidos muestran una correspondencia entre el número de colisiones de la red y las prestaciones obtenidas. El esquema EDCA garantiza unas buenas prestaciones para cargas inferiores a.75. A partir de este punto, y debido al aumento del número de colisiones, las prestaciones obtenidas decaen rápidamente. Los resultados también nos han mostrado que los parámetros recomendados en el estándar no son óptimos. Se ha visto que el parámetro AIFSN juega un papel muy importante para proporcionar QoS. Los resultados sugieren la asignación de un AIFSN distinto para los flujos de voz y vídeo. Con ello se mejoran considerablemente las prestaciones obtenidas para los flujos de voz. De la misma manera se ha observado que la asignación de un AIFSN mayor para los flujos BE aumenta las prestaciones obtenidas para el vídeo. Por todo ello, se puede recomendar la utilización de los siguientes valores: 7 (BK) - 5 (BE) - 3 (Vi) - 2 (Vo). Con respecto al parámetro CW min, los resultados también muestran que los valores asignados nos son adecuados. Se ha mostrado como el tráfico de voz puede beneficiarse, aumentando el valor asignado al resto de tráficos. De la misma manera, y debido a la mayor tasa de inyección, los flujos de vídeo también se verán beneficiados del aumento del tamaño de la ventana. Por todo ello, se puede recomendar el uso de los siguientes valores: 63 (BK) - 63 (BE) - 3 (Vi) - 7 (Vo). Con respeto al parámetro CW max, los resultados nos han mostrado que este no tiene un efecto muy importante en las prestaciones para los paquetes de voy y vídeo. Esto se debe a que los paquetes son descartados por deadline antes de que la ventana llegue a CW max. Finalmente se han examinado las prestaciones de la red al modificar la duración del TXOP. Los resultados han mostrado la necesidad del uso de TXOP tanto para mejorar las prestaciones de los flujos de vídeo, como para mejorar las prestaciones globales de la red. Referencias [] LAN MAN Standards Committee of the IEEE Computer Society, ANSI/IEEE Std 82., Part : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, 999 Edition. [2] IEEE 82 Committee of the IEEE Computer Society, IEEE P82.e/D3. Draft Amendment to IEEE Std 82., Part : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Medium Access Control (MAC) Quality of Service (QoS) Enhancements, April 25. [3] Opnet.Technologies.Inc. OPNET Modeler [4] IEEE 82..D-24: Standard for local and metropolitan area networks [5] Coding of Speech at 6 kbit/s using Low- Delay Code Excited Linear Prediction, Std. ITU-T Recommendation G.728, September 992. [6] ITU-T Recommendation H.264. Advanced Video Coding For Generic Audiovisual Services. May 23.