Generador de tráfico multiterminal para evaluación del rendimiento de servicios de datos en redes celulares

S. Hierrezuelo*, E. Casilari** * Tartessos Technologies, S.A., Calle Severo Ochoa, 4,

Parque Tecnológico de Andalucía, 29590 Málaga (España), Tel.: 636065727 **Dpto. Tecnología Electrónica, E.T.S.I. Telecomunicación, Universidad de Málaga, España

Campus de Teatinos, 29071 Málaga, España E-mail: salvador.hierrezuelo@tartec.com, ecasilari@uma.es

Resumen

Con el lanzamiento de nuevos servicios de datos sobre redes celulares, a los operadores de telefonía móvil les resulta necesario el uso de herramientas que permitan evaluar el rendimiento de la red y la experiencia del usuario de forma automática. Sin embargo, los procedimientos para medir ese rendimiento suelen ser costosos, pues implican un gran desplazamiento de personas y equipos a la celda de prueba si se quiere situar esa celda en unas condiciones de carga similares a las que tendrá cuando sea puesta en funcionamiento. Para solventar estos inconvenientes, se ha desarrollado la herramienta GTM (Generador de Tráfico Multiterminal) que es capaz de generar un tráfico especificado según distintos modelos estadísticos a través de múltiples terminales conectados a un ordenador y recolectar medidas a nivel de aplicación. 1. Introducción Al realizar pruebas de campo para obtener medidas del comportamiento de las redes celulares de conmutación de paquetes, es necesario generar tráfico y observar la respuesta de la red. Hasta hace poco, estas pruebas se han realizado en células reservadas para tal fin donde los encargados de las mismas generaban algún tipo de tráfico como lo haría el común de los usuarios con su terminal móvil. La realización de estas pruebas se convertía en algo tedioso y poco productivo pues sólo se conseguían extraer unos pocos estadísticos a nivel de aplicación, en muchas ocasiones medidos manualmente. En la actualidad, están empezando a surgir herramientas que permiten manejar desde un ordenador un terminal móvil usado como módem para la generación de tráfico de datos y la recogida de estadísticas. Sin embargo, aunque esto supone una mejora con respecto a la primera alternativa, es costoso tener que desplazar un ordenador portátil por cada terminal que se quiera introducir en la escena. Además, esta solución tendría una dificultad añadida si se pretendiera generar una carga agregada determinada pues obligaría a que los distintos ordenadores estuviesen sincronizados. Es aquí donde aparece el deseo de que con una sola herramienta software y un único ordenador portátil se pudieran controlar distintos teléfonos móviles y, como consecuencia, fuera posible cargar la red con el tráfico que generaría un número correspondiente de usuarios de telefonía celular. La aplicación GTM (Generador de Tráfico Multiterminal) es la respuesta a ese deseo [1]. GTM es una aplicación desarrollada en Java y que se ejecuta bajo Linux que emula la presencia real en

una red de múltiples usuarios generando tráfico de distintos servicios según un modelo estadístico. Esta aplicación presenta la novedosa capacidad de controlar distintos terminales para generar simultáneamente el tráfico deseado y permite la conexión tanto a servidores comerciales de Internet como a servidores específicos para la generación de tráfico sintético. Aunque la herramienta se diseñó inicialmente para medir el rendimiento de redes celulares [2], permite manejar desde teléfonos móviles (GPRS o EGPRS) a tarjetas de red Ethernet (LAN o WLAN). Realmente, podría concluirse que es capaz de controlar cualquier dispositivo que permita configurar una conexión a Internet desde el sistema operativo Linux. 2. Principio de funcionamiento La herramienta que se presenta en este documento, GTM (cuya ventana principal se muestra en la Fig. 1), se basa en la definición de una serie de perfiles de usuario. Un perfil de usuario viene a representar el comportamiento que tendrá cada uno de los usuarios que emula la aplicación a lo largo de la sesión. Una vez definidos los perfiles deseados, puede indicarse cuántos usuarios de cada uno de los perfiles actuarán en una sesión. Cuando la sesión se inicia, los usuarios comienzan a generar peticiones de ejecución de servicios según su perfil. Cada una de esas peticiones se almacena en el sistema de colas de la herramienta hasta que es recogida por uno de los terminales disponibles. Según esto, el número de usuarios definidos para una sesión no se ve a priori restringido por el número de terminales.

