Repositorio Institucional de Documentos

Proyecto Final de Carrera Ingenier´ıa en Inform´atica Curso 2009/2010 Banco de pruebas de una Red Inal´ambrica Mesh basada en el protoc´olo IEEE 802.11s Luis Javier S´anchez Cuenca Director: Ulf Bodin Communication Networks Research Group Dept. of Computer Science and Electrical Engineering Lule˚a University of Technology Ponente: Sergio Ilarri Artigas Departamento de Inform´atica e Ingenier´ıa de Sistemas Centro Polit´ecnico Superior Universidad de Zaragoza Agosto de 2010 RESUMEN La tecnolog´ıa inal´ambrica Mesh es una de las tecnolog´ıas que van a jugar un importante papel dentro de las redes de comunicaciones inal´ambricas en la pr´oxima d´ecada. Con el uso de esta tecnolog´ıa ser´a posible llevar a cabo un sue˜no dentro de las redes de comunicaciones: poder conectarse a la red desde cualquier sitio a cualquier hora muy f´acilmente y con un coste muy bajo. Las mejoras que ofrece este tipo de tecnolog´ıa son debido a la capacidad de auto organizaci´on de la que dispone, ya que reduce significativamente la complejidad y el mantenimiento de la red, lo que repercute en que la inversi´on a realizar es m´ınima. El objetivo principal de este proyecto es la creaci´on de una Red Inal´ambrica Mesh (WMN, Wireless Mesh Network) basada en el proyecto Open80211s, que sirva como banco de pruebas para analizar el rendimiento y comportamiento de esta nueva tecnolog´ıa. Este Proyecto Fin de Carrera ha sido realizado en la Universidad Tecnol´ogica de Lule˚a dentro de su Grupo de Investigaci´on de Redes de Comunicaci´on, con el prop´osito de avanzar en el desarrollo e implantaci´on de esta tecnolog´ıa emergente. Los objetivos de este proyecto son construir y verificar dos paquetes de instalaci´on para evaluar diferentes topolog´ıas de una Red Inal´ambrica Mesh basada en el protocolo 802.11s. El primer paquete de instalaci´on ser´a desarrollado bajo el sistema operativo Ubuntu-Linux, utilizando la implementaci´on del proyecto open80211s, y el segundo ser´a desarrollado en el simulador de redes NS-3. La evaluaci´on incluye pruebas de calidad y rendimiento de la red para diferentes topolog´ıas y tr´afico de datos, comparando los resultados obtenidos en ambos sistemas. Con la realizaci´on de este proyecto obtenemos dos sistemas en los que se puede analizar la tecnolog´ıa inal´ambrica Mesh. Por un lado, tenemos un sistema real donde podemos analizar la red bajo condiciones reales y por otra parte tenemos un sistema donde podemos simular la red con las mismas condiciones que en la realidad. Se han podido comparar los resultados y se ha determinado que se ajustan a la realidad, pero con algunos matices a la hora de implementar las interferencias del medio. Con los resultados obtenidos podemos modificar, mejorar y ampliar las implementaciones utilizadas obteniendo un sistema m´as eficaz y robusto. iii AGRADECIMIENTOS Me gustar´ıa dedicar todos estos a˜nos de sacrificio y esfuerzo culminados con este Proyecto Fin de Carrera a mi abuelo, Jos´e S´anchez P´erez, por ense˜narme como comportarse en este mundo. Donde quiera que est´es, muchas gracias ”yayo”. Agradecer al Grupo de Investigaci´on de Redes de Comunicaci´on de la Universidad Tecnol´ogica de Lule˚a, particularmente a mi supervisor, Ulf Bodin, por ayudarme a realizar este PFC. Tambi´en me gustar´ıa agradecer a Sergio Ilarri, mi ponente, su dedicaci´on y su r´apida respuesta a todas mis dudas en la realizaci´on de este Proyecto Fin de Carrera. Por ´ultimo, me gustar´ıa dar las gracias a toda mi familia, abuelas, t´ıos/as, primos/as y, en especial, a mi madre, mi padre y mi hermana, por estar ah´ı y aguantarme. Tambi´en agradecer a todos mis amigos por los buenos momentos para seguir adelante. Zaragoza −Agosto 2010 Luis Javier S´anchez Cuenca v ´ Indice general Cap´ ıtulo 1 – Introducci´ on 1 1.1. Motivaci´on..................................... 1 1.2. Objetivos ..................................... 2 1.3. Alcance ...................................... 3 1.4. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5. Marco temporal del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Cap´ ıtulo 2 – Contexto Tecnol´ ogico 7 2.1. Redes Inal´ambricas Mesh (WMN) . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Est´andares..................................... 8 2.3. Estudioderesultados............................... 9 2.4. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Cap´ ıtulo 3 – WMN real con Ubuntu 15 3.1. Instalaci´on de Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Paquete de instalaci´on de Open80211s . . . . . . . . . . . . . . . . . . . . . 17 3.3. Configuraci´on de la red WMN . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. Topolog´ıa de la red WMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.5. Experimentos de la red WMN . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Cap´ ıtulo 4 – WMN en el simulador NS-3 33 4.1. Simulador de redes NS-3 ............................. 33 4.2. Implementaci´on del banco de pruebas en NS-3 ................. 33 4.3. ExperimentosenNS-3 .............................. 39 4.4. Resultados de la simulaci´on en NS-3 ...................... 40 Cap´ ıtulo 5 – Comparativa de resultados 43 5.1. Throughput .................................... 43 5.2. An´alisis de muestras de ficheros “.pcap” .................... 45 Cap´ ıtulo 6 – Conclusiones y Trabajo Futuro 49 6.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 vii 6.2. Conclusiones personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.3. TrabajoFuturo .................................. 51 Anexo A – Redes WMN 57 A.1.Arquitecturadelared .............................. 57 A.2.Caracter´ısticas .................................. 59 A.3. Escenarios de aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Anexo B – An´ alisis de resultados salto a salto en el banco de pruebas 65 Anexo C – Simulador NS-3 71 C.1. Alcance de NS-3 ................................. 71 C.2. Mecanismos y protocolos soportados . . . . . . . . . . . . . . . . . . . . . . 71 C.3.Casosdeuso.................................... 72 Anexo D – An´ alisis de resultados salto a salto en NS-3 77 Anexo E – Lista de Acr´ onimos 81 Anexo F – Memoria en Ingl´ es 83 viii ´ Indice de figuras 1.1. Diagrama de Gantt del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Adaptador Inal´ambrico USB, D-Link DWL-G122 Wireless G USB ...... 16 3.2. Topolog´ıa en l´ınea de una red WMN . . . . . . . . . . . . . . . . . . . . . . 19 3.3. Topolog´ıa experimento I, banco de pruebas de WMN . . . . . . . . . . . . . 20 3.4. Escenario experimento I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.5. Throughput paraUDPyTCP.......................... 23 3.6. Topolog´ıa experimento II, banco de pruebas de WMN . . . . . . . . . . . . . 24 3.7. Escenario 1 del experimento II . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.8. Escenario 2 del experimento II . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.9. Escenario 3 del experimento II . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.10. Escenario 4 del experimento II . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.11. Escenario 5 del experimento II . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.12. Escenario 6 del experimento II . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.13. Escenario 7 del experimento II . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.14. Canales de transmisi´on inal´ambricos . . . . . . . . . . . . . . . . . . . . . . 29 3.15. Throughput total del banco de pruebas . . . . . . . . . . . . . . . . . . . . . 30 3.16. Throughput total vs. Intervalo de confianza 90 % vs. M´aximo&M´ınimo del bancodepruebas ................................. 31 4.1. Sistema de coordenadas de la topolog´ıa en l´ınea en NS-3 ........... 34 4.2. Diferentes modelos de p´erdidas en la propagaci´on disponibles en NS-3 . . . . 35 4.3. Throughput total de la simulaci´on en NS-3 ................... 40 4.4. Throughput total vs. Intervalo de confianza 90 % vs. M´aximo&M´ınimo de la simulaci´on en NS-3 ................................ 41 5.1. Comparaci´on del Throughput entre el banco de pruebas y el simulador NS-3 44 5.2. Throughput del banco de pruebas vs. NS-3 vs. Intervalo de confianza 90 % vs. M´aximo&M´ınimo................................. 44 5.3. RTTdelostresejemplos............................. 46 5.4. Tiempos de secuencia de los tres ejemplos PCAP files............. 47 A.1. Infraestructura Columna Vertebral . . . . . . . . . . . . . . . . . . . . . . . 59 A.2.ClienteWMN................................... 59 A.3.WMNH´ıbrida................................... 60 B.1. Promedio del throughput del banco de pruebas para 1 salto . . . . . . . . . . 65 ix 4 Cap´ ıtulo 1: Introducci´ on conclusiones obtenidas de los experimentos realizados. El quinto cap´ıtulo muestra la comparaci´on de los resultados obtenidos en el banco de pruebas real y los obtenidos en el simulador NS-3. Finalmente, en el sexto cap´ıtulo se detallan las conclusiones que hemos obtenido al realizar este PFC y se marcan las l´ıneas de trabajo para continuar con el trabajo realizado. Al final de este documento se encuentran los anexos. En el Anexo A se explica con detalle la estructura, caracter´ısticas y escenarios de aplicaci´on de las redes WMN. En el Anexo B y en el Anexo D se explican los resultados obtenidos en el banco de pruebas real y en la simulaci´on en NS-3 salto a salto, respectivamente. En el Anexo C se analiza el funcionamiento y las caracter´ısticas principales del simulador NS-3. En el Anexo E podemos ver una lista detallada de todos los acr´onimos utilizados en la memoria, con su significado en castellano y en ingl´es. Finalmente, en el Anexo F encontramos la memoria original del proyecto realizado, presentado y aprobado en Universidad Tecnol´ogica de Lule˚a. Esta memoria se encuentra realizada en ingl´es, y en ella , as´ı como sus anexos, se puede consultar todo el trabajo realizado. Al realizar la adaptaci´on de esta memoria se han mantenido algunos t´erminos del ingl´es como mesh,WMN,routers, etc. debido a que en el estudio de redes de comunicaci´on, estos t´erminos en castellano no son significativos, ya que se utilizan los t´erminos originales, es decir, en ingl´es. 1.5. Marco temporal del proyecto En este apartado se muestra la planificaci´on del trabajo llevado a cabo para la realizaci´on de este PFC. Como se puede ver en el Diagrama de Gantt (Figura 1.1), el trabajo del proyecto ha sido dividido en semanas de trabajo a tiempo completo (40 horas por semana). El trabajo de cada semana es el descrito a continuaci´on. S00-S01: Estudiar los est´andares relevantes de IEEE 802.11 y el uso de paquetes experimentales en Linux. Identificar los requisitos del hardware necesario para la creaci´on del banco de pruebas. S01-S02: Documentar la motivaci´on del proyecto, los objetivos y el alcance del PFC. S02-S03: Identificar las funcionalidades y los par´ametros a analizar para verificar que una sencilla WMN basada en el est´andar 802.11s funcione correctamente. S03-S06: Construir un paquete de instalaci´on para configurar una WMN en dos ordenadores funcionando con el sistema operativo Ubuntu. S06-S07: Comprobar el correcto funcionamiento de esta instalaci´on. 1.5. Marco temporal del proyecto 5 S07-S08: Documentar el paquete de instalaci´on y las pruebas realizadas para este proyecto. S08-S09: Identificar las funcionalidades y los par´ametros a analizar para verificar que una WMN de ocho dispositivos funcione correctamente. S09-S12: Instalar el paquete en los ocho ordenadores. Configurar la WMN. S12-S13: Realizar las pruebas necesarias para demostrar el comportamiento de la red. S13-S14: Documentar las pruebas, los resultados obtenidos y las conclusiones alcanzadas. S14-S15: Estudiar el entorno del simulador NS-3 y la implementaci´on existente del est´andar 802.11s. S15-S18: Construir un paquete de instalaci´on para probar la misma red y los mismos escenarios que en el banco de pruebas real teniendo en cuenta que se utilizar´an los mismos par´ametros para el an´alisis del comportamiento de la red. S18-S19: Realizar las pruebas de instalaci´on y an´alisis de la red en NS-3. S19-S20: Documentar el paquete de instalaci´on y las pruebas realizadas con el simulador NS-3. S20-S21: Documentar las discrepancias entre los resultados obtenidos en el banco de pruebas real y en el simulado, as´ı como documentar las mejoras propuestas. S21-S23: Finalizar la documentaci´on del PFC para su presentaci´on y publicaci´on. Figura 1.1: Diagrama de Gantt del proyecto 6 Cap´ ıtulo 1: Introducci´ on Esta planificaci´on presentada es acorde con el trabajo realizado en la Universidad Tecnol´ogica de Lule˚a. El tiempo necesario para la adaptaci´on a los requisitos establecidos en las normas del Proyecto Fin de Carrera del Centro Polit´ecnico Superior de la Universidad de Zaragoza de la memoria realizada en ingl´es ha sido de tres semanas de trabajo completo. CAP´ ITULO 2 Contexto Tecnol´ ogico A continuaci´on se puede encontrar una breve descripci´on de las tecnolog´ıas que fueron utilizadas en el desarrollo del presente PFC, persiguiendo con ello que el lector se familiarice con ellas. Se comienza hablando de las Redes Inal´ambricas Mesh (WMN, Wireless Mesh Networks), se sigue hablando de los est´andares que est´an siendo desarrollados actualmente, se contin´ua explicando que herramientas se han utilizado para el estudio de los resultados y finalmente se describen las herramientas software y hardware utilizadas. 2.1. Redes Inal´ ambricas Mesh (WMN) Una WMN est´a formada por un conjunto de nodos que pueden ser routers mesh1o clientes mesh. Todo cliente mesh puede actuar como router ya que todo nodo perteneciente a una red mesh permite el paso de paquetes de informaci´on a trav´es de ´el hacia otros nodos, pero no es capaz de actuar como puente o puerta de enlace. Los routers mesh forman la espina dorsal de la red proveyendo acceso a la red formando mallas con otros nodos mesh. Los nodos mesh se encargan del establecimiento y mantenimiento de la conexi´on de la red autom´aticamente, es decir, la red se auto-organiza y auto-configura din´amicamente creando una red ad hoc. Esta caracter´ıstica brinda grandes ventajas a este tipo de redes como el bajo coste de instalaci´on, el f´acil mantenimiento y la robustez de la red, que proporcionan una gran cobertura y un servicio muy fiable. La integraci´on de WMN con otras redes como Internet, redes de tel´efonos m´oviles, IEEE 802.16, IEEE 802.11, IEEE 802.15 [2], redes de sensores, etc., se realiza a trav´es de los routers mesh con puentes o puertas de enlace. Esta cualidad ofrece la posibilidad de integrar usuarios de distintas redes, proporcionando un servicio com´un imposible con el uso de otras redes convencionales. El despliegue de una 1La palabra mesh viene del ingl´es, que en castellano quiere decir malla. En este contexto se refiere con mesh a aquellos elementos que conforman la red y que funcionan con esta tecnolog´ıa. Se les denomina mesh porque los nodos que pertenecen la red forman una malla que permite la comunicaci´on entre todos los dispositivos 7 8 Cap´ ıtulo 2: Contexto Tecnol´ ogico WMN no es muy complicado debido a que todos los componentes necesarios est´an disponibles en los protocolos de enrutado ad hoc (por ejemplo, protocolo IEEE 802.11 MAC). Las Redes Inal´ambricas Mesh son un prometedor avance en la tecnolog´ıa inal´ambrica para numerosas aplicaciones como redes dom´esticas de banda ancha, redes de una comunidad de vecinos, redes empresariales, redes p´ublicas o redes en lugares donde es muy dif´ıcil y costosa la implantaci´on de una red cableada. Est´an adquiriendo mucho inter´es dentro del sector de los proveedores de Internet, gracias a la robustez, fiabilidad y bajo coste que ofrecen, puesto que pueden ser ampliadas conforme sea necesario. Cuantos m´as nodos haya instalados en la red, mejor ser´a la conectividad y el servicio que podr´an disfrutar todos los usuarios. Son varias las compa˜n´ıas que se han dado cuenta del potencial que esta tecnolog´ıa ofrece, por ello, han sido establecidos en varias universidades, laboratorios de investigaci´on con diversos bancos de pruebas para analizar el comportamiento de este tipo de redes, como el realizado en este PFC. Para profundizar acerca de esta tecnolog´ıa puede consultarse el Anexo A, donde se describe con mayor detalle. 2.2. Est´ andares La gran cantidad de fabricantes que est´an produciendo productos para el desarrollo de redes WMN indica el incremento del inter´es de la industria en este tema. Adem´as, los principales grupos de estandarizaci´on est´an definiendo est´andares de WMN [3, 4] que permitan una mejor interoperabilidad entre las redes de comunicaci´on emergentes y las existentes. El grupo de trabajo IEEE 802.16 es el encargado de desarrollar los est´andares Mesh para la capa f´ısica y la capa de control de acceso al medio. Dentro de este grupo existen varios subgrupos con diferentes tareas: IEEE 802.16a: Encargado de a˜nadir el modo “mesh” a la arquitectura multipunto (PMP). IEEE 802.16b: Proporciona la caracter´ıstica Calidad del Servicio (QoS). IEEE 802.16c: Da soporte a la interoperabilidad entre protocolos con estructuras definidas para pruebas. IEEE 802.16d: Proporciona las extensiones de la capa f´ısica necesarias para permitir el acceso al medio. IEEE 802.16e: Desarrolla los medios para mejorar la movilidad entre estaciones m´oviles (MSS). IEEE 802.16f: Proporciona soporte para la funci´on multisalto. IEEE 802.16g: Proporciona entrega eficiente y Calidad de Servicio (QoS). 2.3. Estudio de resultados 9 El grupo de trabajo IEEE 802.11s desarrolla la especificaci´on de una nueva familia de protocolos para la instalaci´on, configuraci´on y funcionamiento de las redes WMN. Esta implementaci´on trabaja con la capa f´ısica existente en los protocolos IEEE 802.11a/b/g/n e incluye las extensiones para la formaci´on de topolog´ıas que hacen posible la autoconfiguraci´on de las Redes Inal´ambricas Mesh. El IEEE 802.15 est´a encargado de especificar las funciones de la capa f´ısica y de la capa de control de acceso al medio, para Redes Inal´ambricas de ´ Area Personal (WPAN). Espec´ıficamente, dentro de este grupo, est´a el IEEE 802.15.5 que provee la arquitectura necesaria para la interoperabilidad, estabilidad y escalabilidad en diferentes topolog´ıas de WMN para dispositivos WPAN. El acceso inal´ambrico basado en el est´andar IEEE 802.11 se est´a convirtiendo en el m´as com´un, tanto para el uso dom´estico c´omo para redes en lugares p´ublicos como aeropuertos, restaurantes y otros establecimientos donde el acceso a Internet es muy demandado. El IEEE est´a terminando el desarrollo del est´andar 802.11s, que es una extensi´on del 802.11 para Redes Inal´ambricas Mesh. 802.11s facilita dos niveles de infraestructura, donde el nivel m´as bajo provee el acceso de los clientes al nivel superior, la estructura de la red inal´ambrica. El nivel superior constituye la red de retorno (blackhaul) que facilita las puertas de enlace a redes cableadas como Internet, u otro tipo de redes. El consorcio open80211s [1] est´a desarrollando una implementaci´on del est´andar IEEE 802.11s v´alida para el n´ucleo de Linux y para distribuciones Linux como Ubuntu [5]. Tambi´en el IITP [6], Instituto de Investigaci´on para Problemas de Transmisi´on de Informaci´on de Rusia, incluye soporte para el protocolo 802.11s en el simulador desarrollado por ellos (NS- 3)[7]. 2.3. Estudio de resultados Para el an´alisis y evaluaci´on de la red, tanto en el banco de pruebas real como en el simulador, se han centrado todos los esfuerzos en el estudio del throughput. El throughput es el promedio de paquetes de informaci´on entregados satisfactoriamente a trav´es de la red por un canal de comunicaci´on en concreto. Habitualmente se mide en bits por segundo (bit/s o bps), aunque en alguno de nuestros experimentos lo hemos medido en Mbps. Se han usado diferentes f´ormulas para el c´alculo del throughput dependiendo del tipo de protocolo de comunicaci´on utilizado, UDP o TCP. En el caso de UDP se ha utilizado la siguiente f´ormula: Throughput =DatosT otalesRecibidos TiempoTotal 10 Cap´ ıtulo 2: Contexto Tecnol´ ogico Donde: Datos Totales Recibidos: Bits recibidos (paquetes UDP) en el dispositivo destino enviados por la fuente. Tiempo Total: Tiempo transcurrido desde que la fuente manda el primer paquete hasta que la fuente manda el ´ultimo paquete. Y para TCP se ha utilizado la siguiente f´ormula: Throughput =DatosT otalesTransmitidos +DatosTotalesRecibidos TiempoTotal Donde: Datos Totales Transmitidos: Bits transmitidos (paquetes TCP) desde la fuente al destino. Datos Totales Recibidos: Bits recibidos (ACK) por la fuente desde el destino. Tiempo Total: Tiempo transcurrido desde que la fuente env´ıa el primer paquete hasta que la fuente recibe el ´ultimo reconocimiento (ACK). Aunque se han utilizado diferentes f´ormulas dependiendo del protocolo de comunicaci´on utilizado, ambos throughputs son comparables debido a que con ellos se mide el tr´afico total de la red. Cuando se calcula el throughput para UDP, s´olo se utiliza el total de datos transmitidos porque UDP manda los paquetes sin recibir ning´un reconocimiento (ACK) desde el dispositivo destino, mientras que cuando se calcula el throughput para TCP se tiene en cuenta que este protocolo s´ı que recibe reconocimientos desde el destino. El c´alculo del intervalo de confianza para el throughput se realiza de acuerdo con la siguiente f´ormula: Confianza =N·σ 2 √n Y el intervalo de confianza es (X- Confianza, X+ Confianza), donde: N: Valor de la distribuci´on Normal de acuerdo con el nivel de confianza elegido. σ:Desviaci´on est´andar de las muestras de throughput. n: N´umero de muestras de throughput. X:Promedio de las muestras de throughput. 2.4. Herramientas utilizadas En esta secci´on se muestran las herramientas software y hardware utilizadas en el desarrollo de este PFC. 2.4. Herramientas utilizadas 11 2.4.1. Sistema Operativo Ubuntu es un sistema operativo basado en Linux, t´ermino gen´erico utilizado para referirse a un sistema operativo en apariencia similar a Unix pero con un n´ucleo propio. Ubuntu como sistema operativo es un claro ejemplo de colaboraci´on para el desarrollo de software libre y gratis. Habitualmente las fuentes y el c´odigo de los programas y del propio sistema operativo puede ser usado, modificado y redistribuido, comercial y no comercialmente, por cualquier persona bajo los t´erminos recogidos en la Licencia P´ublica GNU GPL y otras licencias de software libre. Se ha escogido Ubuntu como sistema operativo porque: Esta libre de cargos, es decir, no hay que pagar ninguna licencia para utilizarlo. Puede ser descargado, usado y compartido con otros usuarios gratuitamente. Es posible tener siempre las ultimas actualizaciones del software que el mundo del software libre ofrece. En Ubuntu est´a implementado el paquete open80211s que se necesita para configurar la WMN. Se ha utilizado Ubuntu 9.04 [5] dado que al iniciar este proyecto era la ´ultima versi´on disponible del sistema operativo y la que ofrec´ıa todas las herramientas necesarias para realizarlo. La versi´on del n´ucleo que Ubuntu ten´ıa de serie era 2.6.28, pero debido a los requisitos t´ecnicos de la tarjeta inal´ambrica escogida, explicados m´as adelante, se actualiz´o el n´ucleo hasta la versi´on 2.6.29. 2.4.2. WMN Para analizar el comportamiento de la red se utiliz´o Wireshark [8] e Iperf [9] (o Jperf, versi´on en aplicaci´on Iperf-java) . La raz´on por la cu´al se escogi´o Wireshark es porque es el analizador de protocolos de red m´as com´unmente utilizado y con suficientes recursos para alcanzar los objetivos marcados. Iperf ha sido escogida porque tras el an´alisis de las herramientas disponibles actualmente, se trata de una moderna herramienta, escrita en C++, que ofrece la posibilidad de crear tr´afico de datos en la red (tanto TCP como UDP) y medir el throughput de la red. Para identificar qu´e canal de transmisi´on era el ´optimo para el funcionamiento de la red, se ha empleado Network Stumbler ya que ofrece la posibilidad de conocer qui´en est´a utilizando cada canal y la relaci´on se˜nal/ruido de transmisi´on de qui´en utilizaba el canal. Est´a herramienta es muy ´util debido al inter´es de probar la red en un canal escasamente utilizado. Otras herramientas utilizadas: 12 Cap´ ıtulo 2: Contexto Tecnol´ ogico Ping: Es una herramienta utilizada para la administraci´on de redes de ordenadores. Sirve para probar cu´ando un host es alcanzable a trav´es de un Protocolo de Internet (IP) y para medir el round-trip time (en adelante, RTT), tiempo que cuesta mandar paquetes desde el host local hasta el ordenador destino, incluidas las interfaces propias del host local. Tcpdump: Es un analizador de paquetes que funciona a trav´es de la l´ınea de comandos. Permite al usuario interceptar y mostrar TCP/IP y otros paquetes mientras son transmitidos o recibidos a trav´es de la red a la que el ordenador est´a conectado. Route: Es una herramienta que permite manipular la tabla de enrutamiento IP. Su principal uso es configurar rutas est´aticas encaminadas hacia hosts o redes espec´ıficas a trav´es de una interface determinada. Iptables: Provee un sistema basado en una tabla que act´ua como firewall filtrando o modificando paquetes. Tambi´en puede ser usado para crear un enrutado est´atico utilizando la direcci´on MAC. Iw: Es una nueva herramienta, todav´ıa bajo desarrollo, utilizada para configurar los dispositivos inal´ambricos del ordenador. Iwconfig: Herramienta utilizada para configurar los par´ametros de la interfaz de la red inal´ambrica. Ipconfig: Es una utilidad que se comunica con el agente de configuraci´on IP para recuperar y establecer los par´ametros de configuraci´on IP. La versi´on actual estable de Wireshark es 1.2.2, de Iperf es 2.0.8, de Network Stumbler 0.4.0 (Build 554), y de tcpdump es 3.9.8. Para c´alculos matem´aticos y representaci´on de gr´aficos se ha utilizado Matlab y para elaborar esta memoria se ha utilizado L A T EX. 2.4.3. Hardware Los ocho ordenadores de sobremesa utilizados en la primera parte de este proyecto tienen las siguientes caracter´ısticas: Procesador: Intel R Pentium R 4 CPU 2.40 GHz Tama˜no de Cache: 512 KB Capacidad del disco duro: 120 GB Memoria Ram: 256 MB Puertos USB: 6 puertos USB 1.1 (Velocidad de transferencia de datos de 12 Mbit/s) 2.4. Herramientas utilizadas 13 El ordenador utilizado en la segunda parte del proyecto, las simulaciones en NS-3, es un ordenador port´atil con las siguientes caracter´ısticas: Procesador: Intel R Core 2 duo CPU P8600 2.40 GHz (2 CPUs) Tama˜no de Cache: 512 KB Capacidad del disco Duro: 300 GB Memoria Ram: 3 GB Sobre la tarjeta de red inal´ambrica utilizada, se analiza en el cap´ıtulo siguiente qu´e tarjeta es la que mejor se adapta al sistema operativo escogido y puede ser utilizada con el proyecto open80211s. 20 Cap´ ıtulo 3: WMN real con Ubuntu Figura 3.3: Topolog´ıa experimento I, banco de pruebas de WMN Entre los nodos 6 y 7 dos paredes. Entre los nodos 7 y 8 una pared. El conocer la existencia de paredes entre los diferentes nodos es muy importante porque la se˜nal de emisi´on de las antenas disminuye cuando atraviesa las paredes. En este experimento se quiso tener la menor interferencia entre nodos posible, por lo que se trat´o de aislar las antenas. Para aislar las antenas se meti´o cada una en una lata de aluminio vac´ıa, despu´es se rode´o cada antena con papel de aluminio dejando solo el cable fuera del aluminio. Para ver si el aislamiento cumpl´ıa su funci´on se midi´o antes y despu´es de aislar las antenas el RSS3y se comprob´o que disminu´ıa. Utilizando esta t´ecnica se consigui´o aislar algunos nodos, pero no se consigui´o lo que que se buscaba, que cada nodo s´olo se comunicara directamente con sus vecinos m´as pr´oximos. Distancias Nodo 1 →Nodo 2 9.20 m Nodo 2 →Nodo 3 5.90 m Nodo 3 →Nodo 4 7.70 m Nodo 4 →Nodo 5 4.50 m Nodo 5 →Nodo 6 11.43 m Nodo 6 →Nodo 7 10.60 m Nodo 7 →Nodo 8 8.00 m Tabla 3.2: Distancias entre nodos en la topolog´ıa del experimento I Los par´ametros de la red est´an descritos en la Tabla 3.3, donde se puede ver los par´ametros y el valor utilizado para el experimento. 3Received Signal Strength, Intensidad de la Se˜nal Recibida. 3.5. Experimentos de la red WMN 21 Par´ametro Valor Enrutamiento Din´amico Velocidad 54 Mb/s Potencia Se˜nal de Transmisi´on 18 dBm Frecuencia 2437 e6 (Canal 6) RTS/CTS Apagado Fragmentaci´on Apagado Gesti´on de Energ´ıa Encendido Tabla 3.3: Par´ametros de la red del experimento I Escenario El escenario del experimento (Figura 3.4) permite conocer el rendimiento de la red cuando se manda tr´afico desde el primer nodo al segundo, una vez finalizada la transmisi´on, mandar del primero al tercero, y as´ı sucesivamente hasta el ´ultimo nodo. Figura 3.4: Escenario experimento I Para hacer este experimento se envi´o tr´afico utilizando el generador de tr´afico Iperf. Se utilizar´on dos protocolos de env´ıo de datos, UDP y TCP, configurando el mismo escenario para ambos (detalles en la Tabla 3.4). Protocolo de Transporte UDP Protocolo de Transporte TCP N´umero de repeticiones por nodo 5 N´umero de repeticiones por nodo 5 Tama˜no del Buffer 41KB Longitud del Buffer 2KB Tama˜no de Paquete 1.5KB Tama˜no m´aximo del segmento 1.5KB Puerto de conexi´on 5001 Tama˜no de ventana 56KB Puerto de conexi´on 5001 Tabla 3.4: Par´ametros del experimento I 22 Cap´ ıtulo 3: WMN real con Ubuntu 3.5.2. Resultados experimento I Despu´es de configurar todos los par´ametros descritos en las secciones previas, se utiliz´o Jperf, un interfaz gr´afico de Iperf, que permiti´o calcular el throughput de la red durante todo el experimento. El experimento empez´o utilizando el protocolo UDP y se termin´o con el protocolo TCP. El throughput obtenido en cada prueba se muestra en el Anexo D de la memoria en ingl´es. Con todos los resultados obtenidos se trazar´on dos gr´aficos que representan el throughput, uno con UDP y otro con TCP (Figura 3.5), y ayudan a analizar los resultados de este experimento. En el gr´afico de UDP se puede ver c´omo el throughput aumenta de 3 a 6 saltos. Esto indica que el comportamiento no es correcto, ya que el throughput deber´ıa disminuir cuantos m´as nodos hay involucrados en la comunicaci´on, puesto que se est´a utilizando la misma frecuencia y el mismo canal de transmisi´on. En el gr´afico de TCP tambi´en se puede ver este comportamiento pero no con una diferencia tan grande, se ve que de 6 a 7 saltos el throughput aumenta. La raz´on de este comportamiento se encuentra en que los nodos no est´an aislados como se quer´ıa, y no se ha conseguido impedir la comunicaci´on directa entre nodos que no est´an pr´oximos. Debido a este hecho, cuando se transmiten los datos, la red escoge la v´ıa m´as corta (trabaja con enrutamiento din´amico) y se salta nodos para llegar al destino, lo que mejora el throughput. La lectura que se hace de estos resultados es que la topolog´ıa creada no es una l´ınea y que el sistema de aislamiento no funciona correctamente. Otro problema encontrado es que la velocidad de transmisi´on de datos utilizada es de 54 Mbit/s, pero nunca se consigue llegar a este rendimiento, es m´as, en todo el experimento, el ancho de banda m´aximo conseguido, est´a por debajo de 12 Mbit/s. Al principio se pens´o que era debido a que hab´ıa alg´un usuario utilizando el mismo canal de transmisi´on, pero utilizando el programa Network Stumbler se vio que el canal estaba siendo utilizado pero no tanto como para sufrir un descenso tan grande. Otra posible explicaci´on que se pens´o fue que la opci´on fallback to lower transmission rate4estaba activada y al existir tr´afico en el canal se hab´ıa activado, bajando la velocidad de transmisi´on hasta 12 Mbit/s, pero se comprob´o que no estaba activa esta opci´on. Tras pensar cu´al pod´ıa ser el motivo, se cay´o en la cuenta de que los ordenadores utilizaban puertos USB 1.1 para la conexi´on con las antenas inal´ambricas, lo que significaba que, de acuerdo con la especificaci´on de USB 1.1, la m´axima velocidad de transmisi´on que pod´ıa alcanzar era de 12 Mbit/s. Tambi´en se observ´o que el throughput de la red no es muy alto, pero esto es debido a que hay muchas paredes entre los nodos y adem´as el aislamiento de las antenas debilita la se˜nal. Con la realizaci´on de este experimento se obtuvo importante informaci´on del comportamiento de la red, y para los siguientes experimentos se cambiaron los siguientes aspectos: 4Reducci´on autom´atica de la velocidad de transmisi´on o banda ancha 3.5. Experimentos de la red WMN 23 Para asegurar que la topolog´ıa de la red es una l´ınea y los nodos s´olo se comunican con sus nodos m´as pr´oximos (como m´aximo uno a su derecha y otro a su izquierda) se utiliz´o enrutamiento est´atico. Para evitar problemas con los puertos USB, se estableci´o como velocidad de transmisi´on 11 MBits/s y como medida de seguridad, antes de empezar el experimento, se mir´o con el programa Network Stumbler que canal era el menos utilizado y as´ı transmitir por el. Para reducir el problema de bajo throughput, se quitaron de todas las antenas las latas y el papel de aluminio y se cambi´o el lugar donde estaban ubicados los ordenadores intentando que no hubiera ning´un obst´aculo entre los nodos m´as cercanos. Figura 3.5: Throughput para UDP y TCP 24 Cap´ ıtulo 3: WMN real con Ubuntu 3.5.3. Descripci´ on Experimento II La topolog´ıa de este experimento consisti´o en poner los nodos de la red en los pasillos del edificio creando una l´ınea, pero a diferencia del experimento anterior, intentando que las paredes no actuaran debilitando la se˜nal entre los nodos. La situaci´on de los nodos de esta red en el edificio se puede ver en la Figura 3.6. Figura 3.6: Topolog´ıa experimento II, banco de pruebas de WMN Con esta topolog´ıa se quiso obtener las menores interferencias posibles entre nodos y que la comunicaci´on entre nodos cercanos fuera lo mejor posible. Las distancias entre nodos esta descritas en la Tabla 3.5. Para asegurar que la comunicaci´on fluye por el nodo m´as cercano hasta el destino se utiliz´o enrutamiento est´atico por IP y por filtrado de direcci´on MAC. Los par´ametros de esta topolog´ıa est´an descritos en la Tabla 3.6, donde se puede ver todos los cambios realizados respecto del experimento I. Se cambio el canal de transmisi´on al n´umero 3 debido a que se vio que era el canal menos usado. Para generar tr´afico TCP (ver Tabla 3.7) se utiliz´o Iperf. 3.5. Experimentos de la red WMN 25 Distancias Nodo 1 →Nodo 2 37.96 m Nodo 2 →Nodo 3 36.65 m Nodo 3 →Nodo 4 36.65 m Nodo 4 →Nodo 5 33.79 m Nodo 5 →Nodo 6 39.21 m Nodo 6 →Nodo 7 25.41 m Nodo 7 →Nodo 8 44.10 m Tabla 3.5: Distancias entre nodos en la topolog´ıa del experimento II Par´ametro Valor Enrutado Est´atico (IP y Mac) Velocidad 11 Mb/s Potencia Se˜nal de Transmisi´on 18 dBm Frecuencia 2.422 e6 (Canal 3) RTS/CTS Apagado Fragmentaci´on Apagado Gesti´on de Energ´ıa Encendido Tabla 3.6: Par´ametros de la red del experimento II Par´ametros Valor Longitud del bufer de Lectura o Escritura 8 KB Puerto del servidor 5001 Tama˜no de ventana TCP 46.72 KB (32*MSS) Tama˜no de segmento maximo TCP (MTU - 40 bytes) 1.460 KB Tabla 3.7: Par´ametros TCP en Iperf Escenarios En este experimento se ha querido hacer un profundo an´alisis centr´andose en conocer el rendimiento de un nodo cuando se comunica con los dem´as y c´omo trabaja la red con diferente n´umero de nodos involucrados en la prueba. Con el escenario 1 (Figura 3.7), se ha querido conocer el rendimiento cuando la 26 Cap´ ıtulo 3: WMN real con Ubuntu comunicaci´on se establece entre dos nodos cercanos (un solo salto). Lo que se hizo fue situar el cliente en el primer nodo y el servidor en el segundo, enviar tr´afico entre ellos y, una vez finalizada la prueba, poner como cliente el segundo nodo y como servidor el tercero, y as´ı sucesivamente hasta el ´ultimo nodo. Figura 3.7: Escenario 1 del experimento II En el escenario 2 (Figura 3.8), se ha probado el rendimiento cuando en el tr´afico de datos se implican tres nodos (dos saltos). Se situ´o el cliente en el primer nodo y el servidor en el tercero. Repitiendo todas las pruebas hasta el ´ultimo nodo obtuvimos seis muestras diferentes. Figura 3.8: Escenario 2 del experimento II La Figura 3.9 muestra el escenario 3, donde el tr´afico de datos fluye desde el primer nodo hasta el cuarto (tres saltos) y as´ı sucesivamente hasta el octavo nodo. Con este escenario se obtuvieron diferentes muestras de la red con las que comparar el comportamiento. Figura 3.9: Escenario 3 del experimento II El escenario 4 (Figura 3.10) prueba el comportamiento de la red cuando en la transmisi´on 3.5. Experimentos de la red WMN 27 de datos act´uan cinco nodos (cuatro saltos), obteniendo cuatro muestras diferentes de cuatro emplazamientos de nodos diferentes. Figura 3.10: Escenario 4 del experimento II Con el escenario 5 (Figura 3.11) se obtiene el comportamiento de la comunicaci´on entre seis nodos (cinco saltos), obteniendo tres muestras diferentes. Figura 3.11: Escenario 5 del experimento II La Figura 3.12 muestra el escenario 6 que obtiene el comportamiento de la red cuando se env´ıa tr´afico a trav´es de siete nodos (seis saltos). Figura 3.12: Escenario 6 del experimento II En el escenario 7 (Figura 3.13) se obtiene el rendimiento de la red completa, es decir 28 Cap´ ıtulo 3: WMN real con Ubuntu cuando se mandan datos desde el primer nodo hasta el ´ultimo (siete saltos). Figura 3.13: Escenario 7 del experimento II En la Tabla 3.8 se muestra el n´umero de repeticiones de cada escenario, el tiempo para cada prueba y el tiempo total te´orico que se esperaba y el tiempo real que nos cost´o realizar todas las pruebas utilizando como protocolo de comunicaci´on TCP. Escenario N´umero de repeticiones Duraci´on (min) 1 42 126 2 36 108 3 30 90 4 24 72 5 18 54 6 12 36 7 6 18 Total(te´orico): 504 min = 8,4 h Total(pr´actico): 7 am - 1.35 am = 18,59h Tabla 3.8: Tiempos y repeticiones experimento II Cuando se realiz´o este experimento, los miembros del grupo de Investigaci´on de Redes ayudaron a obtener los permisos necesarios para poner los ordenadores por los pasillos, a colocar los ordenadores y tambi´en con el desarrollo de un script v´alido para realizar todos las pruebas de todos los escenarios. El script fue desarrollado por la estudiante de doctorado Anna Chaltseva. 3.5.4. Resultados experimento II El throughput ha sido obtenido en t´erminos de carga ´util en la capa de transporte (capa cuatro), utilizando como protocolo de transporte IP/TCP, con un escenario de un solo cliente. Para obtener los resultados de este experimento, se ha utilizado tcpdump para capturar el tr´afico generado en la red. Una vez finalizado cada prueba, tcpdump crea un fichero “.pcap” 3.5. Experimentos de la red WMN 29 que contiene toda la informaci´on de lo sucedido en la red en el periodo en el que se realiz´o la prueba. Utilizando Wireshark se calculo el throughput de cada prueba (las tablas con todos los resultados se pueden ver en el Anexo D de la memoria en ingl´es). Para obtener los resultados se han realizado dos an´alisis, en el primero se ha analizado como se comporta la red cuando intervienen diferente n´umero de nodos y el segundo se trata de analizar el comportamiento global de la red analizando el Throughput total. El primer an´alisis se encuentra detallado en el Anexo B d´onde se pueden ver las gr´aficas con Throughput de todos los escenarios y el segundo an´alisis se encuentra en el siguiente apartado. Throughput total En la Figura 3.15 se puede observar el promedio del throughput para los diferentes saltos. Se puede ver como el throughput entre dos nodos no disminuye de igual manera conforme aumenta el n´umero de saltos. Este comportamiento es natural y puede ser explicado desde diferentes aspectos: No se puede lograr un throughput igual a la velocidad de transmisi´on del canal (en nuestro caso 11 Mbps) debido a que en un canal inal´ambrico la se˜nal enviada desde la fuente al destino se debilita debido a la p´erdida de la propagaci´on multitrayectoria. Por este motivo cuanto mayor n´umero de nodos participan en la comunicaci´on mayor descenso del throughput. Cuando se transmite un paquete TCP, se env´ıa un paquete de reconocimiento (ACK). La suma de los tiempos, el que transcurre entre la recepci´on y el env´ıo del ACK, y el que transcurre cuando un nodo quiere transmitir y tiene que mirar si el medio de transmisi´on est´a libre, hace que el throughput disminuya puesto que en ese tiempo no se transmiten datos. La propagaci´on dentro de edificios, debido a los materiales utilizados en el suelo, techo y paredes, afecta a la fuerza de la se˜nal y hace que el throughput sea directamente proporcional a la fuerza de la se˜nal recibida (RSS) [21]. Se han llevado a cabo los experimentos utilizando la banda ISM 2.4GHz, utilizando el canal 3. Como se puede ver en la Figura 3.14 es un canal en el que se superponen interferencias de otros canales debilitando la fuerza de la se˜nal recibida (RSS). Figura 3.14: Canales de transmisi´on inal´ambricos 36 Cap´ ıtulo 4: WMN en el simulador NS-3 Log Distance Propagation Loss Model Este modelo calcula la intensidad de se˜nal recibida por cada antena utilizando el modelo log-distance. Para calcular la intensidad de la se˜nal se utiliza la siguiente ecuaci´on: L=L0+ 10 ·n·log10 d d0 Donde: L0:Distancia de referencia (m) n:Exponente de p´erdida en la trayectoria d:Distancia entre las antenas (m) d0:Distancia de referencia de la antena (m) L:P´erdida en la trayectoria (dB) Para utilizar este modelo es necesario estimar o calcular los valores de las variables y adaptarlo al banco de pruebas real. Three Log Distance Propagation Loss Model Este modelo es similar al modelo Log Distance Propagation Loss, pero este modelo utiliza tres campos para la distancia en lugar de uno. En el caso del banco de pruebas real solo es necesario un campo para la distancia, por este motivo se decidio que es mejor utilizar el modelo Log Distance Propagation Loss Model. Modelo de p´ erdidas en la propagaci´ on utilizado Para la adaptaci´on de un modelo de p´erdidas en la propagaci´on con los modelos disponibles en NS-3, se ha utilizado una combinaci´on de tres de ellos para implementar todas las interferencias de la realidad: Log Distance Propagation Loss Model,Friis Propagation Loss Model, and Random Propagation Loss Model. Se ha utilizado el modelo Friis Propagation Loss conociendo que este modelo solo es v´alido para una m´ınima separaci´on entre las antenas, donde la distancia m´ınima viene indicada por la distancia de Rayleigh: RayleighDistance =2·L2 a·f c Donde: La:Tama˜no de la antena (en nuestro caso 1) f : Frecuencia del canal de transmisi´on 4.2. Implementaci´ on del banco de pruebas en NS-3 37 c : Velocidad de la luz (3 ·108m/s). En nuestro caso, la distancia Rayleigh es: RayleighDistance = 16,14ˆ 6 El significado de esta distancia es que la antena que transmite y la antena que reciben, para poder aplicar este modelo, tienen que estar separadas a una distancia de, como m´ınimo, la distancia de Rayleigh. Como se puede ver en la Tabla 3.7 todas las distancias lo cumplen por lo que se puede calcular L0: L0= 20 ·log10 4·π·d0·f c Donde: d0:Distancia de referencia (1m en nuestro caso) f:Canal de transmisi´on (En nuestro caso, Canal 3 = 2,422 ·109Hz) c:Velocidad de la luz (3 ·108m/s). El c´alculo de L0es: L0= 40,125 Una vez calculado el valor de L0, es necesario calcular el valor de npara poder aplicar el modelo Log Distance Propagation Loss. Para estimar el valor de n, se conoce que el experimento del banco de pruebas real fue realizado en el interior de un edificio, por lo que bas´andose en mediciones experimentales realizadas para una red inal´ambrica en el interior de una oficina (recogidas en un art´ıculo de investigaci´on [22]), concluyen textualmente “El estudio de un canal de interior requiere N=18 para una p´erdida de intensidad en la trayectoria entre el transmisor y el receptor (exponente de p´erdida en la trayectoria igual a 1.8)”. El modelo Random Propagation Loss se a˜nadio para ajustar la intensidad de recepci´on (RSS) con los valores obtenidos en el banco de pruebas real durante el experimento. Los valores obtenidos en el experimento oscilan entre -67 and -83 dBm, por este motivo se a˜nadio este modelo que configurar´a los valores de intensidad de recepci´on a un valor aleatorio dentro de este rango utilizando para configurar este modelo el rango (L0+27, L0+43). Tambi´en se a˜nadido el modelo propagation delay para ajustar las interferencias producidas por el aire, configur´andolo de acuerdo a la velocidad de la luz (3 ·108m/s). 4.2.3. Implementaci´ on En esta secci´on se describe c´omo se ha desarrollado el programa para simular el banco de pruebas real, describiendo que clases se han utilizado y que problemas se han encontrado. En el Anexo C de la memoria en ingl´es se encuentra el c´odigo del programa, como ejecutarlo y se describe la clase desarrollada para la simulaci´on (MeshTest) y todos los atributos y m´etodos que tiene. 38 Cap´ ıtulo 4: WMN en el simulador NS-3 Problemas con el uso del protocolo 802.11s Cuando se configur´o el protocolo utilizado en la simulaci´on se empez´o utilizando la implementaci´on del IEEE 802.11s existente en NS-3 [23] utilizando la clase MeshHelper para instalarlo. Durante las primeras pruebas que se realizaron, se envi´o tr´afico desde un nodo a otro utilizando el protocolo de transporte TCP. Una vez comprobado que funcionaba correctamente, se a˜nadi´o el modelo de p´erdidas en la propagaci´on descrito anteriormente. Cuando se realizaron las mismas pruebas de env´ıo de tr´afico entre dos nodos, se comprobo que no funcionaba y que no se mandaban ning´un paquete entre los nodos. Para comprobar si el problema era que la implementaci´on de 802.11s era la que no funcionaba correctamente con el modelo de p´erdidas de propagaci´on cambiamos de protocolo a 802.11b, comprobando que con el modelo de p´erdidas de propagaci´on funcionaba correctamente. Una vez verificado que funcionaba, concluimos que exist´ıa alg´un problema en la implementaci´on del est´andar 802.11s. Se intent´o solucionar el problema mandando varios correos electr´onicos a los desarrolladores de NS-3 explic´andoles el problema y envi´andoles los ficheros de tr´afico generados, pero no recibimos ninguna respuesta. Al no recibir respuesta alguna decidimos continuar nuestra simulaci´on utilizando la implementaci´on disponible del protocolo IEEE 802.11s. Esta decisi´on se tomo conociendo que con el uso de este protocolo pod´ıamos implementar todos los par´ametros del experimento realizado en el banco de pruebas. Nodos En la simulaci´on se comenz´o creando nodos utilizando la clase nodeContainer y se cre´o un objeto con 8 nodos. Para configurar los par´ametros de la tarjeta de red inal´ambrica se utiliz´o un objeto de la clase NetDeviceContainer y para configurar la interface de cada nodo se utiliz´o un objeto de la clase Ipv4InterfaceContainer puesto que se utiliza el protocolo de Internet versi´on 4. Una vez configurados todos los par´ametros de cada objeto, se establecio la posici´on de todos los nodos con la clase MobilityHelper y se instalaron los dispositivos y las interfaces en todos los nodos. Dispositivos En los dispositivos se ha configurado la capa de Control de Acceso Medio (MAC) utilizando la clase NqosWifiMacHelper y estableciendo como protocolo de enrutado ad hoc. Se ha utilizado la clase YansWifiChannelHelper para configurar el modelo de p´erdidas en la propagaci´on descrito anteriormente y para ajustar algunos par´ametros f´ısicos como Umbral de detecci´on de energ´ıa, la ganancia de la transmisi´on, la energ´ıa de transmisi´on, el canal de transmisi´on, etc. se ha utilizado la clase YansWifiPhyHelper. 4.3. Experimentos en NS-3 39 Interfaces Se ha utilizado la clase InternetStackHelper para instalar la pila de Internet y para asignar direcciones IP a cada interface hemos utilizado Ipv4AddressHelper. Para configurar el enrutamiento est´atico se ha utilizado Ipv4StaticRoutingHelper. Aplicaciones Para instalar las aplicaciones en los nodos se ha utilizado ApplicationContainer y para enviar tr´afico entre los nodos PacketSinkHelper instalando un generador de tr´afico en el cliente con la clase TcpSocketFactory. Ejecuciones aleatorias Para poder realizar simulaciones diferentes, se ha utilizado la clase seedManager para generar valores aleatorios cambiando la semilla1de generaci´on, introduci´endola como par´ametro en el programa. 4.3. Experimentos en NS-3 Una vez desarrollado el programa, se quiso realizar exactamente el mismo experimento descrito en la secci´on 3.5.3. Los valores te´oricos esperados no cambiaron, pero los tiempos reales de simulaci´on s´ı (ver Tabla 4.1). Para llevar a cabo este experimento han sido desarrollados siete scripts que permiten probar todos los escenarios (ver Anexo C de la memoria en ingl´es), realizando seis pruebas de cada escenario y cambiando en cada prueba la semilla para obtener diferentes simulaciones. Escenario N´umero de repeticiones Duraci´on (min) 1 42 84 2 36 72 3 30 60 4 24 48 5 18 36 6 12 24 7 6 12 Total (te´orico): 336 min = 5,6 h Total (pr´actico): 13385 s = 3,7h Tabla 4.1: Tiempos y repeticiones para la simulaci´on 1La semilla controla la aleatoriedad de las simulaciones, si la misma semilla aleatoria es usada en la misma situaci´on, el simulador produce exactamente los mismos resultados. Una semilla aleatoria distinta produce resultados diferentes. 40 Cap´ ıtulo 4: WMN en el simulador NS-3 4.4. Resultados de la simulaci´ on en NS-3 Los resultados de la simulaci´on fueron obtenidos despu´es de la ejecuci´on de cada programa, gracias a la generaci´on de archivos “.pcap” que conten´ıan la traza entera de cada ejecuci´on. Centramos nuestro inter´es en analizar el nodo cliente obteniendo el throughput utilizando el programa Wireshark, es decir, de la misma forma que fue obtenido en el experimento II realizado en el banco de pruebas real. Todos los valores de throughput obtenidos en este experimento se encuentran en el Anexo D de la memoria en ingl´es. Para obtener los resultados se han realizado dos an´alisis, al igual que en el banco de pruebas, en el primero se ha analizado como se comporta la red cuando intervienen diferente n´umero de nodos y el segundo se trata de analizar el comportamiento global de la red analizando el Throughput total. El primer an´alisis se encuentra detallado en el Anexo D y el segundo an´alisis se encuentra en el siguiente subapartado. Throughput total Figura 4.3: Throughput total de la simulaci´on en NS-3 Se puede ver en la Figura 4.3 como decrece linealmente el throughput con el aumento del n´umero de saltos. Tambi´en se observa que con dos saltos la disminuci´on del throughput es menor que en cualquier otro caso debido a que las distancias eran muy similares. Con estos 4.4. Resultados de la simulaci´ on en NS-3 41 resultados se puede concluir que el throughput decrece proporcionalmente con la distancia. Si se presta atenci´on al intervalo de confianza (Figura 4.4) se puede observar que para un salto es mucho mayor que para el resto debido a que las distancias entre dos nodos son muy diferentes a la suma de distancias de varios nodos. Atendiendo a los valores m´aximos y m´ınimos tambi´en se puede observar esta diferencia. Figura 4.4: Throughput total vs. Intervalo de confianza 90 % vs. M´aximo&M´ınimo de la simulaci´on en NS-3 CAP´ ITULO 5 Comparativa de resultados En este cap´ıtulo se analizan los resultados obtenidos en los experimentos realizados tanto en banco de pruebas real como en el simulador NS-3. La comparaci´on entre ambos se realiza desde dos perspectivas diferentes, primero se compara el throughput calculado en los experimentos y posteriormente se comparan tres muestras de ficheros “.pcap” generados en los experimentos. 5.1. Throughput En los cap´ıtulos anteriores se ha analizado el throughput obtenido en el banco de pruebas y el obtenido en el simulador NS-3. Ahora es momento de comparar ambos. En la Figura 5.1 se ve que en ambos casos, cuando hay un salto, el throughput coincide, pero que conforme se incrementa el n´umero de saltos, el throughput decrece de diferente manera. Si se observa el throughput del banco de pruebas real, es como si hubiera diferentes etapas entre saltos, una entre uno y tres, otra entre tres y cinco y la ´ultima entre cinco y siete. Si se comparan estas etapas con el comportamiento en la simulaci´on de NS-3 se puede decir que esta ´ultima decrece lenta pero constantemente mientras que en el banco de pruebas real decrece de manera diferente dependiendo del n´umero de saltos. Este comportamiento es debido a que las condiciones del entorno del banco de pruebas var´ıan constantemente y por tanto las interferencias producidas sobre la transmisi´on de la red son diferentes, mientras que las interferencias modeladas en el simulador son similares durante todo el experimento. De acuerdo a la diferencia entre m´aximos y m´ınimos mostrada en la Figura 5.2, solo cuando hay un salto, el intervalo es mayor en la simulaci´on, debido a que las interferencias producidas en el banco de pruebas hacen que el rango sea mayor. Si se presta atenci´on al intervalo de confianza, se ve que existe una mayor variaci´on en los valores en el banco de pruebas. 43 44 Cap´ ıtulo 5: Comparativa de resultados Figura 5.1: Comparaci´on del Throughput entre el banco de pruebas y el simulador NS-3 Figura 5.2: Throughput del banco de pruebas vs. NS-3 vs. Intervalo de confianza 90 % vs. M´aximo&M´ınimo Analizando todos estos resultados y si se tiene en cuenta que la curva ascendente final en el banco de pruebas fue debido al problema enunciado en el cap´ıtulo tres, se puede confirmar que ambas redes tienen un comportamiento similar, pero que las interferencias producidas en el banco de pruebas son m´as variadas y producen cambios constantes en la transmisi´on. 5.2. An´ alisis de muestras de ficheros “.pcap” 45 5.2. An´ alisis de muestras de ficheros “.pcap” Cuando se analizan los resultados del banco de pruebas se encuentran grandes diferencias de throughput entre dos nodos diferentes con el mismo n´umero de nodos entre ellos (mismo n´umero de saltos). Como consecuencia de este comportamiento decidimos comparar dos ficheros “.pcap” obtenidos en el experimento II del banco de pruebas con uno obtenido durante la simulaci´on (s´olo uno puesto que el throughput era similar, no exist´ıan grandes diferencias) cuando se manda tr´afico con dos saltos. Concretamente se escogieron (ver Figuras 3.15 y4.3): Ejemplo del banco de pruebas 1→3: Porque era el que m´as bajo throughput, por lo tanto, donde m´as interferencias hubo. Ejemplo del banco de pruebas 3→5: Porque ten´ıa el throughput m´as alto. Ejemplo de simulaci´on en NS-31→3: Porque ten´ıa el throughput m´as bajo. La Figura 5.3, que muestra las mediciones de Round Trip Time1de las tres muestras descritas anteriormente, ilustra como TCP reajusta el RTT para la conexi´on. Se puede ver como el RTT en la muestra de la simulaci´on se ajusta a valores muy altos en momentos espec´ıficos, pero el n´umero de retransmisiones no es muy alto, mientras que en el banco de pruebas (especialmente 1→3) observamos como el n´umero de retransmisiones es muy alto y como el RTT cambia continuamente debido a las retrasmisiones de diferentes segmentos de datos. Este comportamiento es debido al algoritmo que tiene TCP para adaptar la retransmisi´on [24] registra el tiempo en que cada segmento se env´ıa y el momento que llega el acuse de recibo (ACK) de cada segmento. Cuando TCP obtiene una nueva muestra de RTT, TCP ajusta el RTT para la conexi´on. En la Figura 5.4 vemos como en la simulaci´on y en el banco de pruebas 3→5 el comportamiento es normal por que el n´umero de secuencia aumenta linealmente con el tiempo, pero s´ı miramos la muestra del banco de pruebas 1→3 se ve como existe un gran retraso y se retrasmite 3 veces un paquete. Se muestra como el “time out” aumenta el doble cada vez (como se puede ver hay tres puntos negros, entre el 10 y el 11,5 aproximadamente, que muestran la retransmisi´on del paquete). Si se presta atenci´on a la burbuja dentro del gr´afico de la muestra del banco de pruebas 3→5, vemos que hay dos l´ıneas cuando se manda un paquete. La l´ınea superior es el tama˜no de ventana de TCP y la l´ınea inferior significa el segmento transmitido. Podemos ver tambi´en como cuando se env´ıa tr´afico en 3→5 la diferencia entre ambas l´ıneas es suficientemente grande, lo que significa que el tama˜no de ventana est´a funcionando correctamente y no hay congesti´on de tr´afico. Sin embargo, si miramos en 1→3 observamos como la diferencia entre las l´ıneas se reduce debido a la congesti´on provocada por las interferencias, que hacen que TCP reduzca el tama˜no de ventana exponencialmente para evitar problemas de transmisi´on. Cuando el tr´afico vuelve a fluir, TCP comienza lentamente (se puede ver en la burbuja dentro 1RTT, Tiempo que tarda un paquete enviado en ir desde el emisor al destino y volver. 52 pudiendo controlar las variables del entorno lo mejor posible. El paquete Open80211s debe de ser actualizado con la ´ultima versi´on debido a que ellos est´an mejorando continuamente el sistema y a˜nadiendo nuevas mejoras muy interesantes y dignas de ser probadas. Otras interesantes propuestas a llevar a cabo son: Desarrollar un sistema que permita controlar la red entera desde un solo ordenador. Configurar los ordenadores con conexi´on autom´atica a la WMN cada vez que un usuario los conecta. Conectar la WMN a Internet debido a que es muy ´util para mantener actualizado el sistema constantemente. A˜nadir m´as antenas por nodo para poder crear diferentes WMN funcionando en un mismo entorno. Mejorar el actual manual de usuario del banco de pruebas, a˜nadiendo las nuevas mejoras a˜nadidas. 6.3.2. NS-3 NS-3 es una muy ´util herramienta para simular redes de comunicaci´on como se ha comprobado en este proyecto, pero no s´olo sirve para eso. Con NS-3 es posible crear una gran red combinaci´on de redes reales y simuladas creando as´ı un gran banco de pruebas en el que realizar experimentos muy ´utiles para probar grandes cargas de trabajo. En nuestro caso tambi´en es una buena idea utilizar NS-3 como generador de tr´afico, para as´ı utilizar el mismo tr´afico en el mundo real como en la simulaci´on y as´ı analizar el comportamiento de ambas redes con el mismo flujo de datos. Otra importante mejora para futuras simulaciones es desarrollar en NS-3 un nuevo modelo de p´erdidas en la propagaci´on de acuerdo con las diferentes condiciones del entorno, especialmente, teniendo en cuenta la intensidad de la se˜nal recibida por cada antena. Finalmente, para nuevas simulaciones, es importante utilizar el m´odulo de IEEE 802.11s y trabajar en coordinaci´on con los desarrolladores de NS-3 para mejorar y hacer posible su correcta simulaci´on (ver meshNet.cc en el Anexo C de la memoria en ingl´es para realizar mejoras y experimentos con este m´odulo). Tambi´en es importante a ayudar a los desarrolladores con la documentaci´on de NS-3 a˜nadiendo nuevos comentarios y ejemplos que ayuden a nuevos usuarios a entender y facilitar el uso del simulador. Bibliograf´ıa [1] “Open80211s.” http://o11s.org/.´ Ultimo Acceso: 14-10-2009. [2] “IEEE Standard for Information technology, telecommunications and information exchange between systems local and metropolitan area networks specific requirements.” http://standards.ieee.org/getieee802/download/802.11-2007.pdf.´ Ultimo Acceso: 15-02-2010. [3] Lee, M.J.; JianLiang Zheng; Young-Bae Ko; Shrestha, D.M., Emerging starndars for wireless mesh technology. Wireless Communications. Page(s): 56-63: IEEE.Volume 13, Issue 2, April 2006. [4] “IEEE - the world’s leading professional association for the advancement of technology.” http://www.ieee.org/portal/site.´ Ultimo Acceso: 10-12-2009. [5] “Ubuntu Home Page — Ubuntu.” http://www.ubuntu.com/.´ Ultimo Acceso: 14-10- 2009. [6] “About the IITP RAS.” http://www.iitp.ru/en/about.´ Ultimo Acceso: 22-03-2010. [7] “The NS-3 Network Simulator.” http://www.nsnam.org/index.html.´ Ultimo Acceso: 04-03-2010. [8] “Wireshark Go deep.” http://www.wireshark.org/.´ Ultimo Acceso: 14-10-2009. [9] “Ipef, Download Iperf software.” http://www.noc.ucf.edu/Tools/Iperf/.´ Ultimo Acceso: 24-08-2010. [10] “zd1211rw - Linux Wireless.” http://linuxwireless.org/en/users/Drivers/ zd1211rw.´ Ultimo Acceso: 14-10-2009. [11] “open80211s - Trac.” http://o11s.org/trac#DriverStatus.´ Ultimo Acceso: 14-10- 2009. [12] “ath9k - Linux Wireless.” http://linuxwireless.org/en/users/Drivers/ath9k. ´ Ultimo Acceso: 14-10-2009. [13] “Drivers - Linux Wireless.” http://linuxwireless.org/en/users/Drivers.´ Ultimo Acceso: 14-10-2009. 53 54 [14] “p54 - Linux Wireless.” http://linuxwireless.org/en/users/Drivers/p54.´ Ultimo Acceso: 14-10-2009. [15] “D-Link High Speed 2.4GHz (801.11g) Wireless USB Adapter.” http://www.dlink. com/products/?pid=334.´ Ultimo Acceso: 14-10-2009. [16] “IEEE P802.11 TGs.” http://grouper.ieee.org/groups/802/11/Reports/tgs_ update.htm.´ Ultimo Acceso: 29-12-2009. [17] “mac80211 - Linux Wireless.” http:// linuxwireless.org/en/developers/Documentation/mac80211.´ Ultimo Acceso: 29- 12-2009. [18] “Download - Linux Wireless.” http://wireless.kernel.org/en/users/Download# Archiveofcompat-wireless-2.6tarballs.´ Ultimo Acceso: 19-01-2010. [19] “git.kernel.org - linux/kernel/git/Linville/wireless-testing.git/summary.” http://git. kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=summary;. ´ Ultimo Acceso: 19-01-2010. [20] “HOWTO - open80211s - Trac.” http://o11s.org/trac/wiki/HOWTO.´ Ultimo Acceso: 10-02-2010. [21] “802.11g (2.4GHz) Wireless USB 2.0 Adapter DWL-G122 D-Link AirPlus G TM Manual.” https://www.cz.o2.com/public_conver/6a/55/cc/113539_142058_ dwlg122_manual.pdf.´ Ultimo Acceso: 15-03-2010. [22] Theofilos Chrysikos, Giannis Georgopoulos, Stavros Kotsopoulos Wireless Telecommunications Laboratory −Department of Electrical & Computer Engineering −University of Patras, “Site-Specific Validation of ITU Indoor Path Loss Model at 2.4 GHz,” [23] “NS-3: IEEE 802.11s draf.” http://www.nsnam.org/doxygen-release/group__dot11s.html.´ Ultimo Acceso: 16- 03-2010. [24] Douglas E. Comer, Internetworking With TCP/IP VolI: Principles, Protocols and Architecture. Page(s): 208-227: Third Edition. ANEXOS 55 ANEXO A Redes WMN En este anexo se profundiza un poco m´as en la Tecnolog´ıa Inal´ambrica Mesh. Se presenta la arquitectura de la red, las caracter´ısticas y por ´ultimo los escenarios de aplicaci´on, es decir, donde se pueden aplicar este tipo de redes y por qu´e resultan m´as ´utiles que otras. A.1. Arquitectura de la red Una WMN tiene dos tipos de nodos: routers mesh y clientes mesh. Los routers mesh aparte de las funciones convencionales de un router (actuar como puerta de enlace y repetidor) ofrece soporte para el funcionamiento de la red mesh. Para mejorar la flexibilidad de la red mesh, un router mesh est´a equipado con m´ultiples interfaces con las mismas o diferentes tecnolog´ıas inal´ambricas para el acceso a la red. Comparado con los routers tradicionales, un router mesh puede abarcar la misma cobertura con un gasto de energ´ıa para transmitir mucho menor debido a la comunicaci´on multisalto. Opcionalmente, el protocolo de control de acceso al medio en un router mesh puede ser mejorado con la escalabilidad que ofrece un entorno mesh multisalto. A pesar de todas estas diferencias, los routers convencionales y los mesh est´an basados en una estructura hardware similar. Los routers mesh pueden ser construidos tanto en sistemas dedicados como en sistemas de prop´osito general (PCs, port´atiles,...). Los clientes mesh tienen las funciones necesarias para funcionar en red mesh pudiendo funcionar tambi´en como router mesh sin la funciones de puente y puerta de enlace. Los clientes mesh solo tienen una interface inal´ambrica lo que hace que el hardware necesario sea mucho m´as simple que el de los routers mesh, por lo que los dispositivos que pueden desempe˜nar la funci´on de cliente mesh son mucho m´as variados que los que pueden ser router mesh. La arquitectura de una WMN puede ser clasificada en tres grandes grupos basados en la funcionalidad de los nodos: 57 58 Appendix A 1. Infraestructura “Columna Vertebral” 1:La infraestructura columna vertebral es una de las WMN m´as utilizadas, su arquitectura de la red la podemos ver en la figura A.1. Este tipo de WMN incluye routers mesh que forman la infraestructura necesaria para conectar a los clientes. La infraestructura de la Red Inal´ambrica Mesh puede ser construida con la tecnolog´ıa IEEE 802.11 y utilizando otros tipos de radio tecnolog´ıa. Los routers mesh forman una malla que se autoconfigura y automantiene a s´ı misma. Los routers pueden conectarse a internet con la funci´on puerta de enlace. Esta aproximaci´on provee una estructura para clientes convencionales y permite la integraci´on de diferentes WMN y las redes inal´ambricas existentes a trav´es de las funciones puerta de enlace y puente de los routers mesh. Los clientes convencionales que disponen de Ethernet pueden conectarse a routers mesh a trav´es de enlaces Ethernet, los que disponen de la misma radio tecnolog´ıa que los routers mesh se pueden comunicar directamente con ellos, mientras que los que disponen de otra radio tecnolog´ıa tienen que comunicarse con las estaciones base que disponen de conexi´on Ethernet con los routers mesh. 2. Cliente WMN 2:Esta arquitectura de red proporciona redes punto a punto a trav´es de los dispositivos de cada cliente. La estructura b´asica de este tipo de redes se muestra en la Figura A.2 La caracter´ıstica principal de esta arquitectura es que los nodos clientes constituyen la red entera (no son necesarios los routers mesh) y son los encargados del enrutamiento de los datos, la configuraci´on de la red y proporcionan las aplicaciones necesarias al usuario final. Cada nodo cliente utiliza un solo dispositivo para la transmisi´on/recepci´on de datos. Para la transmisi´on de un paquete de datos destinado a un nodo en la red, los datos pasan por los diferentes nodos hasta que llega a su destino. Esto es posible gracias a que los nodos clientes tienen las funciones de enrutado y autoconfiguraci´on de la red. 3. WMN H´ıbrida: Esta arquitectura es una combinaci´on de las dos arquitecturas anteriores como se puede ver en la Figura A.3. Los clientes mesh pueden acceder a la red a trav´es de los routers mesh o a trav´es de otros clientes mesh. Mientras la infraestructura proporciona conectividad a otras redes como Internet, Wi-Fi, WiMAX, etc., mejora la cobertura dentro de la WMN. La arquitectura h´ıbrida es la m´as aplicable puesto que dispone de los beneficios de las arquitecturas anteriores. 1Tambi´en llamada infrastructure meshing. 2Tambi´en llamada client meshing. A.2. Caracter´ ısticas 59 Figura A.1: Infraestructura Columna Vertebral Figura A.2: Cliente WMN A.2. Caracter´ısticas Las caracter´ısticas de una WMN son las siguientes: Red Inal´ambrica Multisalto: Uno de los prop´ositos marcados al desarrollar una WMN es ampliar la cobertura de las redes inal´ambricas actuales sin sacrificar la capacidad del canal de transmisi´on. Otro gran objetivo es proporcionar conectividad NLOS (fuera de la l´ınea de visi´on) a trav´es de usuarios sin LOS (l´ınea de visi´on directa). Para alcanzar estos objetivos es indispensable utilizar el estilo multisalto mesh que hace posible un mejor throughput sin sacrificar el radio de alcance efectivo. Utilizando peque˜nas distancias entre los enlaces se producen menos interferencias entre los nodos 60 Appendix A Figura A.3: WMN H´ıbrida y se realiza un uso eficiente de la frecuencia. Soporte para redes ad hoc y capacidad para autoconfigurarse, autorganizarse y automantenerse: La tecnolog´ıa ad hoc mejora el rendimiento de la red permitiendo crear una arquitectura de red m´as flexible, con una configuraci´on y despliegue sencillo, mejorar la tolerancia a fallos y permite la conectividad en malla (mesh). Gracias a estas caracter´ısticas, las WMN necesitan de una inversi´on baja y la red puede crecer gradualmente seg´un sea necesario. Dependencia de la movilidad de los nodos mesh: Los routers mesh tienen una movilidad muy peque˜na, mientras los clients mesh pueden ser est´aticos o m´oviles, en consecuencia, la movilidad en una WMN var´ıa de un nodo a otro, lo que la diferencia de una red ad hoc. Diferentes tipos de acceso a la red: Se permite el acceso a Internet a trav´es de backhaul (red de retorno) y comunicaciones punto a punto (P2P). La integraci´on de redes WMN con otras redes inal´ambricas y otros servicios se puede lograr a con el uso de redes WMN. Dependencia del consumo de energ´ıa que limita la malla de nodos: Los routers mesh habitualmente no tienen ninguna restricci´on que limite el consumo de energ´ıa, sin A.2. Caracter´ ısticas 61 embargo los clientes mesh necesitan protocolos que controlen eficazmente el consumo de energ´ıa. Basadas en sus caracter´ısticas, las WMN son generalmente consideradas como un tipo de red ad hoc debido a la falta de una infraestructura cableada, con estaciones base y puntos de acceso, que existe en redes de comunicaciones o en redes Wi-Fi. Las t´ecnicas utilizadas en redes ad hoc son utilizadas tambi´en en redes WMN, pero estas ´ultimas necesitan adem´as algoritmos adicionales mucho m´as sofisticados y nuevos principios para el dise˜no, por lo que podemos considerar que las redes ad hoc son una subtipo de red WMN. Para ilustrar esta conclusi´on, realizamos la siguiente comparaci´on entre redes ad hoc y WMN, utilizando como referencia la arquitectura h´ıbrida que es la que ofrece todas las ventajas de una red WMN: Infraestructura inal´ambrica “Columna Vertebral”: Esta estructura ofrece a una WMN, (gracias a la malla formada por los routers mesh) una gran conectividad y robustez, mientras que en las redes ad hoc la conectividad no es muy fiable puesto que depende de contribuciones de cada usuario final. Integraci´on: WMN permite la integraci´on de clientes convencionales que utilicen la misma frecuencia de radio que los routers mesh consiguiendo proveer de todos los servicios disponibles en todas las redes integradas a los usuarios. Configuraci´on y enrutado: En redes ad hoc los encargados de realizar las funciones de enrutado y configuraci´on son los dispositivos del usuario final. Por este motivo, en redes ad hoc los usuarios sufren restricciones de energ´ıa que limitan sus recursos y hacen que aumente el coste de los dispositivos, mientras que en redes WMN esto no sucede debido a que son los routers mesh los encargados de realizar estas funciones. M´ultiples frecuencias de radio: Routers mesh pueden funcionar con diferentes frecuencias de radio que permiten la separaci´on de los principales tipos de tr´afico. Esta cualidad permite separar el tr´afico entre routers mesh para la configuraci´on y enrutado de la red y el tr´afico necesario para permitir el acceso a la red, lo que mejora la capacidad de la red. En ad hoc, el tr´afico necesario se genera en un solo canal, lo que compromete el rendimiento de la red. Movilidad: En redes ad hoc la topolog´ıa y la conectividad de la red depende de los usuarios finales lo que compromete claramente el rendimiento de la red. Mientras que en redes WMN, los routers mesh son los encargados de proporcionar la estructura de la red, ofreciendo una cobertura mayor puesto que con la arquitectura mesh es m´as f´acil dotar de conexi´on a los usuarios sin reducir el rendimiento. Compatibilidad: Las redes WMN tienen muchas diferencias si las comparamos con las redes ad hoc pero, como hemos dicho anteriormente, las redes ad hoc las podemos considerar como un subgrupo dentro de las WMN debido a que las t´ecnicas desarrolladas para las redes ad hoc est´an aplicadas tambi´en para las WMN. 68 Appendix B pruebas, con el programa Network Stumbler se detect´o que otros usuarios se encontraban utilizando el mismo canal de transmisi´on (canal 3), lo que produc´ıa interferencias en transmisi´on ocasionando un descenso del rendimiento. Figura B.5: Promedio del throughput del banco de pruebas para 5 saltos Cuando se comenz´o con las pruebas del escenario seis (Figura B.6), continuaron los problemas con la transmisi´on de otro usuario en el mismo canal, pero finalmente se consigui´o dar con ´el y se le solicit´o que dejara de transmitir durante el tiempo que se estuvieran realizando las pruebas y el accedi´o. Por este motivo se ve como el throughput se estabiliz´o en las ´ultimas pruebas de este escenario y en siguiente (Figura B.7). 69 Figura B.6: Promedio del throughput del banco de pruebas para 6 saltos Figura B.7: Promedio del throughput del banco de pruebas para 7 saltos En todas las figuras mostradas anteriormente se puede observar que las interferencias son acordes a las caracter´ısticas de la red y a las personas que andaban por el edificio. ANEXO C Simulador NS-3 En este anexo se describe el alcance del simulador NS-3, los mecanismos y protocolos disponibles en ´el, los principales casos de uso y los objetos m´as utilizados. C.1. Alcance de NS-3 NS-3 esta principalmente dirigido a la simulaci´on de redes basadas en IPv4 y IPv6, aunque tambi´en soporta otras arquictecturas como redes de sensors o DTNs. NS-3 puede ser modificado y ampliado por los usuarios. Los usuarios tienen a su disposici´on programas de ejemplo que permiten iniciarse en el simulador para que una vez lo conozcan escriban nuevos programas, modifiquen los existentes o creen nuevos modelos que ayuden a ampliar las funcionalidades del simulador. C.2. Mecanismos y protocolos soportados NS-3 posee una implementaci´on modular que contiene diferentes librer´ıas que dan soporte al simulador (tambi´en es posible que los usuarios desarrollen sus propias librer´ıas): Core library: Ofrece soporte para aspectos gen´ericos del simulador como generaci´on de n´umeros aleatorios, utilizar punteros inteligentes, callbacks o objetos de depuraci´on. Simulator library: Define los par´ametros de simulaci´on como el tiempo de simulaci´on, objetos, planificadores y eventos. Common library: Define objetos independientes como paquetes gen´ericos. Node library: Define las clases abstractas de objetos fundamentales del simulador como nodos, canales y dispositivos de la red. Internet-node: Define los modelos relacionados con Internet, por ejemplo los protocolos TCP y UDP. 71 72 Appendix C La implementaci´on modular permite la compilaci´on de peque˜nas partes y a la hora de compilar solo se compila la parte del programa que ha cambiado. Los programas de ejecuci´on de NS-3 pueden ser construidos est´atica o din´amicamente vinculados a las librer´ıas. NS-3 ofrece soporte para: Construcci´on de redes virtuales (nodos, canales, aplicaciones) y ofrece soporte para planificadores de eventos, generadores de topolog´ıas, temporizadores, variables aleatorias y otro tipo de objetos para la simulaci´on de sistemas de eventos discretos basados en Internet y en otros tipos de redes. Simular procesos que emiten y consumen paquetes de red reales. Simular m´ultiples procesos en diferentes m´aquinas. Animar las redes simuladas. Detecci´on, registro, c´alculo y estad´ısticas de la simulaci´on. C.3. Casos de uso Para utilizar NS-3 es necesario conocer como est´a dise˜nado. Para ello, en esta secci´on se describen los modelos de uso y las tendencias a la hora de simular de la comunidad de investigaci´on de redes. Ampliaci´on del simulador Los usuarios est´an interesados en ampliar el simulador escribiendo o modificando los programas de simulaci´on. Para hacerlo posible, NS-3 utiliza el dise˜no orientado a objetos con clases polim´orficas que permiten a los usuarios modificar los aspectos que necesiten. Para facilitar la anexi´on de nuevos modelos, NS-3 una arquitectura basada en componentes que permite la adicci´on de los nuevos modelos en tiempo de compilaci´on o de ejecuci´on sin necesidad de modificar los modelos base de NS-3. Configuraci´on NS-3 permite a los usuarios redefinir valores y tipos de clases sin tener que recompilar el simulador entero. La base de datos tienen integrados valores por defecto que pueden ser modificados utilizando la l´ınea de comandos. Seguimiento NS-3 cuenta con un sistema de devoluci´on de llamada basado en el seguimiento de la diferencia entre la fuente y el destino. Las trazas de los paquetes est´an disponibles en el formato “pcap” y pueden ser analizadas utilizando analizadores de protocolos de red como C.3. Casos de uso 73 por ejemplo Wireshark oTcpdump. Escalabilidad Est´a planeado que NS-3 incluya t´ecnicas para mejorar la escalabilidad de las redes en las simulaciones, incluyendo t´ecnicas de simulaci´on distribuida con PDNS y GTNetS y aumentando la flexibilidad de la estructura de las trazas de la red (evitando largas trazas). Integraci´on del software NS-3 est´a orientado a reusar software existente, por ejemplo el uso de programas y otras aplicaciones utilizadas en el simulador NS-2. Por ello el dise˜no de NS-3 se realizo basado en t´ecnicas de encapsulamiento separando la aplicaci´on de la implementaci´on. El dise˜no de NS-3 facilita la interacci´on entre la simulaci´on y los experimentos permitiendo la simulaci´on conjunta de c´odigo simulado y aplicaciones reales, mejorando as´ı las implementaciones del mundo real. La interface del usuario en NS-3 se realiza en C++ con el programa ´´main”. Sin embargo, los usuarios pueden disponer de herramientas para implementar programas y otras componentes utilizando Python. Objetos clave para la simulaci´on En este apartado trataremos los objetos primarios para realizar una simulaci´on basada en enviar y recibir paquetes entre nodos en el simulador. En la Figura C.1 [7] se puede observar gr´aficamente la relaci´on entre los objetos. Node La clase Node es la principal clase base de NS-3, pero tambi´en puede ser instanciada (no es una clase abstracta), los usuarios pueden crear sus propias subclases Node con las caracter´ısticas que requieran. El dise˜no de esta clase utiliza patrones de software para permitir la encapsulaci´on de Applications yNetDevices (otras clases explicadas posteriormente) y as´ı poder disponer de la implementaci´on de otras funciones, como por ejemplo la implementaci´on del protocolo de transporte TCP/IP. NetDevice and Channel La clase NetDevice representa el interface f´ısico de un nodo (como por ejemplo un interface Ethernet). La idea b´asica es simular la arquitectura Linux en el l´ımite entre el dispositivo independiente de la subcapa de la capa de red y la capa IP. 74 Appendix C Figura C.1: Arquitectura de los objetos clave de una simulaci´on en NS-3 La clase Channel, que est´a estrechamente unida a la clase NetDevice, implementa el camino l´ogico por el cual fluye la informaci´on. Packet Los objetos de la clase Packet contienen un buffer de bytes. El contenido de este buffer se espera que corresponda bit a bit con el contenido de un paquete de una red real con todas las cabeceras de los protocolos y toda la informaci´on que contiene. El dise˜no de esta clase fue orientado por unos cuantos casos de uso: Evitar cambiar el n´ucleo del simulador para introducir nuevos tipos de cabeceras. Maximizar la manera de integrar la realidad con el c´odigo de los sistemas. Implementar un soporte f´acil para la fragmentaci´on, desfragmentaci´on y la concatenaci´on que son muy importantes especialmente en sistemas inal´ambricos. Tiene que ser muy natural la implementaci´on del dise˜no del paquete para que sea posible fragamentar el paquete en m´ultiples fragmentos y sea f´acil posteriormente ensamblarlos. Hacer que la gesti´on de memoria del objeto sea eficiente. Permita tanto a las aplicaciones simuladas como a las aplicaciones reales la utilizaci´on del mismo paquete. Applications Applications son procesos definidos por el usuario para generar tr´afico y poder mandar datos a trav´es de las redes simuladas. NS-3 provee un framework para desarrollar diferentes C.3. Casos de uso 75 tipos de aplicaciones que tienen diferentes patrones de tr´afico. Existe una clase base de Application que permite definir (a trav´es de la herencia) una nueva generaci´on de patrones de tr´afico. Para poner en funcionamiento una Application basta con crearla y asociarla a un objeto de la clase Node y la aplicaci´on mandar´a tr´afico a otros nodos a trav´es de sockets. ANEXO D An´ alisis de resultados salto a salto en NS-3 En este anexo se detallan los resultados obtenidos al analizar el throughput de la simulacion en el simulador NS-3 cuando interviene en la transmisi´on diferente n´umero de nodos (diferente n´umero de saltos). Observando la Figura D.1 se puede ver la gran diferencia que existe entre el throughput obtenido cuando se manda tr´afico desde el nodo 6 al 7 (que es muy alto) y el throughput entre el 7 y el 8. Este comportamiento es debido a que el modelo de p´erdidas en la propagaci´on que usado utiliza como principal par´ametro para el c´alculo. Si se observa la tabla 3.5 y se ordenan los nodos de menor a mayor distancia (6 →7, 4 →5, 3 →4, 2 →3, 1 →2, 5 → 6, 7 →8) se ve que es el mismo orden de mejor a peor throughput. Figura D.1: Promedio del throughput de la simulaci´on en NS-3 para 1 salto 77 802.11s based Wireless Mesh Network (WMN) test-bed Luis Javier S´anchez Cuenca Lule˚a University of Technology Dept. of Computer Science and Electrical Engineering Communication Networks Research Group March 2010 ABSTRACT Wireless Mesh Networks (WMNs) are one of the key technologies that is likely to play an important role in wireless networking in the next decade. They will help to realize the long-lasting dream of network connectivity anywhere and anytime with simplicity and low cost. Their capability of self-organization significantly reduces the complexity of network deployment and maintenance, and thus, requires minimal upfront investment. The main objective of this master thesis is to create a Wireless Mesh Network test-bed based on the project Open80211s in order to analyze the performance of this type of networks. The goals of this master thesis are to build and verify two installation packages for evaluating 802.11s WMNs. The first package will be based on Ubuntu Linux using the open80211s implementation and the second one will be based on the NS-3 network simulator. The verification includes performing tests on the performance and the quality of the network for typical topologies and traffic loads, and comparing the results between both systems and with the corresponding theoretic values. The main deliveries and results are two systems where we can test WMN technology. On one side, there will be a WMN test-bed in which real conditions can be analyzed, and on the other side there will be a WMN in which it will be possible to simulate a topology and check whether the results agree with reality. iii PREFACE This work has been carried out between September 2009 and March 2010 at Lule˚a University of Technology in Lule˚a (Sweden). I would like to dedicate this work to my grandfather, Jos´e S´anchez P´erez, he showed me a way of life and he always will be my reference. Wherever you are, thank you very much, I love you, “yayo”. I would also like to thank the people at Communication Networks Research Group for helping me with this master thesis. Particularly, I thank my supervisor, Ulf Bodin, for helping me all the way, for bearing with all my questions and for sharing his knowledge. A special thank you goes to all my friends, from Lule˚a and from Spain, for cheering me up during the bad moments. And last, but not least, an enormous thank to my family for giving me the chance to study and develop my Master Thesis in Lule˚a so far from them. There are no words to express my love and gratitude. Lule˚a −March 2010 Luis Javier S´anchez Cuenca v Contents Chapter 1 – Introduction 1 1.1 Background .................................. 1 1.2 Objectives of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Limitations .................................. 4 1.4 StructureoftheThesis............................ 4 1.5 Analysis of the results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.6 ProjectTimePlan .............................. 6 1.7 TechnologiesUsed............................... 8 Chapter 2 – WMN Ubuntu Test-Bed 11 2.1 Operating System Installation . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Open80211s package Installation . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 WMNsetup.................................. 14 2.4 WMNtopology ................................ 15 2.5 WMNexperiments .............................. 16 Chapter 3 – WMN in the NS-3 Simulator 35 3.1 Understanding the NS-3 Network Simulator . . . . . . . . . . . . . . . . 35 3.2 NS-3 Test-bed implementation . . . . . . . . . . . . . . . . . . . . . . . 40 3.3 NS-3Experiments............................... 45 3.4 NS-3 Results ................................. 46 Chapter 4 – Comparing results 53 4.1 Throughput.................................. 53 4.2 Analyzing “.pcap” files............................ 55 Chapter 5 – Conclusions 59 Chapter 6 – Future work 61 6.1 Test-bed.................................... 61 vii 6.2 NS-3 ...................................... 62 Appendix A – Upgrade Ubuntu Kernel 63 A.1 Download all the packets necessary . . . . . . . . . . . . . . . . . . . . . 63 A.2 Install all the packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 A.3 Rebootthesystem .............................. 64 A.4 See if you have installed 2.6.29 kernel . . . . . . . . . . . . . . . . . . . . 64 A.5 Rebootthesystem .............................. 64 A.6 Help ...................................... 64 Appendix B – Test-Bed User Manual 65 B.1 Introduction.................................. 65 B.2 Configurethenetwork ............................ 66 B.3 Add a new computer to the test-bed . . . . . . . . . . . . . . . . . . . . 70 Appendix C – NS-3 Program 79 C.1 b11mesh.cc .................................. 80 C.2 runMeshTest1.cc ............................... 85 C.3 meshNet.cc .................................. 86 Appendix D – Throughput tables 93 D.1 Test-bedexperimentI ............................ 93 D.2 Test-bed experiment II . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 D.3 NS-3experiment ............................... 96 Appendix E – List of Acronyms 99 viii List of Figures 1.1 Project Gantt’s Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 D-Link DWL-G122 Wireless G USB Adapter ............... 12 2.2 ChainWMNtopology ............................ 15 2.3 Topology of experiment I of the WMN test-bed . . . . . . . . . . . . . . 16 2.4 Network scenario experiment I . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5 Throughput for UDP and TCP . . . . . . . . . . . . . . . . . . . . . . . 19 2.6 Topology experiment II of the WMN test-bed . . . . . . . . . . . . . . . 21 2.7 Networkscenario1 .............................. 23 2.8 Networkscenario2 .............................. 23 2.9 Networkscenario3 .............................. 24 2.10Networkscenario4 .............................. 24 2.11Networkscenario5 .............................. 25 2.12Networkscenario6 .............................. 25 2.13Networkscenario7 .............................. 25 2.14 Average throughput test-bed for 1 hop . . . . . . . . . . . . . . . . . . . 27 2.15 Average throughput test-bed for 2 hops . . . . . . . . . . . . . . . . . . . 27 2.16 Average throughput test-bed for 3 hops . . . . . . . . . . . . . . . . . . . 28 2.17 Average throughput test-bed for 4 hops . . . . . . . . . . . . . . . . . . . 29 2.18 Average throughput test-bed for 5 hops . . . . . . . . . . . . . . . . . . . 29 2.19 Average throughput test-bed for 6 hops . . . . . . . . . . . . . . . . . . . 30 2.20 Average throughput test-bed for 7 hops . . . . . . . . . . . . . . . . . . . 31 2.21 Test-bed total throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.22 Test-bed total throughput vs. 90% confidence interval vs. maximum&minimum............................. 33 3.1 NS-3 key simulation objects architecture . . . . . . . . . . . . . . . . . . 38 3.2 Coordinate system of the NS-3 chain topology . . . . . . . . . . . . . . . 40 3.3 Different NS-3 propagation loss model . . . . . . . . . . . . . . . . . . . 41 3.4 Average throughput of NS-3 for1hop ................... 47 3.5 Average throughput of NS-3 for2hops................... 47 ix 4 Chapter 1: Introduction the simulated WMN, these shall be properly documented. The goal for this part is a verified simulation environment that corresponds to the 802.11s test-bed. Related to the second objective, we have the following goals: 1. Configure NS-3: Learn how to use NS-3 and configure it to establish the same scenarios that we have tested in the real world (Network of the first part of this project). 2. Obtain results: Simulate the Network and compare the results obtained from simulations with the ones obtained with the test-bed, analyzing possible differences. 1.3 Limitations The research presented in this thesis intends to create a test-bed based on the IEEE 802.11s protocol and study its behaviour. These are the limitations for this thesis: •The WMN will have eight computers. This way, it is big enough to allow useful studies of its behaviour while being reasonably easy to configure. It should be possible to add more computers to the network without having to make many changes. •The Test-bed will be configured manually, assigning static and local IP addresses to each computer of the network. •The Test-bed shall be tested in a specific topology, describing environment conditions and the specifics parameters of the network. •The NS-3 simulations should adapt to the real conditions using classes and objects already implemented in NS-3. New protocols or models will not be developed. 1.4 Structure of the Thesis This thesis starts with a summary on what we have done. This first Chapter shortly introduces the Wireless Mesh Network technology and enumerates the tools and equipment we have used. It also lays out the time plan of the Thesis. Chapter 2 focuses on the first goal of this Thesis, the WMN test-bed, planning how we have done it and explaining the steps we have followed to make it possible. It also shows how we have done the installation and configuration of the test-bed, which topologies we have chosen, on which scenarios we have test them, and the results of that test are explained at the end of the chapter. 1.5. Analysis of the results 5 Next, in Chapter 3, the thesis gives an overview of NS-3, the second goal of this thesis. Firstly, the main NS-3 concepts are introduced. Secondly, laid out the implementation decisions. Finally, experiments and results obtained from these experiments are explained. Chapter 4 shows the comparison of the results obtained in the test-bed and in the NS-3 simulation. Finally, chapter 5 displays the conclusions drawn in the thesis work and Chapter 6 sketches work that can be conducted to continue this thesis work. 1.5 Analysis of the results When we examined the experiments that we did in the test-bed and in NS-3 we focussed on analyzing the throughput. Throughput is the average rate of successful message delivery over a communication channel and is usually measured in bits per second (bit/s or bps, in some experiments we used Mbps). We used different formulas to calculate the throughput depending on whether we sent UDP or TCP traffic. For UDP we used: Throughput =TotalDataReceived TotalT ime Where: •Total Data Received: Bits received (UDP packets) by the destination from the source. •Total Time: Time elapsed since the source sends the first packet until the source sends the last packet. And for TCP we used the next formula: Throughput =TotalDataT ransmitted +T otalDataReceived TotalT ime Where: •Total Data Transmitted: Bits transmitted (TCP packets) from the source to the destination. •Total Data Received: Bits received (ACK) by the source from the destination. 6 Chapter 1: Introduction •Total Time: Time elapsed since the source sends the first packet until the source receives the last ACK. Both throughputs were comparable because we were measuring the total network UDP/TCP traffic. That is why when we calculate the UDP throughput we only the used total data transmitted (UDP sends packets without received any acknowledgment) and when we were calculating the TCP throughput we also take into account the acknowledgment data. We also calculated the Confidence Interval for the throughput, according to the next formula: Confidence =N·σ 2 √n And the Confidence Interval is (X- Confidence, X+ Confidence) Where: •N: Normal Distribution value according to the confident level chosen. •σ:Standard deviation of samples of throughput. •n: Number of samples of throughput. •X:Throughput samples average. 1.6 Project Time Plan In this section it is shown the time plan of this project. Figure 1.1: Project Gantt’s Diagram 1.6. Project Time Plan 7 As we can see in the Project Gantt’s Diagram (Figure 1.1), the project work is divided in weeks of full time work and with 40 hours per week. This work is explained in the following list. •W00-W01: Study relevant the 802.11 standards, usage of Linux experimental packages, identify hardware requirements for the test-bed, and order missing parts. •W01-W02: Document background, objectives and delimitations for the master thesis. •W02-W03: Identify basic functionally and metrics that shall be tested to verify a simple 802.11s WMN. •W03-W06: Build an installation package for setting up Ubuntu with 802.11s on two PCs, and test basic functionality and metrics for this installation. •W06-W07: Demonstrate the basic installation and testing. •W07-W08: Document the installation package and the basic testing for the master thesis. •W08-W09: Identify additional functionality and metrics for extended tests of larger WMNs consisting of up to 8 nodes. •W09-W12: Extend the installation package for arbitrary sizes of test-beds, and test additional functionality and metrics for this installation (8 PCs will be made available for this phase). •W12-W13: Demonstrate the extended installation and testing. •W13-W14: Document the extended installation package and the additional testing for the master thesis. •W14-W15: Study NS-3 and the 802.11s implementation in that environment. •W15-W18: Build an installation package for testing the same scenarios as tested in reality also in NS-3, test the same functionality and metrics for this installation as tested on the real-test-bed, and identify discrepancies and/or weaknesses. •W18-W19: Demonstrate the NS-3 installation and testing. •W19-W20: Document the installation package and the NS-3 testing for the master thesis. •W20-W21: Correct discrepancies and/or weaknesses in NS-3 to improve the simulation environment. •W21-W23: Document the corrections in NS-3 testing for the master thesis, and finish the thesis to make it ready for presentation and publication. 8 Chapter 1: Introduction 1.7 Technologies Used In this secction we shows the technologies used to do this project. 1.7.1 Operating System Ubuntu is a Linux-based operating system. Linux is a generic term referring to Unixlike computer operating systems based on the Linux kernel. Their development is one example of free and open source software collaboration. Typically all the underlying source code can be used, freely modified, and redistributed, both commercially and non-commercially, by anyone under the terms of the GNU GPL and other free software licenses. Ubuntu is chosen as operative system because: •It is free of charge, so you do not pay any licensing fees. It can be downloaded, used and shared with other people without paying anything. •It is possible to have always the latest applications that the open source world has to offer. •On Ubuntu, the open80211s package that we need to configure our Wireless Mesh Network is implemented. We used Ubuntu 9.04 [6]. It includes the latest enhancements and is maintained until the beginning of 2010. It comes with the 2.6.28 Linux-kernel but the kernel needs to be updated up to 2.6.29. 1.7.2 Network To analyze the Network we used Wireshark [9] and Iperf (or Jperf, a Iperf-java application). The reason for choosing Wireshark was that it is the network protocol analyzer most commonly used to sufficiently support our goals. Iperf was selected because it is a commonly used network testing tool that can create TCP and UDP data streams and measure the throughput of the network that is carrying them. Iperf is a modern tool for network performance measurement written in C++. To identify the best transmission channel, Network Stumbler offers the possibility to know who is using each channel and the signal/noise of those users. This is useful because we are interested in testing our network on a sparsely used channel. Others tools that we used: 1.7. Technologies Used 9 •Ping: Is a computer network administration utility used to test whether a particular host is reachable across an Internet Protocol (IP) network and to measure the round-trip time for packets send from the local host to a destination computer, including the local host’s own interfaces. •Tcpdump: Is a common packet analyzer that runs with the command line. It allows the user to intercept and display TCP/IP and other packets being transmitted or received over a network to which the computer is attached. •Route: Is a tool that manipulates the kernel’s IP routing tables. Its primary use is to set up static routes to specific hosts or networks via an interface. •Iptables: Provide a table-based system for defining firewall rules that can filter or transform packets. It can be also used to create static MAC address routing. •Iw: Is a new tool, still under development, used to configure utilities for wireless devices. •Iwconfig: Used to set the parameters of the network interface which are specific to the wireless operations. •Ipconfig: Is a utility that communicates with the IP configuration agent to retrieve and set IP configuration parameters. The current stable release of Wireshark is 1.2.2, of Iperf is 2.0.8, of Network Stumbler 0.4.0 (Build 554), and of tcpdump is 3.9.8. Mathematical calculations and data plotting are carried out in Matlab. To elaborate this report we have used L A T EX. 10 Chapter 1: Introduction 1.7.3 Hardware The 8 computers used in the first part of this master thesis have the following characteristics: Processor: Intel R Pentium R 4 CPU 2.40 GHz Cache size: 512 KB Hard Disk Capacity: 120 GB Ram Memory: 256 MB Ports USB: 6 ports USB 1.1 (data transfer rate of 12 Mbit/s) The computer used on the second part of the project it is a laptop with the next characteristics: Processor: Intel R Core 2 duo CPU P8600 2.40 GHz (2 CPUs) Cache size: 512 KB Hard Disk Capacity: 300 GB Ram Memory: 3 GB About the wireless card used, it is analyzed which one works with our requirements, if it is supported by the operating system used, and if it is work with the open80211s project. CHAPTER 2 WMN Ubuntu Test-Bed In this section it is explained how the Ubuntu Linux Operative System has been installed on the computers. It is also explained how the open80211s installation package has been developed and how to set up the Wireless Mesh Network. Finally, all the network testing process and the results obtained are described. 2.1 Operating System Installation Ubuntu is an operating system built by a worldwide team of expert developers. Ubuntu is free of charge and everyone can download it [6], use and share the Ubuntu with everybody for nothing. Everybody can contribute to Ubuntu project by writing new software, packaging additional software, or fixing bugs in existing software. For the test-bed, Ubuntu 9.04 version has been chosen because it was the latest version when this project started and because it gives all the tools needed to install the Open80211s package. To analyze which is the best Wireless USB Adapter, we had to look for one working with Ubuntu 9.04 and supporting IEEE 802.11s. We were interested to know which wireless card is compatible with the OS and if the driver works with the Open80211s project. For that, we have analyzed some drivers and some kernels. The first driver we analyzed was “zd1211rw” [10]. When we started to read about it, it seemed to work with 2.6.26 kernel version and we found a Wireless USB Adapter that works with this driver, but after some additional readings [11], we concluded that this driver has problems in some systems because of mesh beaconing triggers, which appears to be a firmware bug. 11 12 Chapter 2: WMN Ubuntu Test-Bed The second driver was “ath9k” [12] but we discarded it because this driver does not beacon with interfaces in Mesh Point mode, until the user performs a scan. We tried other drivers (as it is shown in [13]), and finally we decided to use “p54” [14] because it works with Ad-Hoc, AP, mesh, monitor and station mode. It works with the 2.6.29 Linux-kernel, but as we are using Ubuntu 9.04, we had to upgrade the Linux-kernel from 2.6.28 to 2.6.29. Once we decided which driver was the best option, we looked for a Wireless USB Adapter and we chose the “D-Link DWL-G122 Wireless G USB Adapter” [15], see Figure 2.1. Figure 2.1: D-Link DWL-G122 Wireless G USB Adapter This card has the following characteristics: ' & $ % Standards supported: USB 2.0, IEEE 802.11b and IEEE 802.11g Wireless Signal Rates: 54Mbps, 48Mbps, 36Mbps, 24Mbps, 18Mbps, 12Mbps, 11Mbps, 9Mbps, 6Mbps, 5.5Mbps, 2Mbps and 1Mbps (with automatic fallback). Frequency Range: 2.4GHz to 2.462GHz Operating Voltage: 5 VDC +/- 5 Receiver Sensitivity: 54Mbps OFDM, 48Mbps OFDM, 36Mbps OFDM, 24Mbps OFDM, 18Mbps OFDM, 12Mbps OFDM, 11Mbps OFDM, 9Mbps OFDM, 6Mbps OFDM, 5.5Mbps CCK, 2Mbps QPSK, 1Mbps BPSK Transmit Output Power: •802.11b: +16dBm at 11, 5.5, 2, and 1Mbps •802.11g: +10dBm at 54 and 48Mbps +12dBm at 36 and 24Mbps +14dBm at 18, 12, 9 and 6Mbps 2.2. Open80211s package Installation 13 ' & $ % Power Consumption: •Transmission: 310 mA max •Reception: 290 mA Security: 64/128-bit WEP and WPA-Wi-Fi Protected Access Media Access Control: CSMA/CA with ACK Wireless Signal Range: •Indoors: Up to 328 ft (100 meters) •Outdoors: Up to 1312 ft (400 meters) Antenna Type: Omni Directional Temperature: •Operating: 32◦F to 104◦F (0◦C to 40◦C) •Storing: 4◦F to 167◦F (-20◦C to 75◦C) These parameters are very important because we must know the admitted range to set them on the network, and which one we can change to different values to know the performance of the network. For example, it is possible to change the data rate between 1 Mbps and 54 Mbps or to change the power transmission/reception between 0 and 310 mA and 290 mA, respectively. 2.2 Open80211s package Installation Open80211s is a consortium of companies who are sponsoring (and collaborating in) the creation of an open-source implementation of the emerging IEEE 802.11s wireless mesh standard. Open80211s is a reference implementation of the upcoming 802.11s standard [16] on Linux. Open80211s is based on the mac80211 wireless stack [17] and should be run with any of the wireless cards that mac80211 supports. The goal is to create an installation package working on Ubuntu, consisting of shell scripts, which allows installing Open80211s and lets creating a WMN with this technology. There were two ways to install this system. The first one (called compact-wireless) consisted in downloading a package [18], already compiled, and installing it with the latest stable release. This package works with kernels equal or up to the 2.6.26 version. The second way (called wireless-testing), was to install the latest advances on the Linux 20 Chapter 2: WMN Ubuntu Test-Bed (frecuency) the throughput should decrease because interference between transmissions at different hops.In TCP we can also observe this behaviour but with no such big difference. From six to seven hops we can see how the throughput increases. The reason of this behaviour could be that nodes are not as much isolated as they should be or they can reach better other nodes, and hence they can connect to other nodes directly. Due to this fact, when they want to transmit, the network chooses the shortest way (it is working with dynamic routing) and does not make the expected hops. From these results we conclude that the network topology created is not a chain. Another problem that we found it was that the data rate its 54 Mbit/s but it never achieved this throughput. Furthermore, in both tests, it always worked with a bandwidth below 12 Mbit/s. At first, we thought that fallback to lower transmission rate option was activated because the channel was too noisy. We used Network Stumbler to see if the channel we were using (channel 6) was as crowded of traffic as it looked. We detected that someone was using it, but not as much as having such big decrease of the rate, and we also checked that the auto fallback option was not active. After thinking about it, we found that our computers got USB 1.1 ports, and the antennas were connected to those ports. This means, according to the USB 1.1 spec, that a maximum data rate of 12 Megabits per second can be reached. We can observe also that the throughput of the network it not very high. This is because there are too many walls between nodes and also because the aluminium folio and cans used on the antennas weaken the signal. From this experiment we have obtained some important information of the network, and for the next experiments we changed some settings and parameters: •To make sure that the topology of the network is a chain and nodes only communicates with their nearest nodes (maximum one on their right and one on their left) we used static routing. •To avoid problems with USB ports, we set the data rate to 11 MBits/s. Also, before starting the experiment, we looked with Network Stumbler which one was the less crowded channel. •To reduce the problem of the low throughput, we took out the aluminium folio and the cans from the antennas, and changed the place of the experiment, trying to make each node able to create a line of sight (with nothing between them) with the nearest nodes. 2.5. WMN experiments 21 2.5.3 Description of Experiment II The topology of this experiment consisted of putting the nodes of the network in corridors all around the building creating a chain topology but trying that walls did not act decreasing the signal between nodes. We can see in Figure 2.6 the topology of this network. Figure 2.6: Topology experiment II of the WMN test-bed With this topology we wanted to obtain less interferences between nodes as possible and also that communications between nodes flowed to the nearest node. The distances between nodes are described in Table 2.5. To be sure that communications flowed to the nearest node we used static routing by IP and by MAC address filtering. The parameters of this network topology are defined in Table 2.6 where we can see that we have changed some parameters from the topology of the experiment I. These changes were done because we wanted to set parameters right, learning from the experiment I and not falling in the 22 Chapter 2: WMN Ubuntu Test-Bed same errors. We have changed the transmission channel to 3 because we saw that it was the least used channel. To generate TCP traffic we set some parameters with Iperf. All these parameters are described in Table 2.7. Distances Node 1 →Node 2 37.96 m Node 2 →Node 3 36.65 m Node 3 →Node 4 36.65 m Node 4 →Node 5 33.79 m Node 5 →Node 6 39.21 m Node 6 →Node 7 25.41 m Node 7 →Node 8 44.10 m Table 2.5: Distances between nodes on the topology of experiment I Parameter Value Routing Static (IP and Mac) Data rate 11 Mb/s Transmitted signal power 18 dBm Channel frequency 2.422 e6 (channel 3) RTS/CTS Off Fragmentation threshold Off Power management On Table 2.6: Network parameters of experiment II Parameter Value Length of buffer to read or write 8 KB Server port to listen 5001 TCP window size (socket buffer size) 46.72 KB (32*MSS) TCP maximum segment size (MTU - 40 bytes) 1.460 KB Table 2.7: Iperf TCP settings 2.5. WMN experiments 23 Scenarios In this experiment we wanted to do a deep analysis, focusing on knowing the performance of this node when communicating with the others and how the networks worked with different numbers of nodes involved in the test. In the scenario 1 (Figure 2.7), we wanted to know the performance between nearest nodes (one hop). What we did was run the client on the first node and the server on the second and sent traffic between them, and after finishing it, run the client on the second node and the sever on the third node and so on until the last node. Figure 2.7: Network scenario 1 In the scenario 2 (Figure 2.8), we wanted to test the performance of data traffic between 3 nodes (two hops). We run the client in one node and we run the server on the second nearest node, repeating it until the last node. With this scenario we got 6 different samples. Figure 2.8: Network scenario 2 In scenario 3 (Figure 2.9), the traffic flowed between the first node and the fourth node (three hops) and so on until the last node. With this scenario we got five different samples of the network with which we could compare to know if the performance was similar. 24 Chapter 2: WMN Ubuntu Test-Bed Figure 2.9: Network scenario 3 Scenario 4 (Figure 2.10) tested the performance of having traffic between five nodes (four hops) getting four different samples in four different places of the nodes. Figure 2.10: Network scenario 4 On scenario 5 (Figure 2.11) we obtained the performance of communication between six nodes (five hops), having three different samples. 2.5. WMN experiments 25 Figure 2.11: Network scenario 5 With scenario 6 (Figure 2.12), we wanted to test the performance of of send traffic in the WMN with six hops. Figure 2.12: Network scenario 6 Scenario 7 (Figure 2.13) tested the test-bed with 7 hops, obtaining performance of the network when the traffic flows from the first node to the last one. Figure 2.13: Network scenario 7 For this experiment, we determined the number of repetitions, which communication protocol to use, and how much time takes each test sending traffic. We also decided the number of runs that we were going to do in each scenario and the time taken by each trial (see Table 2.8). 26 Chapter 2: WMN Ubuntu Test-Bed Scenario Number of runs Duration (min) 1 42 126 2 36 108 3 30 90 4 24 72 5 18 54 6 12 36 7 6 18 Total(theoretic): 504 min = 8,4 h Total(practical): 7 am - 1.35 am = 18,59h Table 2.8: Real and expected time for the test-bed experiment II When we run this experiment, we were helped by the Communication Network Research Group with the permissions needed to put all the computers in the corridors, helping us putting the computers working and also developing a script to run the different scenarios. The script was developed by the PhD student Anna Chaltseva. 2.5.4 Results of experiment II We measured the available throughput in terms of sent pay-load at Layer 4 with IP/TCP as bearer in the scenario of a single client. To obtain the results of this experiment, we have used tcpdump to capture all the traffic generated in the network. When each trial finishes, tcpdump creates a “.pcap” file that contains all the information about what happened in the network while we were testing it. Using Wireshark we calculated the throughput of each trial. We can see in Appendix D all the tables with all values calculated. Hop by hop The first analysis of the network we wanted to do was the performance of the network when we sent traffic from one node to another with different hops between them. In the following figures we show the trials (X axis) and the throughput (Y axis) and we plot the traffic flow between the different nodes. 2.5. WMN experiments 27 Figure 2.14: Average throughput test-bed for 1 hop In Figure 2.14 we can see the behaviour when the transmission is between two neighbouring nodes. We see that the worst throughput is from 5 to 6, but the difference between this performance and the other nodes does not show any anomalous interference. Figure 2.15: Average throughput test-bed for 2 hops 28 Chapter 2: WMN Ubuntu Test-Bed In Figure 2.15 we see that the difference between the behaviour of sending from 1 to 3 and sending from 3 to 5 is a big difference (more or less 2.4 Mbps). This is because if we see where they are placed, we see that to go from 1 to 3, packets have to cross a corner. We have the same problem with the 5 to 7 transmission, but the throughput is higher because the distance between them is smaller. Also we can see that from 2 to 4 the throughput is also very low. We can explain this because the corridor got narrower, and the node 4 received a weakness signal. Figure 2.16: Average throughput test-bed for 3 hops Analyzing the performance when we send traffic through 4 nodes (Figure 2.16), we can realize that the pattern noticed in the two hops graphic is also reference here. We can see how the lowest throughputs are when we are sending traffic from 1 to 4, from 4 to 7 and from 5 to 8, just where the transmission interferences are. 2.5. WMN experiments 29 Figure 2.17: Average throughput test-bed for 4 hops In Figure 2.17 we see that when we were sending traffic from node 1 to 5, there are some peaks, but we continue seeing that there is an interference problem between node 1 and node 3. We notice how other three transmissions between nodes that have same the problems we notice above, the throughput is similar. Figure 2.18: Average throughput test-bed for 5 hops 36 Chapter 3: WMN in the NS-3 Simulator 3.1.2 Supported mechanisms and protocols NS-3 has a modular implementation containing different libraries supporting the simulator (and it is also possible that users can write and link their own libraries): •Core library: Offers support for generic aspects of the simulator, such as to generate random numbers, use smart pointers, callbacks, or debugging objects. •Simulator library: Defines simulation parameters such as simulation time, objects, schedulers, and events. •Common library: Defines independent objects such as generic packets and tracing objects. •Node library: Defines abstract classes for fundamental objects in the simulator, such as nodes, channels and network devices. •Internet-node: Defines internet-related models such as TCP/UDP protocols. The modular implementation allows smaller compilation units and when compiling is only necessary to compile the program changed. NS-3 executable programs may be built to either statically or dynamically link the libraries. NS-3 offers support for the following: •Construction of virtual networks (nodes, channels, applications) and support for items such as event schedulers, topology generators, timers, random variables, and other objects to support discrete-event network simulation focused on Internetbased and possibly other packet network systems. •Support for network emulation: the ability for simulator processes to emit and consume real network packets. •Distributed simulation support: the ability for simulations to be distributed across multiple processors or machines. •Support for animation of network simulations. •Support for tracing, logging, and computing statistics on the simulation output. 3.1.3 Use cases To use NS-3 we have to know how it is designed. For that, we describe in this section design issues and usage models, and mention trends in simulation use within the networking research community. 3.1. Understanding the NS-3 Network Simulator 37 Model extensibility Users are interesting in extending the simulator by writing or modifying simulation programs. To make it possible, NS-3 uses object-oriented design with polymorphic classes, allowing users to modify the aspects they want to change. To facilitate the addition of new models, NS-3 adopts a component-based architecture for compile-time or run-time addition of new models, interface aggregation, and encapsulation, without requiring modification of the base models of NS-3. Run-time configuration NS-3 allows users to redefine default values and class types without recompiling the simulator. The default database values are integrated with a command-line argument parsing facility, making all the variables configurable from the command-line as well. Tracing NS-3 features a callback-based approach to tracing that difference between sources and destination. Packet traces are available in “pcap” format, to allow analyzing these files using network protocol analyzers such as Wireshark or Tcpdump. Scaling It is scheduled that NS-3 will include techniques for improving the scalability of simulations, including distributed simulation techniques introduced with PDNS and GTNetS, scalability techniques introduced for wireless simulations such as caching of computationally-intensive results, and fexibility in tracing infrastructure (to avoid large traces). Software integration NS-3 is oriented to reuse existing software such as NS-2 programs or other applications. The NS-3 design is built around encapsulation techniques separating the application interface from the implementation. NS-3 has also a library that allows implementation code to run in both real and simulated environments. Network emulation The NS-3 design is intended to facilitate interaction between simulation and experiments, with encapsulation techniques that allows real application and kernel code to run in the simulator, thereby improving traceability to real-world implementations. 38 Chapter 3: WMN in the NS-3 Simulator Programming The NS-3 user interface at present is a C++ “main” program. However, NS-3 will also feature Python bindings allowing users to define programs and replaceable components in Python. 3.1.4 Key simulation objects This section walks through the primary simulation objects in the simulator, related to the sending and receiving of packets between nodes. In Figure 3.1 [8], it is shown graphically the relations between objects. Figure 3.1: NS-3 key simulation objects architecture Node Class Node is intended mainly as a base class in NS-3, but it can be instantiated as well (i.e., it is not an abstract class). Users can create their own Node subclasses, and NS-3 will provide a few. The design uses patterns of software encapsulation to allow Applications and NetDevices (other class explained bellow) to talk to implementation independent interfaces of the underlying TCP/IP implementations. 3.1. Understanding the NS-3 Network Simulator 39 NetDevice and Channel Class NetDevice represents a physical interface on a node (such as an Ethernet interface). The basic idea is to simulate the Linux architecture at the boundary between the deviceindependent sub layer of the network device layer and the IP layer. Class Channel, which is closely coupled to the attached NetDevices, implements a logical path over which the information flows. Packet NS-3 Packet objects contain a buffer of bytes: protocol headers and trailers are serialized in this buffer of bytes using user-provided serialization and deserialization routines. The content of this byte buffer is expected to match bit-by-bit the content of a real packet on a real network implementing the protocol of interest. The design of the Packet framework of NS-3 was heavily guided by a few important use-cases: •Avoid changing the core of the simulator to introduce new types of packet headers or trailers. •Maximize the ease of integration with real-world code and systems. •Make it easy to support fragmentation, defragmentation, and, concatenation which are important, especially in wireless systems. It is quite natural to implement with this packet design, since we have a buffer of real bytes, we can split it in multiple fragments and reassemble these fragments. •Make memory management of this object efficient. •Allow actual application data or dummy application bytes for emulated applications. Applications Applications are user-defined processes that generate traffic to send across the networks to be simulated. NS-3 provides a framework for developing different types of applications that have different traffic patterns. There is an Application base class that allows one to define new traffic generation patterns via inheritance from this class. Then one simply creates the application and associates it with a node, and the application will send traffic down the protocol stack. Applications on a node communicate with the node’s protocol stack via sockets. 40 Chapter 3: WMN in the NS-3 Simulator 3.2 NS-3 Test-bed implementation In this section we present the decisions we have taken when implementing our test-bed in NS-3 simulator, and describe the problems we have found and what we have done to solve them. 3.2.1 Topology The topology we implemented was the topology of the test-bed of experiment II (see section 2.5.3). We focused on simulating that topology and setting all the parameters according to the concrete characteristics of the place and all the interferences it produces to the network. As we commented in the last chapter, it was a chain topology network so we put the nodes in a line, setting the real distance between them (see Table 5) as it is shown in Figure 3.2. Figure 3.2: Coordinate system of the NS-3 chain topology 3.2.2 Propagation loss model One of the most important parameters when we talk about wireless networks are the interferences (such as electrical equipment, other wireless networks, etc.) and obstacles (as walls, ceilings, doors, people moving, etc.) present in a real-world transmission medium. Due to all these interferences, the signal strength decreases in different ways. In order to set the test-bed interferences behaviour in NS-3, we have collected from the test-bed the average of the signal strength received by each node from the other nodes while we were doing the experiments and, with this information and knowing the distance between nodes we found a NS-3 propagation loss model according to this information. In NS-3 there are different propagation loss models (see Figure 3.3). We reviewed all of them to see which one adapted better to our test-bed requirements. 3.2. NS-3 Test-bed implementation 41 Figure 3.3: Different NS-3 propagation loss model Fixed Rss Loss Model With this model we can fix the propagation loss by setting the received power level (RSS, measured in dBm). We dismissed this model because it does not take the distance between nodes into account. Friis Propagation Loss Model This model uses an equation that gives the power received by one antenna under idealized conditions given the another antenna some distance away when transmitting a known amount of power. This model was interesting for us because with it we could calculate the power received. Jakes Propagation Loss Model This model allows setting some physical parameters such as: •The number of rays used by default to compute the fading coefficients for a given path. •The number of oscillators used by default to compute the coefficient for a given ray of a given path. •The Doppler frequency in Hz. •The distribution to choose the initial phases. We did not have these parameters from our test-bed, that is why we dismissed this model. 42 Chapter 3: WMN in the NS-3 Simulator Nakagami Propagation Loss Model This model is used to describe the statistical properties of a wireless channel since the signal propagation is affected by three statistically independent phenomena: deterministic path loss, slow lognormal shadowing and fast multipath fading. We dismissed it because it used as a reference two distances and it does not take the strength of the signal received into account. Random Propagation Loss Model This model is used when a parameter is included in some specifics values, i.e. distance. We did not use it for the distance because our nodes were static, but we used it to introduce a variance in the signal strength (it is explained in this chapter how and why we used it). Three Log Distance Propagation Loss Model This model is equal to the Log Distance Propagation Loss Model, but this model used three distance fields instead of one. We only needed one distance field, that is why for us it was better to use the Log Distance Propagation Loss Model. Log Distance Propagation Loss Model This model calculates the reception power with a so-called log-distance propagation model. We used this model in our simulation program because it was the one that better adapts to our network model. This model calculates the reception power (received signal strength) using the following equation: L=L0+ 10 ·n·log10 d d0 Where: •L0:Reference distance (m) •n:The path loss distance exponent •d:Distance (m) •d0:Reference distance (m) •L:Path loss (dB) To use this model for the test-bed we have had to estimate or calculate the value of these variables to adapt it to the real test-bed. 3.2. NS-3 Test-bed implementation 43 Propagation Loss Model Used We used three propagation loss models and one propagation delay model in the NS-3 implementation: Log Distance Propagation Loss Model,Friis Propagation Loss Model, and Random Propagation Loss Model. We used the Friis Propagation Loss Model knowing that this loss model is valid in the far field of the antenna, where far field starts far the beyond the Rayleigh distance, RayleighDistance =2·L2 a·f c Where: •La:Antenna size (in our case 1) •f : Transmission channel frequency •c : Speed of light (3 ·108m/s). In our case, Rayleigh distance is: RayleighDistance = 16.14ˆ 6 That is, the transmitter and receiver should be at a distance greater than the Rayleigh distance to calculate L0(as we can see in Table 7 all distances between nodes are bigger than the Rayleigh distance), L0= 20 ·log10 4·π·d0·f c Where: •d0:Reference distance (1m in our case) •f:Transmission channel frequency (in our case, Channel 3 = 2.422 ·109Hz) •c:Speed of light (3 ·108m/s). In our case L0is: L0= 40.125 Now that we have calculated the value of L0, we need to estimate the nvalue to apply the Log Distance Propagation Loss Model. To estimate n, the path loss distance exponent, we now that the test-bed testing was done indoor and we based our estimation on measurements acquired in a experiment for a WLAN indoor office environment [23], 44 Chapter 3: WMN in the NS-3 Simulator where it is said that “The indoor channel study requires N=18 for a LOS path between the transmitter and the receiver (a path loss exponent equal to 1.8)”; because of that, we set nto 1.8. To model exactly the values we obtained from the test-bed we added to this model the Random Propagation Loss Model to make it work in the range of signal strength where the test-bed works. The ranges of the received signal strength in the test-bed are values between -67 and -83 dBm, that is why we add a random model working between these parameters, setting the global received signal strength of the network in the range (L0+27, L0+43). We also added a propagation delay model due to the interferences of the air, setting it according with the speed of light (3 ·108m/s). 3.2.3 Implementation In this section it is described how the test-bed simulation program has been developed, the classes used and the problems founded developing it. In Appendix C it is shown the program code, how to run it and, it is also explained the class developed (MeshTest) and all the attributes and methods it use. Problems with 802.11s implementation When we set the protocol to use in the program of the simulation, we started using the NS-3 802.11s implementation [24]. We used the class MeshHelper to install it. For the first trials we sent TCP traffic from one node to another and it worked perfectly. After checking that everything worked correctly, we introduce the Propagation loss model mentioned above. When we tried to run it with the new features, it did not send any packets. To check that the problem was with the 802.11s implementation we changed to the IEEE 802.11b protocol, and we run the program using this protocol and the Propagation loss model and it worked perfectly. With this verification we concluded that there were some problems with the 802.11s implementation. We sent an email to the NS-3 developers reporting the problem but we did not get any answer. Due to this problem we decided to simulate the test-bed using the protocol IEEE 802.11b. This is possible because on the real test-bed we did not use any of the features that the IEEE 802.11s protocol offers, but anyway we were testing the 802.11s implementation without using some features, so all the settings on the test-bed can be setting up using IEEE 802.11b (we are also using 11 Mbps data rate). 3.3. NS-3 Experiments 45 Nodes We started creating the nodes using the class nodeContainer that contains 8 nodes. To set the parameters of the WiFi-card we used an object of the NetDeviceContainer class, and to set the interfaces of each node we used an object of the Ipv4InterfaceContainer because we were using the Internet Protocol version 4. After we set all the parameters of each object, we set the position of each node with the MobilityHelper class and we installed on nodes the devices and interfaces. Devices In the devices we set the Mac layer using the NqosWifiMacHelper class setting ADHOC as the routing protocol . We used the YansWifiChannelHelper class to set the Propagation loss model described above. To set up physical settings we used the YansWifiPhyHelper class, and we set some parameters such as the Energy Detection Threshold, the Transmission Gain, the Transmission Power, the Channel Number, etc. according with the test-bed values. Interfaces Using the InternetStackHelper class, we set the internet stack and for assigning IP address to each interface we use Ipv4AddressHelper. To set the static routing we used Ipv4StaticRoutingHelper. Application To install applications in the nodes we used ApplicationContainer and for sending traffic between nodes we use PacketSinkHelper which installs a TCP traffic generator on the client(TcpSocketFactory class). Random Runs We used the class seedManager to generate random executions, with a seed setting with a default value, but with the option of changing it as input of the program by value. 3.3 NS-3 Experiments Once we developed the program, we wanted to run the same experiment as run in the test-bed, described in section 2.5.3. Theoretic times expected in these experiments were the same as for experiment II, but the real time changed (see Table 3.1). To run this experiment we developed some scripts that run all the scenarios (see Appendix C ), six trials per scenario. As NS-3 is a simulator we changed the seed of the random generator each time we ran the program to obtain different simulations.