Repositorio Institucional de Documentos

Master en Tecnologas de la Informacion y Comunicaciones en Redes Moviles Programa Ocial de Posgrado en Ingeniera de Telecomunicacion METODOLOG IA PARA EL MODELADO Y EL AN ALISIS DE FLUJOS IP MULTIMEDIA: MEDIDAS DE CALIDAD Luis E. Sequeira Villarreal Director: Julian Fernandez Navajas Ponente: Jose Ruiz Mas Departamento de Ingeniera Electronica y Comunicaciones Universidad de Zaragoza Noviembre 2011 Dedicatoria A Mara Luisa Agradecimientos Por su apoyo y nanciamiento para el desarrollo de este trabajo: Fundacion Carolina Universidad de Zaragoza Universidad Latina de Costa Rica Resumen \Metodologa para el modelado y el analisis de ujos IP multimedia: medidas de calidad" E l presente trabajo propone una metodologa para el modelado y el analisis de ujos IP multimedia que se transportan mediante tecnologas WiFi. Dicha metodologa tiene como objetivo la obtencion de modelos de traco multimedia de manera experimental y generacion de traco en entornos controlados de laboratorio para una aproximada reconstruccion de los escenarios reales. Ademas, se propone la adaptacion de todo el proceso a otros tipos de traco y la automatizacion de los mismos. En primer lugar, para la realizacion del trabajo se describen algunas de las herramientas mas utilizadas, y otras mas recientes, que permiten la captura de datos, la gestion y generacion de traco, as como el procesado de la informacion. Tambien se describen una serie de aplicaciones reales escogidas en el presente trabajo, que generan los ujos IP con requerimientos temporales entre los extremos de la comunicacion (voz, vdeo y streaming ). Por otro lado, dicha metodologa se pone a prueba para la construccion de modelos de ujos IP de voz y vdeo, obteniendo resultados que permiten generar el mismo traco sin la necesidad de la aplicacion. Tambien, se utiliza para modelar las caractersticas del escenario. Como ejemplo se realiza el modelado de un buer en un punto de acceso WiFi. En el se determinan algunas de sus caractersticas tecnicas y funcionales mas relevantes. Con dichos ujos se realizan medidas de calidad en cuanto a perdidas en entornos 802 : 11, en diferentes escenarios inhalambricos reales. Estas medidas se comparan con los valores teoricos del protocolo de acceso al medio utilizado por dicho estandar CSMA/CA ( Carrier Sense Multiple Access Collision Avoidance ) para analizar el comportamiento real y encontrar las posibles diferencias. Al nal se plantean las conclusiones obtenidas y algunas de las lneas futuras de investigacion que se relacionan con los fenomenos observados.  INDICE DE CONTENIDOS 1  Indice de contenidos  Indice de contenidos 1  Indice de guras 4  Indice de tablas 6 1 Introduccion 7 1.1 Descripcion del problema . . . . . . . . . . . . . . . . . . . . . 7 1.2 Objetivos ............................. 9 1.3 Alcances y condiciones de trabajo . . . . . . . . . . . . . . . . 9 1.3.1 Alcances.......................... 9 1.3.2 Condiciones de trabajo . . . . . . . . . . . . . . . . . . 9 1.4 Estructura de la memoria . . . . . . . . . . . . . . . . . . . . 10 1.5 Cronograma de actividades . . . . . . . . . . . . . . . . . . . . 11 2 Herramientas para la implementacion y el analisis 12 2.1 Herramientas de captura de datos . . . . . . . . . . . . . . . . 12 2.1.1 TCPDUM......................... 12 2.1.2 Wireshark......................... 12 2.2 Gestion y generacion de traco . . . . . . . . . . . . . . . . . 13 2.2.1 TCyNETEM....................... 13 2.2.2 JTG............................ 13 2.2.3 D-ITG........................... 14 2.2.4 ETG............................ 14 2.3 Virtualizacion........................... 15 2.4 Procesamiento matematico . . . . . . . . . . . . . . . . . . . . 15 3 Metodologa propuesta 17 3.1 Descripcion de la metodologa . . . . . . . . . . . . . . . . . . 17 3.1.1 Estudio teorico y planicacion de la prueba . . . . . . 17 3.1.2 Acondicionamiento del entorno de pruebas . . . . . . . 18 3.1.3 Obtencion de resultados . . . . . . . . . . . . . . . . . 19 3.1.4 Analisis de resultados . . . . . . . . . . . . . . . . . . . 19 3.1.5 Presentacion de los resultados . . . . . . . . . . . . . . 20 3.2 Adaptacion de la metodologa y automatizacion de procesos . 21 Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 1 INTRODUCCI ON 8 Para que un protocolo o tecnica de cualquier ndole se incorpore de forma operativa y permanente en una red, debe ser minuciosamente optimizado y depurado. La mejor manera de lograr esto, es realizar todas las pruebas en un entorno real, ya que de este modo se valorara todos lo efectos introducidos por los equipos, los sistemas operativos, aplicaciones y los protocolos utilizados [9]. Sin embargo, las pruebas en entornos reales dejan de ser factibles cuando la cantidad de nodos crece a niveles comparables con un entorno tpico de operacion de ciertas aplicaciones y los costes se disparan notablemente. Otra opcion que comunmente se utiliza en la simulacion de entornos de redes, en este ambito se encuentran diversas aplicaciones que facilitan esta labor, este es el caso de OPNET [10], NS-2 [11], Glomosim, entre otros. Los simuladores presentan la ventaja que facilitan la realizacion de las pruebas, la escalabilidad del sistema, ademas de garantizar de manera agil la repetibilidad de las mismas, por otro lado, reducen enormemente los costes. Sin embargo, presentan la desventaja del alto consumo de recursos computacionales y que no toman en cuenta los sistemas operativos ni las aplicaciones que se desean analizar. Otra de las tecnicas a las que los investigadores recurren es a la emulacion de entornos de red [12], [13] y [14]. En este caso se hace uso de maquinas virtuales con sistemas operativos completos y las aplicaciones que se deseen, por lo que el traco presenta los efectos del sistema operativo y las aplicaciones utilizadas. Queda claro que las medidas del traco, el desarrollo de protocolos y el analisis de calidad en entornos de red es un contexto que manejan los centros de investigacion de diferente manera, sin embargo, los procedimientos empleados para el modelado y analisis en los deferentes entornos de pruebas tienen mucho en comun, a pesar que la tecnica utilizada sea diferente. Es por este motivo que surge la necesidad de una serie de procedimientos, que contemplados en una metodologa, brinden los aspectos necesarios para el modelado de diferentes tipos de traco, que permita el analisis transparente de diversas aplicaciones y que sea facilmente adaptable a cada una de las tecnicas utilizadas por los investigadores. Por otro lado, que facilite, de manera sistematica, el analisis de la calidad de los enlaces de red Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 1 INTRODUCCI ON 9 y el impacto de la variacion del traco en ellos. 1.2 Objetivos 1. Obtener los procedimientos necesarios para la realizacion de medidas en diferentes escenarios de red, que permitan modelar sus tecnologas y las aplicaciones utilizadas. 2. Realizar medidas de traco de ujos IP en diferentes escenarios de red comunmente utilizados por empresas y grupos de investigacion con la nalidad de determinar su calidad. 3. Proponer una metodologa para modelar y analizar la calidad de ujos IP con restricciones temporales en distintos escenarios de red. 1.3 Alcances y condiciones de trabajo 1.3.1 Alcances El presente trabajo tiene como nalidad brindar una metodologa que permita el analisis y modelado de ujos IP. Dicha metodologa facilitara a los investigadores, la obtencion de medidas en entornos de red, ademas, se adapta a diversas tecnicas y tecnologas comunmente utilizadas por departamentos de investigacion. 1.3.2 Condiciones de trabajo Las pruebas realizadas a lo largo de este trabajo se realizan con el objetivo de demostrar la veracidad de la propuesta planteada, ademas, han ayudado a depurar y corregir dicha propuesta. El desarrollo de este trabajo se realiza en el Grupo de Tecnologas de las Comunicaciones (GTC) de la Universidad de Zaragoza, por lo tanto, la infraestructura, los equipos y las herramientas utilizadas se limitan a la disponibilidad de las mismas, por parte de dicho grupo de investigadores. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 1 INTRODUCCI ON 10 1.4 Estructura de la memoria El presente trabajo consta de siete secciones, la primera describe el problema de estudio, plantea los objetivos del trabajo, los posibles alcances y el entorno en el cual se desarrolla. La segunda seccion describe las principales herramientas utilizadas para el analisis y la implementacion de las pruebas realizadas. Posteriormente, en la tercera seccion, se propone una metodologa para el analisis y el modelado de ujos IP multimedia en tiempo real, de la cual se extrae un procedimiento que se puede consultar en el apendice B. La seccion cuatro y cinco muestra la obtencion de los modelos de VoIP, vdeo de televigilancia, streaming y de buer utilizando la metodologa planteada. La seccion seis presenta una serie de medidas que se pueden realizar en diferentes escenarios de red para el analisis de la calidad utilizando los modelos anteriormente obtenidos. En la seccion siete se presentan las conclusiones y las futuras lneas de investigacion. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 1 INTRODUCCI ON 11 1.5 Cronograma de actividades Tabla 1: Cronograma de actividades. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 2 HERRAMIENTAS PARA LA IMPLEMENTACI ON Y EL AN ALISIS12 2 Herramientas para la implementacion y el analisis A spectos como la repetibilidad y la exactitud estan estrechamente ligados a los entornos de pruebas y de analisis cientco. Los investigadores tienen la necesidad de reproducir de manera exible y escalable, diversos tipos de pruebas para diferentes condiciones en entornos controlados que permitan el analisis de los fenomenos estudiados, como mencionan algunos autores [9] y [12]. Por esto es necesario escoger un conjunto de herramientas que permitan facilitar la obtencion de resultados para su posterior analisis. Dichas herramientas deben de ser seleccionadas con mucho cuidado ya que de ellas dependera en cierta medida la exactitud de los datos obtenidos. 2.1 Herramientas de captura de datos 2.1.1 TCPDUM TCPDUMP [15] es una herramienta para captura del traco que circula por la red en tiempo real (de los paquetes transmitidos y recibidos en una determinada interfaz de red). Dicha herramienta carece de interfaz graca, esto lo convierte en una de las aplicaciones preferidas cuando se quiere usar los mnimos recursos posibles [6], ademas, de ser idonea para la captura de paquetes en forma desatendida, ya que se gestione por lnea de comandos. Esta aplicacion se encuentra disponible para casi todos los sistemas operativos (en Windows se llama WinDUMP ), hace uso de la librera libpcap en el casos se sistemas UNIX y winpcap para Windows, ademas, es la encargada de las capturas de paquetes. Esta herramienta permite la depuracion de la salida obtenida por medio de ltros, permitiendo ltrar capturas de puerto especco, o ltrando por tipo de protocolo, direccion origen o destino, en una interfaz en especco y otros. 2.1.2 Wireshark Wireshark [16] es un programa de analisis, mantenido bajo licencia GNU GPL ( GNU General Public License ), tambien hace uso de las mismas Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 2 HERRAMIENTAS PARA LA IMPLEMENTACI ON Y EL AN ALISIS13 libreras de captura de paquete de las que se utilizan en TCPDUMP, dependiendo del sistema operativo. A diferencia de TCPDUMP, Wireshark permite su gestion mediante una interfaz graca amigable con el usuario sin la posibilidad de una gestion desatendida, ademas, posee funciones de ltrado y analisis de traco. Es compatible con el formato de archivo que utiliza TCPDUMP y reconoce una gran cantidad de protocolos. Otra caracterstica interesante para los investigadores es que permite la exportacion de los archivos de capturas a diferentes formatos de aplicaciones orientadas al analisis matematico o de bases de datos, algo que puede resultar util para realizar un analisis mas detallado, como por ejemplo, calculos de retardos, MOS, estadsticas y otras magnitudes que se puedan extraer de la captura de paquetes en la red. 2.2 Gestion y generacion de traco 2.2.1 TC y NETEM TC permite la gestion del traco en una interfaz determinada [5], [14], [9] y [12], limita el traco a un ancho de banda determinado haciendo una gestion de colas, clases y ltros de manera que se controle la forma con la se enva o reciben datos. NETEM [17] Network Emulator es un emulador de red que esta contenido en el kernel de linux a partir de la version 2.6.7, por lo que todas las versiones actuales de linux poseen dicha aplicacion integrada. NETEM es una extencion de TC ( Trac Control ), la herramienta de control de traco de linux, la cual esta contenida en el paquete iproute2 . NETEM permite introducir retardos y perdidas sobre la transmision de paquetes en una interfaz determinada [12]. 2.2.2 JTG El JTG ( Jugi's Trac Generator ) es un generador de traco IP gestionado por lnea de comandos, desarrollado por la Universidad de Helsinki [18], permite generar traco parametrico y reproducir traco a partir de archivos con intervalos de tiempo y tama~nos de paquetes a enviar en cada intervalo de tiempo [14]. Por otro lado, provee un receptor para recoger el traco, a Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 2 HERRAMIENTAS PARA LA IMPLEMENTACI ON Y EL AN ALISIS14 partir del cual se pueden calcular estadsticas. El JTG incluye un programa llamado jtg calc que a partir del log de paquetes recibidos realiza un analisis estadstico de perdidas, retardos y jitter. 2.2.3 D-ITG Otro generador de traco IP multiprotocolo, desarrollado por la Universidad de Napoles, es el D-ITG [19]. Este generador tambien permite el analisis de los datos enviados o recibidos, as como realizar capturas en ambos extremos de la comunicacion, ademas, permite realizar medidas en un solo sentido OWD ( one-way-delay ) y de ida y vuelta RTT ( round-trip-time ) [12] y [13]. Puede ser gestionado mediante lnea de comandos o por medio de GUI ( Graphical User Interface ) que puede ser obtenida en la misma pagina web del proyecto. 2.2.4 ETG Recientemente, en el GTC (Grupo de Tecnologas de la Comunicacion) de la Universidad de Zaragoza, grupo en el cual se desarrolla el presente trabajo, se ha implementado una herramienta denominada ETG ( E2E Trac Generator ) [20], inicialmente implementada para el analisis de enlaces en el transporte de voz sobre IP y que actualmente se ha generalizado para generar los de ujos IP del trabajo. Esta herramienta permite calcular parametros objetivos (retardo, jitter, y tasa de perdidas) y subjetivos de QoS (factor R, MOS). Se trata de una herramienta capaz de realizar comunicaciones E2E entre usuarios mediante el envo y recepcion de varias secuencias de rafagas de traco UDP. Permite generar traco OWD y RTT, as como capturas en ambos puntos de la comunicacion, ademas, mediante el analisis del traco recibido se obtienen los parametros de retardo, perdidas y jitter, con los cuales podemos calcular el factor R que determina el MOS para cada comunicacion. Una ventaja de esta aplicacion es la facilidad que presenta para la repetibilidad de la pruebas ya que contempla mecanismos que permiten la automatizacion de ciertas funciones facilitando el trabajo a los investigadores, como por ejemplo: cada ujo se podra reiterar cada cierto tiempo entre una fecha y hora inicial y nal, generar traco equivalente al de diferentes Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 2 HERRAMIENTAS PARA LA IMPLEMENTACI ON Y EL AN ALISIS15 servicios, permite el envo de paquetes a partir de un chero con los intervalos de transmision de paquetes y el tama~no, permite emular comunicaciones cuando los tiempos y tama~nos de paquete no son constantes y nos garantiza poder repetir las pruebas en las mismas condiciones. 2.3 Virtualizacion La virtualizacion presenta una serie de ventajas, para algunos autores [9], [11] y [12], a la hora de realizar emulaciones de redes, dentro de ellas destacan la reduccion de costes, espacio y recursos, ademas que permite una administracion centralizada y simplicada por parte del investigador. Por otro lado, en [21] se encuentra una descripcion de las principales opciones de virtualizacion que algunos autores mencionan. En el ambito de investigacion es necesario que las maquinas virtuales consuman la mnima cantidad de recursos, que sean rapidas para poder adaptarse a cualquier escenario de prueba y que sean lo mas cercano posible a una maquina real. La interaccion entre los sistemas operativos, tanto antrion como huesped, debe ser lo mas eciente posible para que el software que gestiona la interaccion de cada huesped con el hardware no consuma recursos excesivos para la ejecucion de ciertas instrucciones. En estos casos, es recomendable utilizar entornos de paravirtualizacion, en este ambito, algunos autores [4], [7] y [22] han desarrollado sus investigaciones emulando escenarios de red en diversos contextos, para ello se han apoyado en Xen ya que en el grupo de investigacion se utiliza este entorno de virtualizacion. Xen presenta varias ventajas [23] frente a otro entornos de virtualizacion, entre ellos VMware ESXi, Hyper-V y KVM. Uno de los aspectos que destaca es que no hace utilizacion de drivers por lo que permite mantener aislados los sistemas huesped, ademas, al mantener los sistemas huesped aislado brinda cierto nivel de seguridad, as como los privilegios de acceso y la separacion de los sistemas operativos. 2.4 Procesamiento matematico La complejidad de algunas operaciones matematicas o la gran cantidad de repeticiones de calculo necesarias para el procesado de cierta informacion Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 2 HERRAMIENTAS PARA LA IMPLEMENTACI ON Y EL AN ALISIS16 hace necesario herramientas para este tipo de situaciones. Matlab es una herramienta de software que ofrece un lenguaje de programacion (lenguaje M) para este tipo de ambientes. Es desarrollado por MathWorks desde el a~no 1984 y esta disponible para las plataformas Unix, Windows y Apple Mac OS X. A pesar de haber sido altamente difundido en universidades y centros de investigacion y desarrollo en los ultimos a~nos, es un producto propietario de MathWorks y por lo tanto sujeto a licencia. Sin embargo, existen alternativas de libre distribucion y codigo abierto como GNU Octave y Scilab que tienen buena compatibilidad con dicho lenguaje. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 3 METODOLOG IA PROPUESTA 17 3 Metodologa propuesta 3.1 Descripcion de la metodologa L a metodologa utilizada en las pruebas realizadas se resume en cinco fases principales que se detallan a continuacion:  Fase 1: Estudio teorico y planicacion de la prueba  Fase 2: Acondicionamiento del entrono de pruebas  Fase 3: Obtencion de resultados  Fase 4: Analisis de resultados  Fase 5: Presentacion de los resultados Ademas, se puede revisar el apendice B que contiene un procedimiento de tallado de las tareas realizadas para la obtencion de modelos de traco IP para ujos multimedia. 3.1.1 Estudio teorico y planicacion de la prueba La planicacion consiste en una etapa de adquisicion de informacion a cerca del fenomeno que se desea analizar y de las herramienta y aplicaciones involucradas en el proceso. En concreto, en esta fase inicial se debe obtener toda la informacion del objeto de estudio que permita seleccionar cuales aplicaciones se deben elegir para obtener modelos de diversos ujos IP. Posteriormente, se debe realizar un listado de los elementos, dispositivo o equipos necesarios para la implementacion de un escenario que involucre todos los aspectos de una red real y su correspondiente topologa. Dependiendo de los alcances y los objetivos de la investigacion sera necesario realizar una segregacion de las tareas a realizar por grupos de trabajo, detallando los objetivos especcos y las tareas a realizar, ademas, es conveniente la elaboracion de un cronograma de actividades que permita supervisar las actividades y tareas a realizar. Por otro lado, las herramientas asociadas a la obtencion de datos, captura de paquetes, as como, las relacionadas al analisis de la informacion deben ser Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 4 MODELADO DE FLUJOS IP MULTIMEDIA 24 la llamada esta en curso y se analizan los resultados de dichas capturas. VoIP utiliza el protocolo RTP para la transmision de datos en tiempo real y este se transporta por medio de UDP, la gura 21 permite comprobar la utilizacion de los protocolos mencionados. Ademas, destaca en el analisis de las capturas de paquetes realizadas, que la transmision de cada uno de los paquetes tiene una distribucion constante (no se presentan rafagas de paquetes), determinandose que cada terminal realiza el envo de paquetes cada 20 ms y que el contenido de datos de dichos paquetes corresponde con el tipo de codec utilizado ( G: 729) y la cantidad de muestras que se denieron en la conguracion de cada gateway . Ademas, en la gura 2 se puede observar la variacion de la duracion de cada paquete para el traco enviado y recibido de voz en funcion del tiempo de transmision. Para las muestras tomadas en este caso se presenta un tiempo medio de envo de paquetes de 20 ms con una desviacion estandar de 0 : 62 ms . Cada conexion de este ujo tienen un consumo de ancho de banda a nivel IP BW = (60  8) = 20  10  3 , lo que equivale a 24 Kbps . Figura 2: Detalle del tiempo entre los inicios de cada paquete para el traco de voz. El modelo de la transmision de voz es relativamente sencillo y estable en cuanto a tiempos y tama~nos ya que no presenta un comportamiento de rafagas, o bien, puede verse como una sola. Representar un ujo IP de este Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 4 MODELADO DE FLUJOS IP MULTIMEDIA 25 tipo consiste en el envo de paquetes de 60 byte (incluyendo las cabeceras, ver gura 21) cada 20 ms con una desviacion estandar de 0 : 62 ms , esto si se utiliza el codec G: 729 y una paquetizacion de dos muestras por paquete. En el caso de que sea necesario el cambio del codec o la cantidad de muestras por paquete, los cambios son sencillos de representar, se debe tener en cuenta la frecuencia de muestreo denida en el nuevo codec utilizado y las muestras que se deseen empaquetar se incluiran despues del encabezado RTP (ver gura 21). 4.2.2 Modelo de video para televigilancia En este caso, la obtencion del modelo de traco se realiza con un escenario como se muestra en la gura 3. La estacion de trabajo puede tener acceso a la camara IP (AXIS 2120) de manera remota por medio de un navegador web tradicional, la camara utilizada puede ser congurada para un ancho de banda de 1 o 2 Mbps , segun sea necesario dependiendo del enlace al que se tenga acceso, el snier capturara paquetes durante la transmision de datos. Figura 3: Escenario utilizado para determinar el traco de vdeo. Para modelar este tipo de traco es necesario analizar aspectos mas detallados de la conguracion, ya que el comportamiento del ujo de datos diere en funcion de la conguracion que permita el fabricante para este tipo de aplicacion, uno de los factores que tienen relevancia en este caso es el factor de compresion que se dena para la transmision (ver tabla 2). Ademas de la inuencia en la calidad de la imagen percibida por el usuario, el nivel de compresion que se dena afectara en forma directa el comportamiento del Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 4 MODELADO DE FLUJOS IP MULTIMEDIA 26 ujo de paquetes en la red. Por ultimo, otros aspectos se relacionan con el tama~no de la imagen (en pixeles ) y el ancho de banda denido en la camara. El nivel de compresion dene el tama~no de la imagen (en bytes ) que la camara transmite en cada instante, cada imagen tiene un tama~no diferente por lo que el ultimo paquete de cada rafaga, tendra un tama~no menor que los demas, mientras que el resto seran de 1500 bytes , sin embargo, la cantidad de paquetes se mantiene constante para cada caso (excepto en uno de ellos), esto se aprecia en la tabla 2. Resoluci  on Niveldecompresi  on Cantidaddepaquetes 704  576 pixeles 50 Kbytes 25 16 Kbytes 10 352  288 pixeles 13 Kbytes 7  9 4 Kbytes 3 Tabla 2: Cantidad de paquetes por rafaga en funcion de la compresion para camara. El ujo de los paquetes se presenta en forma de rafagas para todos los casos estudiados, cada rafaga transmite la cantidad de paquetes que el nivel de compresion dene (ver tabla 2), esto se muestra en la gura 4, donde el tiempo entre las llegadas de las rafagas es el lapso en el cual se transmite la cantidad de paquetes; de forma analoga, existe un tiempo entre las llegadas de cada paquete contenido en la rafaga que dene la diferencia entre los inicios de cada paquete. Figura 4: Relaciones de tiempos entre los inicios de cada paquete y de rafagas para una compresion de 50 Kbytes . Las capturas de datos se realizan para cada uno de los niveles de compresion que se muestran en la tabla 2, por otro lado, se estudia el caso de baja Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 4 MODELADO DE FLUJOS IP MULTIMEDIA 27 compresion (50 Kbytes ), ante cambios en el ancho de banda (permitido por el fabricante) denido en la conguracion de la camara. En este caso se analizan tres casos, estos se muestran en la tabla 3, el primero, sin movimiento (Vdeo A), con poco (Vdeo B) y mucho movimiento (Vdeo C) frente a la camara. Tr  afico Paquetes Tiempo r  afagas ( ms ) Cantidad Tama ~ no ( bytes ) 75 80 110 120 140 160 200 V  ideo A 10 1500 12 : 85& 47 : 35% 39 : 8% 1 500  800 V  ideo B 24 1500 7 : 12% 30 : 65% 54 : 9% 9 : 29% 1 700  1300 V  ideo C 37 1500 42% 52% 11% 14 : 3% 4% 1 200  1300 Tabla 3: Resumen de los modelos obtenido para vdeo. Figura 5: Detalle del tiempo entre los inicios de cada rafaga para una compresion de 50 Kbytes . En el caso donde no se presenta movimiento los diferentes tiempos entre los inicios de las rafagas se mantienen en los valores que se muestran (75 ms , 110 ms , 140 ms aproximadamente), en los caso donde se presenta Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 4 MODELADO DE FLUJOS IP MULTIMEDIA 28 movimiento los tiempos entre inicios de las rafagas presentan mayores variaciones, esto se aprecia mejor en las guras 6, 7 y 8. Figura 6: Distribucion de rafagas en funcion de su duracion para una compresion de 50 Kbytes sin movimiento. Figura 7: Distribucion de rafagas en funcion de su duracion para una compresion de 50 Kbytes con poco movimiento. En la gura 5 se presentan los resultados correspondientes a la compresion 50 kbytes y poco movimiento, en dicha gura se observa la duracion entre Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 4 MODELADO DE FLUJOS IP MULTIMEDIA 29 los inicios de cada paquete, ademas, muestra las variaciones de los tiempos entre los inicios de las rafagas denidos en valores de 80 ms , 120 ms , 150 ms , 200 ms y 240 ms aproximadamente. La distribucion en funcion de la duracion de cada rafaga se muestra en las guras 6, 7 y 8. Dichos histogramas permiten visualizar una clara agrupacion de la duracion entre los inicios de cada rafaga. Los tiempos entre los inicios de cada paquete dependeran de la disponibilidad del procesador y la velocidad del enlace, sin embargo, se ha observado en el 1 : 32% de los casos para las transmisiones con movimiento moderado, que el ultimo paquete de cada rafaga presenta una duracion de 40 ms . Figura 8: Distribucion de rafagas en funcion de su duracion para una compresion de 50 Kbytes con mucho movimiento. El traco de vdeo se caracteriza por una agrupacion de paquetes dentro de un determinado rango de tiempo denido o rafaga. Para modelar el traco de vdeo que transmite la camara se debe generar un archivo que tenga como contenido los tama~nos y tiempos de transmision de cada paquete, segun la probabilidad de que un paquete este contenido en un rafaga determinada (ver guras 6, 7 y 8 y tabla 3), ya que dentro de las caractersticas analizadas para este tipo de ujo, lo tama~nos de todos los paquetes no son iguales, ademas, las variaciones en los tiempos entre rafagas son bastante amplias, por lo que es necesario obtener una distribucion estadstica de dichos tiempos. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 4 MODELADO DE FLUJOS IP MULTIMEDIA 30 En el apendice D.4 y en el D.5 se muestra como generar los archivos de texto correspondientes a los modelos de vdeo para una compresion de 4 Kbytes y 50 Kbytes respectivamente. En resumen, se puede decir que dichos script representan los histogramas de las rafagas de cada una de las capturas correspondientes (ver guras 6, 7 y 8), ademas de los tama~nos y tiempos entre los inicios de cada paquete. 4.2.3 Modelo de streaming Para modelar el traco streaming se utiliza un escenario como el que de presenta en la gura 9. Figura 9: Escenario utilizado para determinar el traco streaming. Analizando las capturas realizadas, se determina que el traco streaming no tiene un comportamiento uniforme, las rafagas tienen grandes diferencias en cuanto a los tiempos entre los inicios entre ellas, como se puede apreciar en la gura 10. Las rafagas producidas durante la transmision presentan variaciones en la duracion de las mismas, sin embargo, es claro que los paquetes tienen un tama~no de 1370 bytes , las rafagas se caracterizan por mantener un periodo de inactividad antes del inicio de la proxima rafaga, los tiempos entre los inicios de rafagas dieren, sobrepasando en algunos hasta 1 : 5 s . El tama~no de los paquetes es el mismo en todos los casos, como era de esperarse por el uso de Transport Stream , ya que cada stream elemental tiene un tama~no jo de 188 bytes [25] y los paquetes IP deben contener multiplos de estos, por lo tanto el mayor tama~no posible sera de 1370 bytes . Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 4 MODELADO DE FLUJOS IP MULTIMEDIA 31 Figura 10: Distribucion de traco transmitido por el servidor. El modelo de streaming diere en buena medida de los dos casos anteriores, este se caracteriza por una gran dispersion en cuanto a los tiempos entre los inicios de las rafagas. Sin embargo, la reproduccion del traco se puede realizar de manera similar que con el vdeo, generando un archivo similar al mencionado anteriormente, pero cambiando en el script D.5 las rafagas que se han denido y agregando nuevas rafagas y duraciones de rafagas en funcion de la distribucion que se presenta en la gura 10, en este caso se recomienda comparar los histogramas que representan la distribucion de las rafagas generadas con las capturadas para corroborar que dichos histogramas sean similares, como se muestra al nal de dicho script . Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 5 MODELADO DEL BUFFER EN UN PUNTO DE ACCESO 32 5 Modelado del buer en un punto de acceso 5.1 Dimensionado de buer I nternet es un conjunto descentralizado de redes de comunicacion, de tal manera que la arquitectura es bastante heterogenea. Los nodos de red dieren en cuanto a capacidad, por mencionar un caso, las velocidades de entrada y salida de un router pueden tener grandes diferentes, mientras de manera interna, una red domestica, puede tener una velocidad de hasta 54 Mbps (con un punto de acceso WiFi), la conexion hacia su proveedor de acceso a Internet puede ser de 8 Mbps (caso comun en ADLS), el mismo caso se presenta en la interconexion de grandes ISP ( Internet Service Providers ) o en Puntos de Intercambio de Internet ( Internet eXchange Point ) con tasas de velocidad mayores. Otro de los posibles escenario es la conexion entre dos redes LAN de 100 Mbps por medio de un enlace inalambrico de 54 Mbps , este caso se analizara con mayor detalle mas adelante. Estas diferencias entre las velocidad de entrada y de salida producen cuellos de botella donde se pueden producir perdidas de paquetes. Los router utilizan buer para reducir las perdidas de paquetes absorbiendolos cuando estos no pueden ser reenviados en ese preciso instante, tambien, se utilizan como instrumentos que ayudan a mantener los enlaces con un alto grado de utilizacion en casos de congestion. Desde 1994, en [26] se propuso la denominada rule of thumb , la cual fue aceptada por muchos investigadores, para establecer el tama~no de los buer en los router . La idea principal era la utilizacion al 100% del ancho de banda, asegurando una cantidad de paquetes almacenados que pueda mantener ocupado el canal cuando inicie el descarte de paquetes, mientras, TCP reacciona bajando la tasa de transmision. Esta regla, se resume en la ecuacion 1, la cual dene el tama~no del buer , B , como el producto del ancho de banda del enlace, C , por el retardo de ida y vuelta, RTT . B = C  RTT (1) La ecuacion 1 se obtuvo utilizando 8 ujos TCP en un enlace de 40 Mbps , Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 5 MODELADO DEL BUFFER EN UN PUNTO DE ACCESO 33 que en la actualidad no son datos representativos del traco en una red, por ejemplo, una capacidad de 40 Gbps , y un RTT de 250 ms , se obtendra un tama~no del buer de 1 : 25 Gbytes que es un tama~no muy grande, ademas, no se tomo en cuenta el caso de ujos con RTT diferentes. En 2004, esta regla fue puesta en duda, por el llamado Stanford model [27], que reduce el tama~no del buer , dividiendolo por la raz cuadrada del numero N de ujos TCP, como se muestra en la ecuacion 2. Esto se debe a que la ausencia de sincronizacion entre los ujos permite realizar una aproximacion. B = C  RTT p N (2) Esta nueva aproximacion se realiza bajo el supuesto de que la duracion de los ujos es larga y el numero de ujos es lo sucientemente grande como para considerarlos asncronos e independientes. Usando esta aproximacion, un router que gestione 10 : 000 ujos solamente necesitara 12 : 5 Mbytes de tama~no de buer . A este modelo se ha denominado small buer [28]. Debido al modelo propuesto por [27] se generaron una serie de investigaciones en este ambito. En [29] se propuso la utilizacion de buer todava mas peque~nos, denominados tiny buer , que consideran que un tama~no de entre 20 y 50 paquetes (que equivale a algunas decenas de Kbytes ) es suciente como para alcanzar una utilizacion de entre el 80% y el 90%. Esto, basado en el hecho que los ujos no estan sincronizados y el traco no presenta rafagas, sin embargo, muchos de los ujos IP en tiempo real son denidos por un comportamiento de rafagas como por ejemplo el streaming de vdeo, esto deja un poco de incertidumbre en cuanto a los modelos de dimensionado de buers . Por otro lado, son poco los trabajos realizados teniendo en cuenta servicios de tiempo real, que es uno de los principales objetivos del presente trabajo. En [1], [30] han considerado el traco combinado TCP y UDP en buer peque~nos, descubriendo una region anomala (ver gura 11), en la que las perdidas de paquetes de UDP crecen con el aumento del tama~no del buer . Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 6 MEDIDAS DE CALIDAD 40 6 Medidas de calidad A continuacion se presentan una serie de medidas basadas en entornos reales y con tecnologa WiFi. Las medidas consisten en valorar la cantidad de conexiones que se pueden establecer sin perdidas de datos, en los escenarios que se plantean mas adelante. Los ujos IP utilizados para las pruebas son los modelos de voz y vdeo de televigilancia, que se han obtenido durante el presente trabajo. Las pruebas presentadas se realizan tratando de mantener un maximo control de cada uno de los entornos de pruebas y de los equipos utilizados. Por otro lado, se ha realizado un escaneo de las celdas WiFi adyacentes que se encontraban operando a la hora de las pruebas, con la nalidad de seleccionar el canal que presente la menor interferencia para realizar las pruebas. El procedimiento que se ha utilizado se puede consultar en el apendice B. La generacion de traco se realiza con la herramienta ETG, ya que ha sido desarrollada en el grupo de investigacion donde se realiza el presente trabajo. Ademas, el traco generado es en todo momento UDP y en un solo sentido ( one way ), esto se detalla en la seccion 6.5. La captura de paquetes es gestionada por el generador de traco mencionado, el cual hace uso de TCPDUMP con este n. Ademas se verica que cada una de las capturas sea correcta. Para el analisis y procesamiento de la informacion se utiliza Matlab. Con la nalidad de tener un valor de referencia con el cual comparar los resultados obtenidos por las medidas, se ha realizado el calculo teorico de la cantidad de conexiones que se pueden obtener en 802 : 11 en modo ad-hoc para diferentes anchos de banda. La tabla 5 muestra los calculos obtenidos, suponiendo un enlace en modo ad-hoc, para el traco en un solo sentido ( one way ) y traco de ida y vuelta ( round trip ) en funcion del ancho de banda (ver apendice C.4). Ademas, para cada caso se ha realizado el calculo tomando como valores medios 0, 15 : 5 y 31 slots de backo , lo que generara una cantidad de conexiones mnima, media y maxima, respectivamente. La diferencia entre el traco de vdeo y voz se tienen en cuenta el ancho de banda y el tama~no de las tramas. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 6 MEDIDAS DE CALIDAD 41 Tr  afico BW ( Mbps ) Cantidaddeconexiones Roundtrip Oneway M  inimo Medio M  aximo M  inimo Medio M  aximo V oz 1 5 7 8 11 14 17 2 7 10 14 15 20 29 5 : 5 9 13 24 19 27 48 11 10 15 30 20 31 60 24 10 16 34 21 33 68 54 11 17 37 22 34 74 V  ideo 1 0 0 0 1 1 1 2 0 0 1 1 1 2 5 : 5 2 2 2 4 4 5 11 3 3 4 6 7 9 24 4 6 8 9 12 17 54 5 8 13 11 16 27 Tabla 5: Cantidad de conexiones de VoIP y video para diferentes anchos de banda. Para el caso de voz, se utiliza codec G 729 [2] para una paquetizacion de dos muestras por paquete, para vdeo la longitud del paquete se estima en 1500 bytes . Figura 16: Cantidad de conexiones VoIP para un enlace WiFi en modo adhoc en funcion del ancho de banda del canal con un backo de 15 : 5 slots . La gura 16 muestra el crecimiento de la cantidad de ujos de voz en funcion Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 6 MEDIDAS DE CALIDAD 42 del ancho de banda de un canal para un backo medio (15 : 5 slots ). Es claro el rapido crecimiento, hasta un punto que el aumento de las conexiones se estabiliza. Por ejemplo, en el caso de un ancho de banda de 11 Mbps se alcanzan 15 conexiones, pero si se aumenta el ancho de banda hasta 54 Mbps (casi 5 veces mas) solo se ganan dos conexiones mas para el caso de round trip . 6.1 Prueba en un enlace en modo ad-hoc Para este caso se toman dos estaciones de trabajo con identicas caractersticas de hardware y software . La conguracion de la red (ver gura 17) se realiza por lnea de comando en cada una de las estaciones, se comprueba el funcionamiento en modo ad-hoc y se realizan una serie de pruebas preliminares. Figura 17: Enlace WiFi entre dos estaciones de trabajo en modo ad-hoc. Con el modelo obtenido en la seccion 4.2.1 se realizan pruebas de voz y progresivamente se aumenta la cantidad de conexiones en cada una de las pruebas hasta llegar al lmite maximo permitido; que para el caso de voz es de 58 conexiones, por lo tanto, estos ujos tienen un consumo de ancho de banda de BW = 58  (60  8) = 20  10  3 , lo que equivale a 1 : 392 Mbps . En la conguracion de la tarjeta de red (802 : 11 b=g ), esta gestiona de forma automatica la norma ( b=g ) y por lo tanto el ancho de banda. El numero de conexiones obtenido supera la media, pero no el maximo permitido, como se puede ver en la tabla 5. Estos resultados suponen que el tiempo de backo ha sido menor al valor medio esperado, o bien nulo, el protocolo de acceso al medio no hace uso del backo o la cantidad de slot que ja es bastante peque~no. Por otro lado, se realiza la misma prueba pero con traco de vdeo, el cual fue obtenido en la seccion 4.2.2 y reproducido mediante el apendice D.4, Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 6 MEDIDAS DE CALIDAD 43 para este caso se pudo obtener un maximo de 13 conexiones con la misma conguracion y el ancho de banda sera BW = 13  (3  1500  8) = 40  10  3 , lo que equivale a 11 : 7 Mbps . El aumento de ancho de banda se debe a que se usan tramas de mayor tama~no. 6.2 Prueba en el enlace entre el punto de acceso y una estacion de trabajo En la gura 18 se muestra la segunda prueba realizada, en el enlace inalambrico entre un punto de acceso y una de las estaciones base. Las medidas se basan en la premisa de que las posibles perdidas se presentaran en el enlace inalambrico ya que la conexion entre el punto de acceso y la otra estacion de trabajo tiene una capacidad muy superior. La conguracion del punto de acceso se caracteriza por establecer una velocidad maxima de 1 Mbps en modo 802 : 11 g (para el primer caso, incrementandose en cada prueba), se inhabilita el modo CTS, el beacon interval es de 100 ms y se utiliza diversidad. Figura 18: Enlace WiFi entre una estacion de trabajo y un punto de acceso. Ademas, se realizan pruebas con 802 : 11 b obteniendo los mismos resultados para los casos donde los anchos de banda son los mismos que 802 : 11 g (11 Mbps o menos). La tabla 6 muestra los resultados obtenidos en relacion con los valores teoricos calculados con un backo medio (15 : 5 slots ). Los valores de voz obtenidos muestran que para los anchos de banda mayores 5 : 5 Mbps (inclusive), la cantidad de conexiones supera las expectativas de los valores medios, pero siempre dentro de las posibles lmites maximos. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 6 MEDIDAS DE CALIDAD 44 Ademas, los resultados son comparables, a pesar de tener un escenario diferente, con otros estudios realizados por [5] y [12] en los que se obtienen los mismos resultados para el caso de 1 Mbps . Tr  afico BW ( Mbps ) Cantidaddeconexiones Teorico Experimental M  inimo Medio M  aximo Conexinoes BW ( Mbps ) V oz 1 11 14 17 12 0 : 288 2 15 20 29 16 0 : 384 5 : 5 19 27 48 32 0 : 768 11 20 31 60 40 0 : 960 24 21 33 68 40 0 : 960 54 22 34 74 66 1 : 584 V  ideo 1 1 1 1 0 0 2 1 1 2 1 0 : 9 5 : 5 4 4 5 4 3 : 6 11 6 7 9 8 7 : 2 24 9 12 17 11 9 : 9 54 11 16 27 13 11 : 7 Tabla 6: Cantidad de conexiones de VoIP y vdeo ( one way ) para diferentes anchos de banda. Para el caso de voz, se utiliza codec G 729 para una paquetizacion de dos muestras por paquete, mientras que para vdeo se utiliza el traco obtenido en el apendice D.4 y el escenario que se muestra en la gura 18. El ancho de banda experimental es a nivel IP. Los resultados presentados en la table 6 son para el modelo de compresion de 4 Kbytes , dado que para el caso del modelo con una compresion baja (50 Kbytes ) solamente permite una comunicacion, habiendo perdidas de paquetes desde la segunda comunicacion. Hay una clara diferencia en cuanto a como se aprovecha el ancho de banda para los casos de vdeo y voz; el protocolo de acceso al medio es el que hace que se penalicen mas los paquetes peque~nos que los de mayor tama~no, en cuanto a ancho de banda, ya que los tiempos de DIFS, SIFS y el tiempo del ACK se mantienen para todos los paquetes, as como el preambulo. 6.3 Prueba en el enlace entre dos puntos de acceso La siguiente prueba se realiza en un escenario como se muestra en la gura 19, en este caso cada estacion de trabajo se conecta con un punto Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 6 MEDIDAS DE CALIDAD 45 de acceso diferente a traves de un enlace de 100 Mbps , dichos puntos de acceso se comunican por medio de un enlace WiFi, las caractersticas de la conguracion de los puntos de acceso se realiza de la misma manera que en la prueba anterior para diferentes anchos de banda. Figura 19: Enlace WiFi entre dos puntos de acceso. Tr  afico BW ( Mbps ) Cantidaddeconexiones Teorico Experimental M  inimo Medio M  aximo Conexiones BW ( Mbps ) V oz 1 11 14 17 15 0 : 360 2 15 20 29 28 0 : 672 5 : 5 19 27 48 47 1 : 128 11 20 31 60 56 1 : 344 24 21 33 68 67 1 : 608 54 22 34 74 68 1 : 632 V  ideo 1 1 1 1 0 0 2 1 1 2 1 0 : 9 5 : 5 4 4 5 4 3 : 6 11 6 7 9 7 6 : 3 24 9 12 17 11 9 : 9 54 11 16 27 13 11 : 7 Tabla 7: Cantidad de conexiones de VoIP y vdeo ( one way ) para diferentes anchos de banda. Para el caso de voz, se utiliza codec G 729 para una paquetizacion de dos muestras por paquete, mientras que para vdeo se utiliza el traco obtenido en el apendice D.4 y el escenario que se muestra en la gura 19. El ancho de banda experimental es a nivel IP. En este caso, se ha observado que la cantidad se ujos de voz que se han Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 6 MEDIDAS DE CALIDAD 46 podido establecer en cada ancho de banda, es mayor que los obtenidos en la prueba realizada anteriormente, como se puede observar en la tabla 8. Los resultados se mantienen dentro del rango medio de slot de que se han asumido, debido a las caractersticas del protocolo de acceso al medio. En el caso de vdeo los valores se mantienen similares a los obtenidos en la prueba anterior. 6.4 Prueba entre dos estaciones de trabajo en modo infraestructura Esta prueba se realiza con dos estaciones de trabajo que se comunican por medio de un punto de acceso en modo infraestructura. La diferencia en este caso consiste en que ambas estaciones compartiran el medio por lo que la misma trama que se transmite aparecera dos veces en el enlace WiFi, la conguracion del punto de acceso es identica a los casos anteriores, el escenario propuesto se muestra en la gura 20. Figura 20: Enlace WiFi entre dos puntos de acceso en modo infraestructura. En este caso se presentan mayores problemas ya que a la hora de repetir las pruebas hay todava mas variaciones, es necesario una gran cantidad de repeticiones para poder obtener valores ables en cuanto a sus valores medios. Por otro lado, recordar que se ha sido exhaustivo en mitigar los problemas de interferencias de las celdas adyacentes, sin embargo, los problemas asociados a las colisiones de datos generan problemas en la comunicacion, degradando la cantidad de conexiones que se pueden obtener para cada ancho de banda en comparacion a las pruebas anteriores. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 6 MEDIDAS DE CALIDAD 47 Los datos que se muestran en la tabla 8 dieren en gran medida de los obtenidos en las pruebas anteriores, tanto para las pruebas de voz como para las de vdeo, encontrandose casos en los que la cantidad de conexiones se reduce hasta en un 57%. Tr  afico BW ( Mbps ) Cantidaddeconexiones Teorico Experimental M  inimo Medio M  aximo Conexiones BW ( Mbps ) V oz 1 11 14 17 11 0 : 264 2 15 20 29 15 0 : 360 5 : 5 19 27 48 22 0 : 528 11 20 31 60 24 0 : 576 24 21 33 68 50 1 : 200 54 22 34 74 54 1 : 296 V  ideo 1 1 1 1 0 0 2 1 1 2 1 0 : 9 5 : 5 4 4 5 3 2 : 7 11 6 7 9 5 4 : 5 24 9 12 17 8 7 : 2 54 11 16 27 7 6 : 3 Tabla 8: Cantidad de conexiones de VoIP y vdeo ( one way ) para diferentes anchos de banda. Para el caso de voz, se utiliza codec G 729 para una paquetizacion de dos muestras por paquete, mientras que para vdeo se utiliza el traco obtenido en el apendice D.4 y el escenario que se muestra en la gura 20. El ancho de banda experimental es a nivel IP. 6.5 Analisis de resultados En primer lugar, los resultados obtenido para voz, se acercan mas a los valores maximos teoricos que a los valores medios, esto se debe a que el entorno de pruebas se ha maximizado con esta nalidad, se ha seleccionado un canal que presente las mejores condiciones y se ha tratado de minimizar los efectos de las interferencias, ademas, se he tratado que la ubicacion de los equipos utilizados asegure un excelente nivel de potencia, superior al 95% en todos los casos, con el objetivo de poder valorar el ancho de banda maximo en cada caso. Por otro lado, a pesar que el numero de slots se genera de manera aleatoria (dentro de ciertas condiciones), puede existir algun criterio dentro del Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 6 MEDIDAS DE CALIDAD 48 manejo que realiza la tarjeta de red, que al existir un buen nivel de se~nal y al no existir colisiones de datos con otras estaciones de trabajo, se reduzca el tiempo de backo . Como se pudo observar en 4.2.1, las comunicaciones de VoIP analizadas anteriormente, se caracterizan por paquetes peque~nos, a esto se le suma la gran cantidad de encabezado que se genera en la red, que se puede calcular mediante la ecuacion 3, de ah se obtiene que el porcentaje de datos transmitidos con respecto a todos los bits transmitidos, lo que corresponde a un 21 : 27% en el caso de voz y un 95 : 21% para el de vdeo. Porcentaje Datos = Datos Datos + RTP + UDP + IP + MAC (3) La relacion anterior en conjunto con el backo , son las grandes limitantes de CSMA/CA en cuanto a la cantidad de conexiones que puedes ser transportados por un canal determinado utilizando esta tecnica de acceso al medio; por otro lado, el preambulo que se utilice (largo o corto) tambien tiene un aporte signicativo, ademas, se debe tener en cuenta los tiempos DIFS, SIFS y de ACK. Los resultados obtenidos concuerdan con los valores teoricos calculados y con ciertos autores [5] y [12], lo que valida el uso de la metodologa empleada para realizar las pruebas en los distintos escenarios planteados. Ademas, las herramientas utilizadas para la reproduccion del traco han tenido los resultados esperados por lo que se recomienda su uso. Para el caso de vdeo y voz el comportamiento de los ujos es similar en los distintos escenarios, excepto en modo infraestructura ya que al compartir las dos estaciones de trabajo el mismo medio, esto produce colisiones de datos, que puede provocar un aumento en el backo . Otro aspecto que es necesario dejar claro esta relacionado con el tipo de traco y el sentido de los ujos IP analizados en esta seccion, esto se debe en buena medida a la limitacion de tiempo para el desarrollo del presente trabajo. Dejando planteado un analisis que contemple ambos sentidos de la comunicacion para futuras investigaciones. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad 6 MEDIDAS DE CALIDAD 49 Otro de los aspecto tenidos en cuenta a la hora de establecer las caractersticas del traco utilizado en la realizacion de las medidas, viene dado por el analisis de los modelos de traco obtenidos, por ejemplo, en el caso del modelo de voz se pudo determinar que cada uno de los nodos enviaba traco identico al nodo con el cual se comunicaba, de aqu que una de las aproximaciones que se ineren sera que la cantidad de comunicaciones posibles en ambos sentidos sera la mitad de las obtenidos en un solo sentido, ademas, lo que se desea valorar en este caso es la cantidad de ujos posibles sin perdidas. Sin embargo, si se deseara valorar el efecto real del traco en ambos sentidos habra que transmitir desde las dos estaciones de trabajo, traco con una distribucion similar a la utilizada. En el caso de vdeo, el analisis del modelo obtenido (para una compresion de 50 Kbytes ) presenta un 25% de los paquetes en sentido inverso, dichos paquetes son del tipo ACK, ya que la transmision se realiza por medio de TCP. Esta situacion se puede ser aproximada mediante traco UDP si se supone que no hay perdidas, que es el caso de estudio en la realizacion de las pruebas planteadas. Por otro lado, en futuras investigaciones, sera interesante valorar el efecto del aumento de ujos en ambos sentidos del enlace, para esto es necesario apoyarse en el script D.1 donde se obtienen las caractersticas del traco en ambos sentidos de la comunicacion, de la misma manera comentada con anterioridad sera necesario reproducir el traco desde los dos equipos terminales segun el sentido del ujo de datos. 6.6 Recomendaciones para medidas en entornos virtuales La virtualizacion de escenarios de red presenta una serie de ventajas en comparacion a la simulacion; el uso de entornos virtuales permite utilizar un determinado sistema operativo y aplicaciones en forma directa, algo que es util en los casos que estos tengan efecto sobre el traco analizado con respecto al su de escenarios reales, por otros lado, presenta una reduccion importante de costes cuando el numero de nodos se incrementa. En el caso de hacer uso de este tipo de entorno para la realizacion de pruebas, emulando entornos reales, se debe prestar especial cuidado a los dos primeros Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad BIBLIOGRAF IA 56 [8] Nelson Antunes, Antonio Pacheco, and Rui Rocha. An integrated trac model for multimedia wireless networks. Computer Networks , 38(1):25 { 41, 2002. [9] J. M. Salda~na Medina, J. Murillo, J. Fernandez Navajas, J. Ruiz Mas, E. A. Viruete Navarro, and J. I. Aznar Baranda. Emulacion de escenarios de red mediante un testbed. Actas del XXV Simposium Nacional de la Union Cientca Internacional de Radio (URSI) , Bilbao (Espa~na). Septiembre 2010. [10] J. I. Aznar Baranda, E. A. Viruete Navarro, J. Fernandez Navajas, J. Ruiz Mas, J. M. Salda~na Medina, and J. Murillo. Qmoes: A bandwidth estimation and monitoring tool for qoe-driven broadband networks. In Proc. New Technologies, Mobility and Security (NTMS), 5th International Conference , Paris. ISBN: 978-1-4244-8704-2. Febrero 2011. [11] J. M. Salda~na Medina, J. I. Aznar Baranda, E. A. Viruete Navarro, J. Fernandez Navajas, and J. Ruiz Mas. Qos measurement-based cac for an ip telephony system. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering , 22(1):3{19, DOI: 10-1007-978-3-642-10625-5-1. Noviembre 2009. [12] J. Murillo Royo, J. M. Salda~na Medina, J. Fernandez Navajas, J. Ruiz Mas, E. A. Viruete Navarro, and J. I. Aznar Baranda. Analisis de qos para una plataforma distribuida de telefona ip. Actas de las IX Jornadas de Ingeniera Telematica (JITEL 2010). , pages 63{70, Valladolid. Septiembre 2010. [13] J. M. Salda~na Medina, J. Murillo, J. Fernandez Navajas, J. Ruiz Mas, E. A. Viruete Navarro, and J. I. Aznar Baranda. Evaluation of multiplexing and buer policies inuence on voip conversation quality. In Proc. CCNC 2011 3rd IEEE International Workshop on Digital Entertainment, Networked Virtual Environments, and Creative Technology , pages 1147{1151, Las Vegas. ISBN 978142448782. Enero 2011. [14] J. M. Salda~na Medina, J. Fernandez Navajas, J. Ruiz Mas, J. I. Aznar Baranda, Eduardo Viruete, and L. A. Casadesus Pazos. Inuence Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad BIBLIOGRAF IA 57 of the router buer on online games trac multiplexing. Proc. International Symposium on Performance Evaluation of Computer and Telecommunication Systems SPECTS , pages 253{258, The Hague, Netherlands. ISBN: 978-161-782-309-1. Junio 2011. [15] http://www.tcpdump.org/. [16] http://www.wireshark.org/. [17] http://www.linuxfoundation.org/collaborate/workgroups/networking/netem. [18] http://www.cs.helsinki./u/jmanner/software/. [19] http://www.grid.unina.it/software/ITG/. [20] Casadesus Pazos L. A., Fernandez Navajas J., Ruiz Mas J., Salda~na Medina J. M., Aznar Baranda J. I., and Viruete Navarro Eduardo. Herramienta para automatizacion de medidas de tiempo real extremo a extremo. Actas del XXVI Simposium Nacional de la Union Cientca Internacional de Radio (URSI 2011) , Leganes (Espa~na). ISBN 9788493393458. Septiembre 2011. [21] Salda~na J. Sistema de emulacion de escenarios de movilidad. Master's thesis, Universidad de Zaragoza, Agosto 2008. [22] Murillo J. Analisis de un sistema cac par telefona ip. Master's thesis, Universidad de Zaragoza, Febrero 2010. [23] http://www.xen.org/. [24] http://www.sintel.org/. [25] Telecomunication Standardization Sector of ITU. G.729 coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (cs-acelp). Technical report, International Telecomunication Union, 2007. [26] Curtis Villamizar and Cheng Song. High performance tcp in ansnet. SIGCOMM Comput. Commun. Rev. , 24:45{60, October 1994. [27] Guido Appenzeller, Isaac Keslassy, and Nick McKeown. Sizing router buers. SIGCOMM Comput. Commun. Rev. , 34:281{292, August 2004. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad BIBLIOGRAF IA 58 [28] Arun Vishwanath, Vijay Sivaraman, and Marina Thottan. Perspectives on router buer sizing: recent results and open problems. SIGCOMM Comput. Commun. Rev. , 39:34{39, March 2009. [29] Mihaela Enachescu, Yashar Ganjali, Ashish Goel, Nick McKeown, and Tim Roughgarden. Part iii: routers with very small buers. SIGCOMM Comput. Commun. Rev. , 35:83{90, July 2005. [30] A Vishwanath, V Sivaraman, and G N Rouskas. Considerations for sizing buers in optical packet switched networks. IEEE INFOCOM 2009 The 28th Conference on Computer Communications , pages 1323{ 1331, 2009. [31] Amogh Dhamdhere and Constantine Dovrolis. Open issues in router buer sizing. SIGCOMM Comput. Commun. Rev. , 36:87{92, January 2006. [32] Joel Sommers, Paul Barford, Albert Greenberg, and Walter Willinger. An sla perspective on the router buer sizing problem. SIGMETRICS Perform. Eval. Rev. , 35:40{51, March 2008. [33] http://www.videolan.org/. [34] IEEE Standard for Information Tecchnology. Wireless lan medium access control (mac) and physical layer (phy) specications. Technical report, IEEE Computer Society, 2007. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad A ACR ONIMOS Y T ERMINOS 59 A Acronimos y terminos A.1 Acromimos GNU GPL ( GNU General Public License ) NETEM Network Emulator es un emulador de red. TC ( Trac Control ) JTG ( Jugi's Trac Generator ) GUI ( Graphical User Interface ) D-ITG OWD ( one-way-delay ) RTT ( round-trip-time ) IAX ( Inter-Asterisk eXchange protocol ) Hub Concentrador o ethernet hub, un dispositivo para compartir una red de datos o de puertos USB de un ordenador. IVR ( Interative Voice Response ) NAT (Network Address Translation - Traduccion de Direccion de Red) es un mecanismo utilizado por enrutadores IP para intercambiar paquetes entre dos redes CCITT Consultative Committee for International Telegraph and Telephone (Comite Consultivo Internacional de Telefona y Telegrafa) H.323 Estandar de la ITU-T para voz y videoconferencia interactiva en tiempo real en redes de area local, LAN, e Internet. IP Internet Protocol (Protocolo Internet) ISP Internet Service Provider (Proveedor de Servicios Internet, PSI) ITU-T International Telecommunications Union Telecommunications (Union Internacional de Telecomunicaciones - Telecomunicaciones) MOS Mean Opinion Score (Nota Media de Resultado de Opinion) QoS Quality of Service (Calidad de Servicio) RTP Real Time Protocol (Protocolo de Tiempo Real) SIP Session Initiation Protocol (Protocolo de Inicio de Sesion) TCP Transmission Control Protocol (Protocolo de Control de Transmision) UDP User Datagram Protocol (Protocolo de Datagramas de Usuario) ICMP El Protocolo de Mensajes de Control de Internet o ICMP (por sus siglas de Internet Control Message Protocol) es el sub protocolo de control y noticacion de errores del Protocolo de Internet (IP). MPEG Moving Picture Experts Group (en espa~nol Grupo de Expertos en Imagenes Moviles), referido comunmente como MPEG, es un grupo de trabajo del ISO/IEC encargado de desarrollar estandares de cod- icacion de audio y vdeo. A.2 Terminos codec Algoritmo software usado para comprimir/descomprimir se~nales de voz o audio. Se caracterizan por varios parametros como la cantidad de bits, el tama~no de la trama (frame), los retardos de proceso, etc. Algunos ejemplos de codecs tpicos son G.711, G.723.1, G.729 o G.726. streaming consiste en la distribucion de audio o video por Internet, esta palabra hace referencia a una transmision en forma continua Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad A ACR ONIMOS Y T ERMINOS 60 gateway (pasarela). Dispositivo empleado para conectar redes que usan diferentes protocolos de comunicacion de forma que la informacion puede pasar de una a otra. En VoIP existen dos tipos principales de pasarelas: la Pasarela de Medios (Media Gateways), para la conversion de datos (voz), y la Pasarela de Se~nalizacion (Signalling Gateway), para convertir informacion de se~nalizacion. jitter (variacion de retardo). Es un termino que se reere al nivel de variacion de retado que introduce una red. Una red con variacion 0 tarda exactamente lo mismo en transferir cada paquete de informacion, mientras que una red con variacion de retardo alta tarda mucho mas tiempo en entregar algunos paquetes que en entregar otros. La variacion de retardo es importante cuando se enva audio o video, que deben llegar a intervalos regulares si se quieren evitar desajustes o sonidos inintelegibles. snier un analizador de paquetes es un programa de captura de las tramas de una red de computadoras. router (encaminador, enrutador). Dispositivo que distribuye traco entre redes. La decision sobre a donde enviar los datos se realiza en base a informacion de nivel de red y tablas de direccionamiento. Es el nodo basico de una red IP. VoIP Voice over IP (Voz sobre IP). Metodo de envo de voz por redes de conmutacion de paquetes utilizando TCP/IP, tales como Internet. Ancho de banda Capacidad de transmision de datos que tiene un medio determinado, generalmente cuanticado segun el numero de bits que se transmiten en un segundo. root En sistemas operativos del tipo Unix, root es el nombre convencional de la cuenta de usuario que posee todos los derechos en todos los modos (mono o multi usuario). root es tambien llamado superusuario. Normalmente esta es la cuenta de administrador. broadcast transmision de un paquete que sera recibido por todos los dispositivos en una red. El Dominio de difusion, CSMA/CA Carrier Sense, Multiple Access, Collision Avoidance (acceso multiple por deteccion de portadora con evasion de colisiones) es un protocolo de control de redes de bajo nivel que permite que multiples estaciones utilicen un mismo medio de transmision. Cada equipo anuncia opcionalmente su intencion de transmitir antes de hacerlo para evitar colisiones entre los paquetes de datos (comunmente en redes inalambricas, ya que estas no cuentan con un modo practico para transmitir y recibir simultaneamente). Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad B PROCEDIMIENTO PARA EL MODELADO DE FLUJOS IP MULTIMEDIA 61 B Procedimiento para el modelado de ujos IP multimedia 1. Estudio teorico y planicacion de la prueba. (a) Recopilacion de informacion de fuentes primarias y secundarias. (b) Analisis de la informacion. (c) Reproduccion de ejemplos, simulaciones y similares. (d) Seleccion de aplicaciones a modelar. (e) Seleccion de equipamiento a utilizar. (f) Seleccion de herramientas para la obtencion de datos. (g) Seleccion de herramientas para el analisis de resultados. (h) Asignacion de tareas a grupos de trabajo. (i) Elaboracion de un cronograma de actividades. 2. Acondicionamiento del entorno de pruebas. (a) Proveer un entorno de pruebas libre de ruido e interferencia. (b) Realizar y comprobar conexiones fsicas de red. (c) Puesta en marcha de equipos. (d) Conguracion de parametros basicas de red. (e) Comprobacion de enlaces de red. (f) Conguracion avanzada de cada elemento de red. (g) Monitorizar procesos activos y recursos. (h) Eliminacion de procesos innecesarios en el sistema. 3. Obtencion de resultados. (a) Lanzar aplicaciones a utilizar. (b) Conguracion de la aplicaciones. (c) Conguracion de herramientas para la obtencion de resultados (d) Lanzar herramientas para la captura de datos. (e) Iniciar la transmision. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad B PROCEDIMIENTO PARA EL MODELADO DE FLUJOS IP MULTIMEDIA 62 (f) Mantener activa transmision segun tiempo planicado. (g) Terminar transmision. (h) Terminar herramienta de obtencion de resultados. 4. Analisis de resultados. (a) Vericar contenidos de resultados obtenidos. (b) Construir herramientas o procedimientos que permitan adaptar los resultados hacia las herramientas de analisis. (c) Exportar resultados con formatos compatibles con las aplicaciones de analisis. (d) Aplicar herramientas de analisis. (e) Vericar la correspondencia de los resultados obtenidos con los protocolos involucrados. 5. Presentacion de resultados. (a) Seleccion de las herramientas de elaboracion de documentos. (b) Seleccion de las herramientas de elaboracion de graco y guras. (c) Representar sntesis de resultados con herramientas para la produccion de documentos cientcos. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad C APLICACIONES MULTIMEDIA 63 C Aplicaciones multimedia C.1 Voz IP El desarrollo de tecnologas de VoIP ha tenido una gran aceptacion por parte de empresas que buscan una reduccion de costes para sus comunicaciones de voz principalmente PYMES (Peque~nas y Medianas Empresas) [5] y [12]. VoIP permite la transmision de voz por medio de una red IP, como Internet, consiste en la digitalizacion de la se~nales de voz por medio de un codec , por otro lado, VoIP hace uso de diversos tipos de tecnicas para la se~nalizacion de la llamada, no habiendo un protocolo denido en este ambito. Uno de los protocolo utilizados con este n en SIP ( Session Initiation Protocol ), ademas, se encuentran implementaciones con H.323 o IAX ( Inter-Asterisk eXchange protocol ). SIP es uno de los protocolo con mayor impacto en la implementacion de ToIP ( Telephony over IP ) [5], [11], [13] y [12], dicho protocolo, se encarga de la se~nalizacion extremo a extremo de la comunicacion, realiza los procedimientos necesarios para el establecimiento de la llamada, la modicacion y la nalizacion de la comunicacion. Por otro lado, para la transmision de datos en tiempo real, VoIP hace uso del protocolo RTP ( Real-time Transport Protocol ), dicho protocolo se encarga del control de la transmision en las sesiones de aplicaciones multimedia y utiliza como protocolo de transporte UDP. El dispositivo Linksys SPA 3102 es una pasarela de voz sobre IP hacia una red telefonica convencional y viceversa, utiliza el protocolo SIP ( Session Initiation Protocol ) para la se~nalizacion de la comunicacion, ademas, puede ser congurado, con relativa facilidad, por medio de un menu IVR ( Interative Voice Response ) o mediante un servidor web desde cualquier navegador. El menu IVR permite la conguracion basica del dispositivo, como lo es la asignacion de direcciones IP a cada terminal. La conguracion avanzada del gateway VoIP consiste en la asignacion de los parametros correspondientes para las funcionalidades de enrutador y las asociadas a voz, esta conguracion se realiza por medio de un navegador web. Dentro de los aspectos mas relevantes de la conguracion destacan la utilizacion de SIP como protocolo de se~nalizacion, la desactivacion de NAT ( Network Address Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad C APLICACIONES MULTIMEDIA 64 Translation ) y demas funcionalidades de enrutamiento, por otro lado, en la conguracion de audio se hace uso del codec G 729 [2] y en la paquetizacion se denen dos muestras por paquete, no se realiza supresion de silencio. De los resultados se obtiene la gura 21, en la que se ha reconstruido la distribucion de los encabezados de cada uno de los paquetes capturados. Figura 21: Paquete VoIP transmitido por las estaciones. C.2 Camaras de video sobre IP Las camaras IP han tenido un impacto importante en mecanismos de seguridad a nivel empresarial y residencial, este tipo de equipos permite emitir video utilizando tecnicas de compresion de imagen a traves de miles de kilometros utilizando TCP/IP. Dentro de sus funciones se encuentran activacion mediante movimiento o sensores, control remoto, gestion a traves de HTTP, entre otros. Para las pruebas realizadas en este trabajo se utiliza una camara AXIS 2120 (un modelo dise~nado para exteriores), esta camara permite conectarse a redes Ethernet y Fast Ethernet con relativa facilidad, posee detector de movimientos, soporta protocolos como TCP/IP ( Transmision Control Protocol/Internet Protocol ), SMTP ( Simple Mail Transfer Protocol ), HTTP ( Hypertext Transfer Protocol ), entre otros. El formato de imagen es JPEG ( Joint Photographic Experts Group ) y soporta diferentes niveles de compresion. En resumen, la camara captura imagenes en formato JPEG y las transmite a razon de 25/30 tramas por segundo (PAL/NTSC) sobre una red con ancho de banda de 10 Mbps o 100 Mbps respectivamente. La distribucion de encabezados para un paquete de este tipo tiene la forma que se muestra en la gura 22. A diferencia del caso anterior, el transporte lo brinda TCP y la informacion esta contenida en un paquete HTTP. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad C APLICACIONES MULTIMEDIA 65 Figura 22: Paquete transmitido por la camara. C.3 Video streaming El crecimiento a nivel mundial en el acceso a Internet por parte de los usuarios ha generado el desarrollo de diversas aplicaciones y nuevos modelos de negocio dentro de los que se encuentran la radio y la television por Internet (por mencionar algunos) [4] y [3]. Este tipo de servicios basa su funcionamiento en la transmision streaming . El streaming consiste en la distribucion de audio o video por Internet, esta palabra hace referencia a una transmision en forma continua, sin interrupciones y sin la necesidad de descargas previas. Para la implementacion de este tipo de traco se ha escogido una aplicacion ampliamente difundida y aceptada por los usuarios, como lo es VLC. VLC media player [33] es un reproductor multimedia y framework multimedia libre y de codigo abierto desarrollado por el proyecto VideoLAN bajo la licencia GNU GPL. Es un programa multiplataforma con versiones disponibles para sistemas operativos como Microsoft Windows, GNU/Linux, Mac OS X, BeOS, BSD y eComStation, entre otros. El reproductor es capaz de reproducir muchos codecs y formatos de audio y video (dependiendo del sistema operativo en el que opere), ademas de capacidad de streaming . Figura 23: Reproductor de multimedia VLC. Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad D SCRIPT 72 130 figure (1); subplot (2 ,1 ,2); plot (tiempo rafaga enviado , 131 t rafaga enviado) 132 figure (1); subplot (2 ,1 ,2); xlabel (Tiempo de transmision ( s )) 133 figure (1); subplot (2 ,1 ,2); ylabel ( Duracion de la rafaga ( s )) 134 figure (1); subplot (2 ,1 ,2); title ( Variacion de la duracion de 135 rafagas ) 136 figure (1); subplot (2 ,1 ,2); legend ( Trafico enviado ) 137 figure (2); subplot (2 ,1 ,1); hist ( t paquete enviado ) 138 figure (2); subplot (2 ,1 ,1); xlabel ( Duracion del paquete ( s )) 139 figure (2); subplot (2 ,1 ,1); ylabel (Cantidad de paquetes ) 140 figure (2); subplot (2 ,1 ,1); title ( Distribucion de paquetes enviados ) 141 figure (2); subplot (2 ,1 ,1); legend ( Trafico enviado ) 142 figure (2); subplot (2 ,1 ,2); hist (t paquete recibido) 143 figure (2); subplot (2 ,1 ,2); xlabel ( Duracion del paquete ( s )) 144 figure (2); subplot (2 ,1 ,2); ylabel (Cantidad de paquetes ) 145 figure (2); subplot (2 ,1 ,2); title ( Distribucion de paquetes recibidos ) 146 figure (2); subplot (2 ,1 ,2); legend ( Trafico recibido ) 147 148 % Camara 16 149 figure (1); bar ( t enviado , t paquete enviado , r , 150 t recibido , t paquete recibido ,b) 151 figure (1); xlabel (Tiempo de transmision ( s )) 152 figure (1); ylabel ( Duracion del paquete ( s )) 153 figure (1); title ( Variacion del tiempo de paquetes para el 154 trafico de camara 16 ) 155 figure (1); legend ( Trafico enviado , Trafico recibido ) 156 figure (2); plot ( tiempo rafaga enviado , t rafaga enviado ) 157 figure (2); xlabel (Tiempo de transmision ( s )) 158 figure (2); ylabel ( Duracion de la rafaga ( s )) 159 figure (2); title ( Variacion del tiempo rafagas para el trafico 160 enviado de camara 16 ) 161 figure (2); legend ( Trafico enviado ) 162 figure (3); hist ( t paquete enviado ) 163 figure (3); xlabel ( Duracion del paquete ( s )) 164 figure (3); ylabel (Cantidad de paquetes ) 165 figure (3); title ( Distribucion de paquetes para el trafico de 166 camara 16) 167 figure (3); legend ( Trafico enviado ) 168 figure (4); hist (t paquete recibido) 169 figure (4); xlabel ( Duracion del paquete ( s )) 170 figure (4); ylabel (Cantidad de paquetes ) 171 figure (4); title ( Distribucion de paquetes para el trafico 172 camara 16) 173 figure (4); legend ( Trafico enviado ) 174 Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad D SCRIPT 73 175 % Camara 13 176 figure (1); plot ( t enviado , t paquete enviado , r , 177 t recibido , t paquete recibido ,b) 178 figure (1); xlabel (Tiempo de transmision ( s )) 179 figure (1); ylabel ( Duracion del paquete ( s )) 180 figure (1); title ( Variacion del tiempo de paquetes para el trafico 181 de camara 13 ) 182 figure (1); legend ( Trafico enviado , Trafico recibido ) 183 figure (2); plot ( tiempo rafaga enviado , t rafaga enviado ) 184 figure (2); xlabel (Tiempo de transmision ( s )) 185 figure (2); ylabel ( Duracion de la rafaga ( s )) 186 figure (2); title ( Variacion del tiempo rafagas para el trafico 187 enviado de camara 13 ) 188 figure (2); legend ( Trafico enviado ) 189 figure (3); hist ( t paquete enviado ) 190 figure (3); xlabel ( Duracion del paquetes para el trafico de 191 camara 13) 192 figure (3); ylabel (Cantidad de paquetes ) 193 figure (3); title ( Distribucion de paquetes para el trafico de 194 camara 13) 195 figure (3); legend ( Trafico enviado ) 196 figure (4); hist (t paquete recibido) 197 figure (4); xlabel ( Duracion del paquete ( s )) 198 figure (4); ylabel (Cantidad de paquetes ) 199 figure (4); title ( Distribucion de paquetes para el trafico 200 camara 13) 201 figure (4); legend ( Trafico recibido ) 202 203 % Camara 4 204 figure (1); plot ( t enviado , t paquete enviado , r , 205 t recibido , t paquete recibido ,b) 206 figure (1); xlabel (Tiempo de transmision ( s )) 207 figure (1); ylabel ( Duracion del paquete ( s )) 208 figure (1); title ( Variacion del tiempo de paquetes para el trafico 209 de camara 4) 210 figure (1); legend ( Trafico enviado , Trafico recibido ) 211 figure (2); plot ( tiempo rafaga enviado , t rafaga enviado ) 212 figure (2); xlabel (Tiempo de transmision ( s )) 213 figure (2); ylabel ( Duracion de la rafaga ( s )) 214 figure (2); title ( Variacion del tiempo rafagas para el trafico 215 enviado de camara 4 ) 216 figure (2); legend ( Trafico enviado ) 217 figure (3); hist ( t paquete enviado ) 218 figure (3); xlabel ( Duracion del paquete ( s )) 219 figure (3); ylabel (Cantidad de paquetes ) Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad D SCRIPT 74 220 figure (3); title ( Distribucion de paquetes para el trafico de 221 camara 4) 222 figure (3); legend ( Trafico enviado ) 223 figure (4); hist (t paquete recibido) 224 figure (4); xlabel ( Duracion del paquete ( s )) 225 figure (4); ylabel (Cantidad de paquetes ) 226 figure (4); title ( Distribucion de paquetes para el trafico 227 camara 4) 228 figure (4); legend ( Trafico recibido ) D.2 Script para el analisis de modelos para ujos streaming 1 %% Analisis de datos de trafico 2 3 clear all 4 5 %% Datos 6 voz= csvread (voz . csv ); 7 camara 4= csvread (camara 4 . csv ); 8 camara 13= csvread (camara 13 . csv ); 9 camara 16= csvread (camara 16 . csv ); 10 camara 50= csvread (camara 50 . csv ); 11 video streaming= csvread ( streaming 3 . csv ); 12 umbral voz=0; 13 umbral camara 4 =0.035; 14 umbral camara 13=0.035; 15 umbral camara 16=0.1; 16 umbral camara 50=0.1; 17 umbral streaming=20e  5; 18 19 %% Definir archivo 20 datos=video streaming; 21 umbral=umbral streaming ; 22 23 %% Para streaming 24 if datos==video streaming 25 a=1; 26 for i =1: length (datos) 27 if (( datos ( i ,3)==0) && ( datos ( i ,4)==1)) 28 t enviado (a)=datos ( i , 2) ; 29 a=a+1; 30 end Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad D SCRIPT 75 31 end 32 t paquete enviado= zeros ( size ( t enviado )) ; 33 for i =2: length ( t paquete enviado ) 34 t paquete enviado ( i)=t enviado ( i)  t enviado(i  1); 35 end 36 c=1; 37 for i =1: length ( t paquete enviado ) 38 if t paquete enviado ( i) > umbral 39 t rafaga enviado ( c)=t paquete enviado ( i ); 40 c=c+1; 41 end 42 end 43 e=1; 44 for i =2: length (datos) 45 if (( datos ( i ,3)==0) && ( datos ( i ,4)==1) && (( datos ( i ,2)  46 datos ( i  1,2)) > umbral )) 47 tiempo rafaga enviado ( e)=datos ( i , 2); 48 e=e+1; 49 end 50 end 51 media paquetes enviados= mean ( t paquete enviado ) 52 desviacion std paquetes enviados= std ( t paquete enviado ) 53 media rafaga enviado= mean (t rafaga enviado) 54 desviacion sdt rafaga enviado= std (t rafaga enviado) 55 probabilidad paquetes enviados= length (t enviado)/ 56 length ( datos ) 57 probabilidad rafagas enviadas= length (t rafaga enviado)/ 58 length (t enviado) 59 end 60 61 %% Graficos 62 63 % subplot (2 ,2 ,[1 2]); plot ( t enviado , t paquete enviado ) 64 % subplot (2 ,2 ,[1 2]); xlabel (Tiempo de transmision ( s )) 65 % subplot (2 ,2 ,[1 2]); ylabel (Duracion del paquete (s )) 66 % subplot (2 ,2 ,[1 2]); t i t l e ( Variacion del tiempo de paquetes para 67 el trafico streaming ) 68 % subplot (2 ,2 ,[1 2 ]); legend ( Trafico enviado ) 69 % subplot (2 ,2 ,1); plot ( t enviado , t paquete enviado ) 70 % subplot (2 ,2 ,1); xlabel (Tiempo de transmision (s )) 71 % subplot (2 ,2 ,1); ylabel (Duracion del paquete ( s )) 72 % subplot (2 ,2 ,1); t i t l e ( Variacion del tiempo de paquetes para 73 el trafico streaming ) 74 % subplot (2 ,2 ,1); legend ( Trafico enviado ) 75 figure (5); subplot (2 ,2 ,[1 2 ] ) ; scatter ( tiempo rafaga enviado , Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad D SCRIPT 76 76 t rafaga enviado) 77 figure (5); subplot (2 ,2 ,[1 2 ]); xlabel (Tiempo de transmision ( s )) 78 figure (5); subplot (2 ,2 ,[1 2 ]); ylabel ( Duracion de la rafaga ( s )) 79 figure (5); subplot (2 ,2 ,[1 2 ]); title ( Variacion del tiempo rafagas 80 para el trafico enviado de streaming ) 81 figure (5); subplot (2 ,2 ,[1 2 ]); legend ( Trafico enviado ) 82 % subplot (2 ,2 ,3); hist ( t paquete enviado ) 83 % subplot (2 ,2 ,3); xlabel (Duracion del paquete ( s )) 84 % subplot (2 ,2 ,3); ylabel (Cantidad de paquetes ) 85 % subplot (2 ,2 ,3); t i t l e ( Distribusion de paquetes para el 86 trafico streaming ) 87 % subplot (2 ,2 ,3); legend ( Trafico enviado ) 88 figure (5); subplot (2 ,2 ,[3 4 ]); hist (t rafaga enviado) 89 figure (5); subplot (2 ,2 ,[3 4 ]); xlabel ( Duracion de la rafaga ( s )) 90 figure (5); subplot (2 ,2 ,[3 4 ]); ylabel (Cantidad de rafagas ) 91 figure (5); subplot (2 ,2 ,[3 4 ]); title ( Distribusion de rafagas para 92 el trafico streaming ) 93 figure (5); subplot (2 ,2 ,[3 4 ]); legend ( Trafico enviado ) 94 95 figure (1); plot ( t enviado , t paquete enviado ) 96 figure (1); xlabel (Tiempo de transmision ( s )) 97 figure (1); ylabel ( Duracion del paquete ( s )) 98 figure (1); title ( Variacion del tiempo de paquetes para el trafico 99 streaming ) 100 figure (1); legend ( Trafico enviado ) 101 % figure (2); scatter ( tiempo rafaga enviado , t rafaga enviado ) 102 % figure (2); xlabel (Tiempo de transmision (s )) 103 % figure (2); ylabel (Duracion de la rafaga ( s )) 104 % figure (2); t i t l e ( Variacion del tiempo rafagas para el trafico 105 enviado de streaming ) 106 % figure (2); legend ( Trafico enviado ) 107 % figure (3); hist ( t paquete enviado ) 108 % figure (3); xlabel (Duracion del paquete (s )) 109 % figure (3); ylabel (Cantidad de paquetes ) 110 % figure (3); t i t l e ( Distribusion de paquetes para el trafico 111 streaming ) 112 % figure (3); legend ( Trafico enviado ) 113 % figure (4); hist ( t rafaga enviado ) 114 % figure (4); xlabel (Duracion del paquete (s )) 115 % figure (4); ylabel (Cantidad de paquetes ) 116 % figure (4); t i t l e ( Distribusion de rafagas para el trafico 117 streaming ) 118 % figure (4); legend ( Trafico enviado ) Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad D SCRIPT 77 D.3 Script para el calculo de cantidad de conexiones 1 %% Calculo de cantidad de conversaciones de ToIP que se pueden 2 %% establecer en un determinado ancho de banda 3 4 %% Variables , modificar segun sea el caso 5 clear all ; 6 difs=52e  6; 7 s i f s =10e  6; 8 slot =1; % Backoff media 15,5 slots 9 cp media=20e  6  slot ; 10 preamb=96e  6; % Corto , 2Mbps 11 %preamb=192e  6; % Largo , 1Mbps 12 bw max=54e6 ; 13 g729=10e  3; 14 m=2; 15 ip =20; 16 udp=8; 17 rtp =12; 18 mac wifi =34; 19 20 %% Calculos 21 for i =1:bw max 22 bw( i)=i ; 23 end 24 for i =1: length (bw) 25 % Longitud del paquete en bits 26 l=(m  10+ip+udp+rtp+mac wifi )  8; 27 t ack ( i )=(14  (8/bw( i )))+preamb ; 28 % Tiempo de ACK medio sin coliciones 29 t ack media ( i)=cp media+difs+s i f s+t ack ( i ); 30 % Numero de conexiones en un sentido 31 num ow( i)=m  g729/( t ack media ( i)+preamb+(l /bw( i ) ) ) ; 32 % Numero de conexiones bidireccionales 33 num rt( i)=m  g729 /(2  ( t ack media ( i)+preamb+(l /bw( i )))); 34 end 35 figure (1); plot (bw, num rt , b , bw,num ow , r ) 36 figure (1); xlabel (Ancho de banda (Hz)) 37 figure (1); ylabel (Numero de conexiones ) 38 figure (1); title (Cantidad de conexiones de VoIP para un enlace 39 WiFi en modo ad  hoc en funcion del ancho de 40 banda del canal ) 41 figure (1); legend (Round trip , One way) Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad D SCRIPT 78 D.4 Script para generar archivo del traco de vdeo con una compresion de 4 Kbytes 1 %% Generar tamanos y tiempos para 4K 2 3 clear all ; 4 close all ; 5 6 total paquetes =10000; 7 8 %% Creando datos 9 for i =1:3: total paquetes 10 datos ( i ,1)=40000; % microsegundos 11 datos ( i ,2)=1472; 12 end 13 14 for i =2:3: total paquetes 15 datos ( i ,1)=2000; % microsegundos 16 datos ( i ,2)=1472; 17 end 18 19 for i =3:3: total paquetes 20 datos ( i ,1)=4000; % microsegundos 21 datos ( i ,2)=1472; 22 end 23 24 dlmwrite ( trafico enviar 4k . txt , datos , newline , pc , precision , %.0 f ); D.5 Script para generar archivo del traco de vdeo con una compresion de 50 Kbytes 1 %% Generador de archivo de tamanos y tiempos 2 %% Datos 3 4 clear all 5 close all 6 7 %format bank ; 8 paquetes rafaga =25; 9 total paquetes =10000; 10 rafagas =[80 23; 120 99; 160 171; 200 30]; 11 porcentaje rafagas =[7.12 37.77 90.71 100]; Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad D SCRIPT 79 12 tamano paquete=1472; 13 porcentaje paquetes 40 =1.32; 14 cont1=1; 15 cont2=1; 16 cont3=1; 17 cont4=1; 18 cont5=1; 19 cont raf 80 =1; 20 cont raf 120 =1; 21 cont raf 160 =1; 22 cont raf 200 =1; 23 24 %% Construir tamanos 25 for i =1: total paquetes 26 if cont1==paquetes rafaga 27 tamanos tiempos ( i ,1)= floor (random( unif ,700 ,1300)); 28 cont1=1; 29 else 30 tamanos tiempos ( i ,1)=tamano paquete ; 31 cont1=cont1+1; 32 end 33 end 34 35 %% Construir tiempos 36 tamanos tiempos (: ,2)=0; 37 for j=1:total paquetes 38 if tamanos tiempos ( j ,2)==0 39 for i =1: paquetes rafaga : total paquetes 40 %tipo rafaga=floor (random( unif ,0 ,100)); 41 tipo rafaga=unifrnd (0 ,100); 42 if tamanos tiempos ( i ,2)==0 43 if tipo rafaga < =porcentaje rafagas (1) 44 misc=i ; 45 while cont2 < =25 46 tamanos tiempos ( misc ,2)= 47 random( unif ,1.75 e  4,2.75e  4); 48 tamanos tiempos ( misc ,3)=80; 49 cont2=cont2+1; 50 misc=misc+1; 51 end 52 cont2=1; 53 else 54 if tipo rafaga < =porcentaje rafagas (2) 55 misc=i ; 56 while cont3 < =25 Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad D SCRIPT 80 57 tamanos tiempos ( misc ,2)= 58 random( unif ,1.75 e  4,2.75e  4); 59 tamanos tiempos ( misc ,3)=120; 60 cont3=cont3+1; 61 misc=misc+1; 62 end 63 cont3=1; 64 else 65 if tipo rafaga < =porcentaje rafagas (3) 66 misc=i ; 67 while cont4 < =25 68 tamanos tiempos ( misc ,2)= 69 random( unif ,1.75 e  4,2.75e  4); 70 tamanos tiempos ( misc ,3)=160; 71 cont4=cont4+1; 72 misc=misc+1; 73 end 74 cont4=1; 75 else 76 if tipo rafaga < =porcentaje rafagas (4) 77 misc=i ; 78 while cont5 < =25 79 tamanos tiempos ( misc ,2)= 80 random( unif ,1.75 e  4,2.75e  4); 81 tamanos tiempos ( misc ,3)=200; 82 cont5=cont5+1; 83 misc=misc+1; 84 end 85 cont5 ; 86 end 87 end 88 end 89 end 90 end 91 end 92 end 93 end 94 95 %% Calculando el acumulado de tiempos 96 for i=1:total paquetes 97 if i==1 98 tamanos tiempos ( i ,4)= tamanos tiempos ( i , 2 ); 99 else 100 tamanos tiempos ( i ,4)= tamanos tiempos ( i ,2)+ 101 tamanos tiempos ( i  1,4); Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad D SCRIPT 81 102 end 103 end 104 105 %% Calculando tiempos entre rafagas 106 tamanos tiempos (: ,3)= tamanos tiempos (: ,3)  1 e  3; 107 for i=1:total paquetes  1 108 if tamanos tiempos ( i ,1)~= tamano paquete 109 tamanos tiempos ( i +1,2)=tamanos tiempos ( i +1,2)+ 110 tamanos tiempos ( i , 3 ); 111 end 112 end 113 114 datos (: ,2)= tamanos tiempos (: ,1); 115 datos (: ,1)= floor ( tamanos tiempos (: ,2)  1 e6 ); 116 dlmwrite ( trafico enviar . txt , datos , newline , pc , precision , %.0 f ); 117 118 %% Para comparar los resultados simulados y los reales 119 figure (1); bar ( rafagas (: ,1) , rafagas ( : , 2)); 120 figure (2); hist ( tamanos tiempos (1: total paquetes , 3 ) ) ; D.6 Script para el calculo del tama~no del buer 1 %% Determinar caracteristicas del buffer 2 3 clear all 4 5 %% Entrada de capturas 6 % Interfaz en minipc4 Tx 7 datos em1 54= csvread (54Mbps/datos captura buffer em1 1300 . csv ); 8 % Interfaz en minipc3 Rx (supone el tiempo mas largo ) 9 datos p5p1 54= csvread (54Mbps/datos captura buffer p5p1 1300.csv); 10 % Interfaz en minipc4 Tx 11 datos em1 24= csvread (24Mbps/datos captura buffer em1 1300 . csv ); 12 % Interfaz en minipc3 Rx (supone el tiempo mas largo ) 13 datos p5p1 24= csvread (24Mbps/datos captura buffer p5p1 1300.csv); 14 % Interfaz en minipc4 Tx 15 datos em1 11= csvread (11Mbps/datos captura buffer em1 1300 . csv ); 16 % Interfaz en minipc3 Rx (supone el tiempo mas largo ) 17 datos p5p1 11= csvread (11Mbps/datos captura buffer p5p1 1300.csv); 18 % Interfaz en minipc4 Tx 19 datos em1 5= csvread (5.5Mbps/datos captura buffer em1 1300 . csv ); 20 % Interfaz en minipc3 Rx (supone el tiempo mas largo ) 21 datos p5p1 5= csvread (5.5Mbps/datos captura buffer p5p1 1300 . csv ); 22 % Interfaz en minipc4 Tx Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad D SCRIPT 88 293 figure (2); subplot (3 ,1 ,1); ylabel (Ocupacion del buffer ) 294 figure (2); subplot (3 ,1 ,1); title (Ocupacion del buffer de un 295 router de acceso ) 296 figure (2); subplot (3 ,1 ,1); legend (5.5Mbps) 297 298 figure (2); subplot (3 ,1 ,2); plot ( datos 2 (1:114 ,4) , datos 2 (1:114 ,7)) 299 figure (2); subplot (3 ,1 ,2); xlabel ( Referencia de tiempo del 300 procesador) 301 figure (2); subplot (3 ,1 ,2); ylabel (Ocupacion del buffer ) 302 figure (2); subplot (3 ,1 ,2); title (Ocupacion del buffer de un 303 router de acceso ) 304 figure (2); subplot (3 ,1 ,2); legend (2Mbps) 305 306 figure (2); subplot (3 ,1 ,3); plot (datos 1 (1:114 ,4) , datos 1 (1:114 ,7)) 307 figure (2); subplot (3 ,1 ,3); xlabel ( Referencia de tiempo del 308 procesador) 309 figure (2); subplot (3 ,1 ,3); ylabel (Ocupacion del buffer ) 310 figure (2); subplot (3 ,1 ,3); title (Ocupacion del buffer de un 311 router de acceso ) 312 figure (2); subplot (3 ,1 ,3); legend (1Mbps) 313 314 figure (3); plot ( datos 54 (1:114 ,4) , datos 54 (1:114 ,7) , 315 datos 24 (1:114 ,4) , datos 24 (1:114 ,7) , datos 11 (1:114 ,4) , 316 datos 11 (1:114 ,7) , datos 5 (1:114 ,4) , datos 5 (1:114 ,7) , 317 datos 2 (1:114 ,4) , datos 2 (1:114 ,7) , datos 1 (1:114 ,4) , 318 datos 1 (1:114 ,7)) 319 figure (3); xlabel ( Referencia de tiempo del procesador ( s )) 320 figure (3); ylabel (Ocupacion del buffer ) 321 figure (3); title (Ocupacion del buffer de un router de acceso ) 322 figure (3); legend (54Mbps,24Mbps,11Mbps,5.5Mbps,2Mbps,1Mbps) 323 324 figure (4); plot ( datos 54 (: ,4) , datos 54 (: ,7) , datos 24 (: ,4) , 325 datos 24 (: ,7) , datos 11 (: ,4) , datos 11 (: ,7) , datos 5 (: ,4) , 326 datos 5 (: ,7) , datos 2 (: ,4) , datos 2 (: ,7) , datos 1 (: ,4) , 327 datos 1 (: ,7)) 328 figure (4); xlabel ( Referencia de tiempo del procesador ( s )) 329 figure (4); ylabel (Ocupacion del buffer ) 330 figure (4); title (Ocupacion del buffer de un router de acceso ) 331 figure (4); legend (54Mbps,24Mbps,11Mbps,5.5Mbps,2Mbps,1Mbps) Metodologa para el Modelado y el Analisis de Flujos IP Multimedia: Medidas de Calidad