Fig. 1 Ventana principal de GTM

En la actualidad, los servicios soportados son PING, FTP y HTTP. Se eligieron estos servicios preferentemente por ser los más adecuados para medir la latencia de las redes, su capacidad de transmisión y la experiencia de usuario respectivamente. Una vez que una petición de ejecución de servicio ha sido satisfecha a través de uno de los terminales, todos los estadísticos relevantes de la ejecución de esa petición son procesados y almacenados. De esta forma, al final de la sesión, puede generarse un informe de resultados en formato html y texto que además puede ser procesado por otras aplicaciones como, por ejemplo, hojas de cálculo. 3. Perfiles de usuario Un perfil de usuario permite establecer cuál será el comportamiento a lo largo de la sesión de un determinado usuario con ese perfil. La creación del perfil de usuario implica una introducción de determinados parámetros para cada uno de los servicios soportados por GTM. En general, podría decirse que para cada servicio ha de indicarse cuál será el tiempo entre dos peticiones consecutivas y la cantidad de datos a transferir que implicará cada petición. Tanto el tiempo entre peticiones consecutivas de un servicio dado como la cantidad de datos asociada a cada petición pueden configurarse para que tomen valores fijos o sigan distintas funciones de densidad de probabilidad: Exponencial, Gamma, Pareto,

Weibull, Uniforme, Normal, Lognormal, Poisson o Rayleigh. Para cada perfil definido, puede habilitarse o deshabilitarse cualquier servicio a voluntad, de manera que un usuario con un perfil dado sólo lance servicios de un determinado tipo. Con el objetivo de dar una mayor flexibilidad, se permite configurar para cada perfil un número máximo de conexiones TCP simultáneas en el servicio HTTP para la descarga de objetos. Además, para este servicio puede seleccionarse la opción de utilizar un servidor HTTP dedicado, esto es, un servidor capaz de interpretar peticiones especiales realizadas desde la herramienta GTM y servir páginas web de los tamaños requeridos. En la Fig. 2 se muestra el cuadro de diálogo de configuración de perfiles. Por motivos de usabilidad, se incluye la posibilidad de definir grupos de perfiles. Estos grupos sirven para establecer una organización lógica de todos los perfiles que un usuario pueda crear a lo largo de su actividad con GTM. 4. Configurar una sesión Al configurar una sesión, se detallan todos los parámetros que serán empleados durante la campaña de medidas en cuestión. Entre esos parámetros están el número de usuarios (con sus correspondientes perfiles), la hora de comienzo y finalización de la sesión (si es que se desea

programarlas), la posibilidad de interrumpir la sesión si no se puede generar toda la carga especificada, las carpetas y archivos donde se almacenarán los informes resultantes, los terminales a utilizar, la configuración del sistema de colas, etc. En la Fig. 3 se muestra el cuadro de diálogo de selección de perfiles y número de usuarios para una sesión. 5. El sistema de colas de GTM GTM gestiona un sistema de colas compuesto de una cola por cada usuario de la sesión y una cola general. Las peticiones de servicio que genera el usuario van pasando de la cola de usuario a la cola general, donde son finalmente atendidas por alguno de los terminales disponibles. Cada usuario ve limitado el máximo número de peticiones de servicio generadas por él que esperan ser atendidas en la cola general o que están actualmente en ejecución. Si al generar una petición, el usuario en cuestión no sobrepasa ese límite, la petición pasa directamente de la cola de usuario a la cola general. En el caso de que se alcance el límite especificado (que puede ser configurado en el cuadro de diálogo de sesión), la petición se almacena en la cola de usuario hasta que alguna de las peticiones que se envió a la cola general sea satisfecha. Este procedimiento se ilustra en la Fig. 4. Según lo explicado en el párrafo anterior, hay una cota en el número de peticiones que pueden estar almacenadas en la cola general. Si llamamos ‘P’ al número máximo de peticiones de servicio generadas por un usuario que esperan ser atendidas en la cola general o que están actualmente en ejecución y ‘N’ al número de usuarios en la sesión, entonces el máximo número de peticiones que puede haber en la cola general (‘K’) es K = N x P. Con este sistema de colas se consigue que ningún usuario llegue a monopolizar el uso de los terminales.

Fig. 2 Configuración de perfiles

Fig. 3 Selección de perfiles y número de usuarios

Fig. 4 Sistema de colas de GTM

5.1. Seguimiento del tamaño de las colas Evidentemente, habrá peticiones de servicio que no puedan ser satisfechas inmediatamente debido a la limitación en el ancho de banda que tengan los terminales utilizados. En las situaciones en que el tráfico ofrecido es mayor que el tráfico cursado, el tamaño de la cola general (hasta un límite específico) y, especialmente, de las colas de usuario puede aumentar progresivamente. Cuando se da esta circunstancia, el usuario no está generando el tráfico tal y como especifica su perfil, ya que las peticiones han de esperar a que se satisfagan las anteriores para ser cursadas. Por este motivo, en GTM se da la opción en el cuadro de diálogo de sesión de interrumpir esa sesión cuando se detecte que el tamaño de las colas, ya sea de la general o de las de usuario, sobrepase el valor que se configure. En la Fig. 5 se muestra ese cuadro de diálogo. 6 Configuración de servidores GTM dispone de un cuadro de diálogo en el que se introducen, editan o eliminan los servidores (HTTP o FTP, por ejemplo) a utilizar para cada uno de los servicios. Cuando se introduce más de un servidor para un servicio dado, se elige uno aleatoriamente para ejecutar cada petición. Los servidores han de ser situados en lugares visibles por todos los terminales disponibles. En la Fig. 6 se muestra el cuadro de diálogo de configuración de servidores FTP.

Fig. 5 Configuración del sistema de colas

Fig. 6 Configuración de servidores FTP

Como se comentó anteriormente, existe la posibilidad de configurar un servidor HTTP comercial o uno específico para la generación de tráfico sintético. Este servidor específico contendría páginas de distintos tamaños de modo que GTM pudiera realizar la petición de una página con un tamaño dado a este servidor. El servidor conocería el tamaño de la página que ha de servir por el nombre del archivo html solicitado desde el cliente. En la Fig. 7 se muestra el cuadro de diálogo de configuración de servidores HTTP. 7 Ejecución de la sesión Durante el transcurso de una sesión, el usuario puede conocer toda la información relativa a los usuarios y terminales involucrados. Al iniciarse la sesión, se abre una ventana por cada usuario en la que se muestra información relativa a las peticiones ya cursadas o en curso. Por otro lado, se muestran los tamaños de las colas de usuario y general en una tabla y, finalmente, se muestra una gráfica de barras apiladas por cada terminal que informa del número de peticiones que ha ejecutado cada uno clasificadas según el usuario al que pertenezcan y el servicio de que se trate. En la Fig. 8 se muestra un ejemplo. Adicionalmente, hay una ventana de información general o “log” en la que se muestran eventos tales como la generación de una petición por parte de un usuario o la recogida de una petición desde la cola general por parte de un terminal. 8 Gestión de múltiples terminales La gestión de múltiples terminales conectados a Internet desde una misma máquina se complica debido a la manera en que los equipos suelen enrutar sus paquetes hacia Internet. Cuando una aplicación intenta ejecutar un servicio que funciona

sobre la capa IP, genera paquetes de este protocolo que son distribuidos hacia los adaptadores de red, que en este documento hemos denominado terminales, según la tabla de enrutamiento del sistema en que se ejecuta. En la gran mayoría de los casos, los equipos basan su enrutamiento en la dirección IP de destino del paquete, lo cual implica que dos paquetes con la misma dirección IP de destino siempre serán enviados a través del mismo adaptador de red. Según esto, una herramienta que pretendiese gestionar varios terminales que se descargasen simultáneamente, por ejemplo, una misma página web sería irrealizable pues pretendería alcanzar el mismo equipo en Internet (misma IP destino) a través de dos adaptadores de red distintos al mismo tiempo. En la Fig. 9 se muestra la tabla de enrutamiento de un sistema Windows XP que dispone de dos conexiones a Internet, una a través de su red local (interfaz Ethernet) y otra a través de una conexión telefónica (interfaz ppp). Antes de enviar un paquete IP a uno de los adaptadores de red, el sistema operativo ha de determinar cuál de las reglas (filas) de su tabla de enrutamiento aplica a ese paquete. Siguiendo el orden que se especifica en la columna “métrica”, el sistema comienza a verificar la posible aplicación de cada una de las reglas. En este sistema, se intenta aplicar primero aquellas reglas con un valor de métrica menor. Si hubiese varias reglas con el mismo valor, se aplicaría la situada en la parte superior.

Fig. 7 Configuración de servidores HTTP

Fig. 8 Gráfica de la actividad de un terminal

Fig. 9 Ejemplo de tabla de enrutamiento de Windows XP

Una regla es aplicable a un paquete IP si al hacer la operación lógica AND entre la dirección IP de destino del paquete y el campo “Máscara de red”, el resultado es el campo “Destino de red” de esa misma regla. Por ejemplo, en el caso de la Fig. 9, si se fuese a mandar un paquete con dirección IP destino 172.16.0.6, al hacer el AND lógico con la máscara de red 255.255.0.0 obtendríamos 172.16.0.0, lo cual se corresponde con la séptima regla de la tabla. Cuando se verifica que una regla es aplicable, el paquete se envía por el adaptador de red que tiene la dirección IP “Interfaz de red” de la regla y se le especifica que el siguiente salto será al equipo “Puerta de acceso”. Para el ejemplo anterior, el paquete sería enviado por el interfaz 172.16.0.5 y podría alcanzar su destino directamente. En el ejemplo de la Fig. 9 resultan especialmente interesantes las dos primeras reglas. Estas dos reglas son las salidas por defecto a Internet y sólo se aplican cuando ninguna de las otras reglas ha sido aplicable. Al hacer el AND lógico de la máscara 0.0.0.0 con cualquier dirección IP, el resultado es 0.0.0.0. Así pues, esta regla es cumplida por cualquier dirección IP destino y siempre se puede aplicar. Se observa entonces que aparecen dos salidas por defecto, las dos primeras reglas. En realidad sólo una es efectiva, la de valor “Métrica” más pequeño. De lo anterior se deduce que no es posible enviar paquetes IP a un equipo en Internet a través de dos interfaces en un mismo equipo con dos conexiones a Internet, pues en última instancia todos los paquetes han de seguir las reglas de la tabla de enrutamiento del sistema, que sólo es capaz de efectuar su labor considerando la dirección IP destino. Todos los paquetes IP saldrían siempre por el mismo interfaz de red. Por lo tanto, queda claro que se necesita algún tipo de enrutamiento más potente para poder manejar varias conexiones a Internet por las que se quiera acceder al mismo destino al mismo tiempo.

Finalmente, también ha de considerarse que cuando se establece una conexión a Internet, el equipo local debe recibir una dirección IP y todos los paquetes enviados por esa conexión han de tener como dirección IP origen la asignada en el establecimiento. Dicho esto, una herramienta que gestione múltiples terminales habría de ser capaz de generar paquetes IP con las direcciones IP fuente adecuadas para cada una de las conexiones a Internet establecidas. 8.1 La solución de GTM Conseguir que determinados paquetes IP sean enviados con las direcciones IP fuente deseadas no es difícil; basta con abrir un “socket” con la dirección IP fuente que se quiera. Sin embargo, el problema del enrutamiento que se comentó en la sección anterior es bastante más complicado de solucionar. La aplicación es capaz de distinguir qué paquetes son los que han de ser enviados por cada terminal y luego enviarlos. La manera más fácil de distinguir los distintos flujos de tráfico podría ser precisamente la dirección IP origen. Ya que los paquetes que serán enviados por una conexión (que se corresponde con un terminal) tienen todos la misma IP origen, se podría hacer una clasificación de los paquetes por esa IP origen y luego llevarlos al adaptador de red deseado. GTM lleva a cabo este proceso mediante la creación de múltiples tablas de enrutamiento usando las funciones del sistema operativo Linux. Así, en un primer momento, GTM asigna a todos los paquetes con la misma IP origen una tabla de enrutamiento, la cual contiene como salida por defecto a Internet el terminal que hayamos elegido, que será el correspondiente a la conexión que está asociada a esa dirección IP origen. De esta manera, lo que realmente lleva a cabo GTM es un enrutamiento según la dirección IP fuente de cada paquete que le permite distribuir el

tráfico IP entre los distintos terminales conectados a Internet (véase la Fig. 10). 9 Tecnologías software empleadas La aplicación GTM fue enteramente realizada con el lenguaje de programación Java debido a su portabilidad, velocidad de desarrollo y amplio soporte en Internet. Se hizo un uso intensivo de la librería Swing de Java para la realización de la interfaz gráfica [3]. El sistema operativo elegido fue Linux por su capacidad de realizar funciones de enrutamiento avanzadas. Se utilizó la distribución RedHat 9 por ser una distribución ampliamente usada, completa (incluye gran parte de los paquetes necesarios para GTM) y gratuita. Para la verificación del correcto funcionamiento de los servicios que ejecuta la herramienta, se hizo uso del analizador de protocolos de redes Ethereal, incorporado en la distribución de RedHat 9. Finalmente, para la realización de pruebas de campo, se empleó Bluetooth como medio de conexión entre el ordenador y los teléfonos móviles, ya que con un solo interfaz BlueTooth en el ordenador se pueden controlar diversos terminales. Para conseguir esa conexión entre ordenador y terminal, se usó Bluez, una conocida torre de protocolos Bluetooth para Linux [4].

10 Resultados Al término de la sesión, GTM genera una serie de informes de interés. Por un lado, genera un documento html con toda la información acerca de los parámetros con los que se ejecutó dicha sesión: perfiles de usuario, número de usuarios, horas de comienzo y final, configuración del sistema de colas, terminales utilizados, etc. De otra parte, se genera un informe html con los resultados de la ejecución de cada uno de los servicios. Este último incluye la tasa de éxito para cada servicio por usuario, histogramas con información del tamaño de las peticiones y el tiempo entre peticiones, tablas con las medidas del rendimiento para cada servicio (retardos, throughput ...), etc. Los histogramas generados resultan de utilidad para verificar en qué medida se parece el conjunto de las peticiones realizadas (en tiempo o tamaño) a una determinada función de densidad de probabilidad. 10.1 Pruebas reales En esta sección, para ejemplificar las posibilidades de la herramienta, se comentarán algunos de los resultados que se obtuvieron en dos pruebas reales. La primera se realizó en una red de área local formada por dos equipos con conexión a Internet a través de un router ADSL. La segunda fue realizada con dos teléfonos móviles para medir el rendimiento de una red celular. La primera prueba pretendía cumplir un doble objetivo: Por un lado, demostrar que la aplicación generaba peticiones de servicio según los modelos establecidos y, por otro lado, evaluar el rendimiento de la conexión ADSL. En la tabla 1 se detallan los parámetros de esta primera prueba.

Fig. 10 Enrutamiento en GTM

Tabla 1. Parámetros de configuración de la prueba 1 (ADSL)

Perfil de Usuario: TEST0 Tiempo entre envíos Tamaño de la petición PING Poisson (media 10 seg.) Rayleigh (media 100 bytes) FTP UL Poisson (media 40 seg.) Rayleigh (media 300 KB) FTP DL Determinista (30 seg.) Uniforme (100-1000 KB) HTTP Poisson (media 30 seg.) Determinista (184 KB) Número de Usuarios: 2 con perfil TEST Terminales: 1 terminal (Tarjeta de Red Ethernet) Máximo número de terminales por usuario: 1 Duración de la prueba: 1 hora Máximo número de conexiones TCP para descarga de objetos: 2 Número de objetos de la página web a descargar: 79 Como resultado de esta prueba, se obtuvieron múltiples histogramas, diagramas de sectores y tablas. Valga como ejemplo el tiempo entre peticiones de Ping para el usuario 0 que se muestra en la Fig. 11. En la tabla 2 se muestran, con carácter orientativo, los valores medios de throughput (FTP, HTTP) y retardo (PING) obtenidos. No pudo generarse toda la carga especificada debido a la limitación en el ancho de banda de la conexión ADSL. En la Fig. 12 se muestra el esquema de conexiones para la segunda prueba. Como se comentó anteriormente, esta prueba tenía el objetivo de medir el rendimiento ofrecido por la red celular de un determinado operador en una celda concreta. En este caso, se intentó ajustar la carga de tráfico para que pudiera ser cursada por dos teléfonos móviles. En la tabla 3 se detallan los parámetros de la segunda prueba. Para la realización de estas pruebas no se realizó un bloqueo de la celda, por lo tanto la presencia de otros usuarios en la misma podría haber alterado las medidas debido a la gestión de los recursos que se hace en este tipo de redes. Así pues, los números obtenidos han de manejarse con cierta precaución. En la tabla 4 se recogen los valores medios de algunos de estos resultados. 11 Conclusiones La aplicación presentada en este documento permite la generación de tráfico real correspondiente a servicios de Internet a través de los múltiples terminales que puede gestionar simultáneamente gracias a la aplicación de funciones de enrutamiento avanzadas. Con esto, es capaz de emular la presencia activa de muchos usuarios en una celda de telefonía móvil o en una red LAN o WLAN. Esta herramienta basa su generación de tráfico en perfiles de usuario que son definidos a través de modelos estadísticos. La herramienta no presenta ninguna restricción respecto a los tipos de dispositivo que es capaz controlar, siempre que éstos permitan establecer

una conexión a Internet desde el ordenador. Así pues, deja la puerta abierta al uso de cualquier otra tecnología para conectar un equipo a Internet. Agradecimientos Este trabajo ha sido financiado en parte por el Ministerio de Ciencia y Tecnología (MCYT), Proyecto No. TIC2003-07953-C02-01 Referencias [1] S. Hierrezuelo, “Estudio de la Calidad de Servicio ofrecida a Servicios de Datos en Redes Celulares”, Proyecto Fin de Carrera, ETSI Telecomunicación, Universidad de Málaga, 2004. [2] T. Halonen, J. Romero y J. Melero, “GSM, GPRS and EDGE performance”, John Wiley & Sons, 2002. [3] The JavaTM Tutorial. Disponible en: http://web2.java.sun.com/docs/books/tutorial/information/download.html [4] Bluez (Official Linux Bluetooth protocol stack). Disponible en: http://www.bluez.org/ Tabla 2. Resultados de la prueba 1 (ADSL) Retardo (ms) Throughput (bps)

PING FTP UL FTP DL HTTP 115 118343 179075 146833

Tabla 3. Parámetros de configuración de la prueba 2 (GPRS)

Perfil de Usuario: TEST1 Tiempo entre envíos Tamaño de la petición PING Poisson (media 40 seg.) Normal (µ= 64, σ=32)bytes FTP DL Poisson (media 100 seg.) Uniforme (10-50 KB) HTTP Poisson (media 60 seg.) Determinista (14 KB) Número de Usuarios: 4 con perfil TEST Terminales: 2 terminales GPRS (Nokia 3650) Máximo número de terminales por usuario: 1 Duración de la prueba: 20 minutos Máximo número de conexiones TCP para descarga de objetos: 2 Número de objetos de la página web a descargar: 4 Tabla 4. Resultados de la prueba 2 (GPRS) Retardo (ms) Throughput (bps)

PING FTP DL HTTP 1061 22420 11806

Fig. 11 Tiempo entre peticiones de Ping para la

prueba 1 (en el eje de ordenadas: número de ocurrencias)

Fig. 12 Esquema de la segunda prueba