Escuela

Polit

écnic

a S

uperior

de L

ina

res

UNIVERSIDAD DE JAÉN Escuela Politécnica Superior de Linares

Trabajo Fin de Grado

______

REDES DE SENSORES

INALÁMBRICOS, SU SIMULACIÓN

EN EL NETWORK SIMULATOR

VERSIÓN 3

Alumno: Antonio Conejero Díaz

Tutor: Antonio Jesús Yuste Delgado Depto.: Ingeniería de Telecomunicación

Junio, 2014

Y que todo esto sin vosotros no hubiera sido posible.

II

Índice general

1. Resumen 1

2. Introducción 2

3. Objetivos 4

4. Materiales y métodos 54.1. Simuladores de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.1.2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.1.3. Evaluación de simuladores . . . . . . . . . . . . . . . . . . . . . 7

4.1.3.1. GloMoSim . . . . . . . . . . . . . . . . . . . . . . . . . 74.1.3.2. J-Sim . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.1.3.3. GTNetS . . . . . . . . . . . . . . . . . . . . . . . . . . 84.1.3.4. SSFNet . . . . . . . . . . . . . . . . . . . . . . . . . . 84.1.3.5. NCTUns . . . . . . . . . . . . . . . . . . . . . . . . . 94.1.3.6. OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . 124.1.3.7. NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.3.8. NS-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5. Resultados y discusión 235.1. Contexto tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1.1. Redes inalámbricas de sensores (WSN) . . . . . . . . . . . . . . 235.1.2. Nodo sensor inalámbrico . . . . . . . . . . . . . . . . . . . . . . 245.1.3. Topología de las redes de sensores . . . . . . . . . . . . . . . . . 255.1.4. Tecnologías de comunicación . . . . . . . . . . . . . . . . . . . . 26

5.1.4.1. Arquitectura de red . . . . . . . . . . . . . . . . . . . 275.1.4.2. Estándar IEEE 802.15.4 . . . . . . . . . . . . . . . . . 28

5.1.5. Protocolo de encaminamiento (AODV) . . . . . . . . . . . . . . 335.1.6. Protocolos de transporte . . . . . . . . . . . . . . . . . . . . . . 34

5.1.6.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

III

5.1.6.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1.7. Estudio de resultados . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2. Desarrollo del programa . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2.1. Simulador de redes NS-3 . . . . . . . . . . . . . . . . . . . . . . 385.2.2. Implementación de la red de sensores en NS-3 . . . . . . . . . . 38

5.2.2.1. Topología . . . . . . . . . . . . . . . . . . . . . . . . . 385.2.2.2. Modelo de pérdidas en la propagación . . . . . . . . . 425.2.2.3. Implementación red con tráfico TCP y UDP . . . . . . 455.2.2.4. Implementación red con tráfico Lr-Wpan . . . . . . . . 47

5.3. Simulaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.1. Resultados de las simulaciones TCP y UDP . . . . . . . . . . . 49

5.3.1.1. Resultados TCP . . . . . . . . . . . . . . . . . . . . . 505.3.1.2. Resultados UDP . . . . . . . . . . . . . . . . . . . . . 52

5.3.2. Resultados de las simulaciones Lr-Wpan . . . . . . . . . . . . . 54

6. Conclusiones 57

Bibliografía 58

A. Simulador NS-3 60A.1. Alcance de NS-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60A.2. Mecanismos y protocolos soportados . . . . . . . . . . . . . . . . . . . 60A.3. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61A.4. Objetos clave para la simulación . . . . . . . . . . . . . . . . . . . . . . 62

B. Manual de usuario 65B.1. Instalación de NS-3

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65B.1.1. Requisitos previos . . . . . . . . . . . . . . . . . . . . . . . . . . 65B.1.2. Descarga e instalación de NS-3 usando Mercurial . . . . . . . . 68B.1.3. Construcción del ns-3 con build.py . . . . . . . . . . . . . . . . 68B.1.4. Configuración con Waf . . . . . . . . . . . . . . . . . . . . . . . 69B.1.5. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

B.2. Modo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70B.2.1. Parámetros de entrada de los programas TCP y UDP . . . . . . 70

B.2.1.1. Ejecución de la simulación . . . . . . . . . . . . . . . . 70B.2.2. Parámetros de entrada del programa Lr-Wpan . . . . . . . . . . 73

B.2.2.1. Ejecución de la simulación . . . . . . . . . . . . . . . . 73B.2.2.2. Generación de los ficheros GNUplot . . . . . . . . . . . 74

C. Manual de mantenimiento 76

IV

D. Código fuente de los programas 108D.1. pfc_tcp.cc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108D.2. pfc_udp.cc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125D.3. pfcscript.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141D.4. lr-wpan.cc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

V

Índice de figuras

4.1. Modelo de canal con NCTUns . . . . . . . . . . . . . . . . . . . . . . . 104.2. Arquitectura NCTUns . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3. Ejemplo del entorno gráfico del NCTUns . . . . . . . . . . . . . . . . . 114.4. GUI de OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.5. GUI del Nam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.6. GUI del nsbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.7. GUI de PyViz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1. Ejemplo de red Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2. Arquitectura en capas de IEEE 802.15.4 . . . . . . . . . . . . . . . . . 295.3. Formato general de la trama MAC . . . . . . . . . . . . . . . . . . . . 315.4. Topologías de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.5. Escenario 100 nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.6. Escenario 25 nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.7. Escenario 16 nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.8. Escenario Lr-Wpan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.9. Modelos de pérdidas en la propagación disponibles en NS-3 . . . . . . . 425.10. Visualización del algoritmo RandomWalk2MobilityModel en el escenario

de 16 nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.11. Diagrama de carpetas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.12. Gráfica con los resultados de la simulación TCP . . . . . . . . . . . . . 515.13. Gráfica con los resultados de la simulación UDP . . . . . . . . . . . . . 535.14. Simulación con un tamaño de paquete de 20 bytes . . . . . . . . . . . . 555.15. Simulación con un tamaño de paquete de 50 bytes . . . . . . . . . . . . 555.16. Simulación con un tamaño de paquete de 100 bytes . . . . . . . . . . . 555.17. Simulación con un tamaño de paquete de 114 bytes . . . . . . . . . . . 565.18. Simulación con un tamaño de paquete de 115 bytes . . . . . . . . . . . 56

A.1. Arquitectura de los objetos clave de una simulación en NS-3 . . . . . . 63

B.1. Ejecución del script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71B.2. Numero de simulaciones a efectuar . . . . . . . . . . . . . . . . . . . . 71

VI

B.3. Ejemplo ejecución del fichero pfc_tcp.cc . . . . . . . . . . . . . . . . . 72B.4. Ejemplo ejecución del fichero pfc_tcp.cc . . . . . . . . . . . . . . . . . 74B.5. Ejemplo de utilización de la herramienta GNUplot . . . . . . . . . . . . 75

VII

Índice de tablas

5.1. Comparativa entre estándares inalámbricos . . . . . . . . . . . . . . . . 285.2. Características según la banda de trabajo . . . . . . . . . . . . . . . . . 305.3. Resultados de las simulaciones TCP . . . . . . . . . . . . . . . . . . . . 505.4. Resultados de las simulaciones UDP . . . . . . . . . . . . . . . . . . . . 52

VIII

1

Resumen

En los últimos años han tomado especial relevancia en el ámbito de las I+D+i lasredes inalámbricas de sensores WSN (Wireless Sensor Networks). Las WSN se estánaplicando en muchos ambientes y con distintos propósitos. Estas redes están compues-tas por pequeños dispositivos compactos y económicos llamados nodos-sensores quetienen la capacidad de detectar y suministrar datos a otros sistemas, se comunicaninalámbricamente y están especialmente diseñados para redes con pérdidas y recursoslimitados de memoria.

En este proyecto se propone implementar y simular una red inalámbrica de sensoresmultisalto que se encuentran en movimiento dentro de un recinto cuadrangular. Parapoder llevar a cabo el escenario, se ha desarrollado una aplicación que permite a losnodos comunicarse entre ellos, la cual medirá en función del tráfico generado, TCP oUDP, el throughput o la tasa de paquetes perdidos respectivamente. Un porcentaje denodos se comunicarán con un nodo central llamado “sink”.

También se ha implementado una red de sensores compuesta por dos nodos, loscuales implementan el estándar IEEE 802.15.4. Con este escenario se ha querido hacerun estudio de este estándar, específico para redes de sensores.

Mediante este trabajo hemos comprobado las diferentes ventajas e inconvenientesque tienen cada uno de los protocolos estudiados mediante diversos escenarios simuladosen NS-3.

1

2

Introducción

El proyecto que vamos a describir tiene por objeto el análisis, implementación ysimulación de una red de sensores con el simulador de redes network simulator en suversión 3 (en adelante NS-3 ).

Este proyecto se divide en cuatro partes principales, que describiremos brevemente:

Instalación del software:

El simulador NS-3 es un software libre y se ejecuta sobre Linux, por ello, se hautilizado como sistema operativo Ubuntu para ejecutar dicho simulador. Ubuntues un sistema operativo basado en Linux y además, es recomendado para utilizareste simulador por los propios desarrolladores del NS-3.

Sobre este sistema operativo se instalará el simulador NS-3, en el Manual deUsuario que se incluye en este proyecto, se detalla paso a paso como ha de reali-zarse dicha instalación.

Red de sensores:

Se han implementado dos redes de sensores:

1. Una red siguiendo una topología en estrella. Para dicha implementación seha diseñado un escenario cuadrangular de cientocincuenta metros cuadrados,sobre el cual se definirán diferentes números de sensores.

2. Otra red que constará de dos sensores que se irán distanciando entre ellos.

2

Simulación:

1. Para la primera red, la simulación consistirá en la transmisión de tráficoTCP (Transmission Control Protocol) y UDP (User Datagram Protocol)entre los nodos que constituyen la red de sensores.

2. Para la segunda red, la simulación consistirá en la transmisión de tráfico Lr-Wpan (IEEE 802.15.4) entre los dos nodos que conforman la red de sensores.

Cabe destacar que en el Anexo B incluido en el proyecto se indica detalladamentecomo ha de realizarse dicha simulación.

Análisis de los resultados obtenidos:

Una vez realizadas las simulaciones los programas obtienen una serie de datosdependiendo del tráfico generado:

• TCP: para este tipo de tráfico se obtendrá el throughput el cual nos indica-rá el promedio de paquetes de información entregados satisfactoriamente através de la red.

• UDP: para este tipo de tráfico se obtendrá la cantidad de paquetes perdidosen la red.

• Lr-Wpan: para este tipo de tráfico se obtendrá la tasa de paquetes entregadoscon éxito entre los dos nodos que componen la red.

3

3

Objetivos

Los objetivos del presente proyecto fin de carrera son:

Realizar el análisis de los simuladores de redes que se emplean actualmente.

Adquirir los conocimientos necesarios para programar en NS-3.

Implementar redes de sensores en NS-3.

Simular tres tipos de fuentes con distintas características (TCP, UDP y Lr-Wpan)sobre las redes de sensores implementadas, y analizar los resultados obtenidos.

4

4

Materiales y métodos

En este capítulo se evalúan los distintos simuladores de red. Hay que tener en cuentaque esta evaluación se ha realizado de acuerdo a las especificaciones técnicas necesariaspara este proyecto.

4.1. Simuladores de red

4.1.1. Introducción

Existe un gran número de simuladores de red disponibles. De entre ellos veremoslos que son de uso libre y gratuito (al menos para fines académicos), con una especialatención a los cuatro que se ajustan mejor a las características del proyecto (NCTUns,OMNeT++, NS-2 y NS-3). En este estudio no se tomarán en consideración programasde pago (tales como OPNET, QualNet o Shunra), puesto que el código fuente no estádisponible y es imposible tanto la validación de sus modelos como la creación y modi-ficación del código.

Las aplicaciones que se evalúan, son todas simuladores de eventos discretos querepresentan a un sistema como una secuencia cronológica de eventos. Cada uno deestos eventos, que sucede en un momento determinado, marca un cambio de estado enel sistema (un ejemplo de evento es el envío de un paquete). Durante la simulación segeneran un conjunto de ficheros que una vez procesados permiten extraer parámetrospara estimar las prestaciones de la red; tales como el throughput -tasa de transmisión-entre estaciones, retardo, pérdida de paquetes, etc.

4.1.2. Requisitos

El software de simulación de red que se necesita debe cumplir todos o la mayorparte de los siguientes requisitos. Si alguna de las características no está disponible, se

5

discutirá la posibilidad de implementarla.

Licencia: cualquier licencia de software libre [1]. Se aceptan excepcionalmentelicencias académicas, es decir, aquellas libres excepto para fines comerciales (cabenotar que, bajo estas restricciones, estas aplicaciones no se consideran softwarelibre).

Sistema operativo: preferiblemente multiplataforma, aunque el soporte parasistemas operativos libre (en especial GNU/Linux) es un requisito indispensable.Excepcionalmente se aceptan simuladores que funcionen a través de plataformas(no emuladas) como Wine.

Protocolos inalámbricos: debe soportar los protocolos WiFi más comunes(802.11 a/b/g) y WiFi con QoS (calidad de servicio) 802.11e.

Encaminamiento: el simulador debe permitir la creación de redes con topolo-gías complejas, con encaminamiento configurable entre interfaces y nodos.

Nivel físico configurable: los simuladores de redes incorporan habitualmentesus propios modelos físicos de propagación. Esto supone una ventaja a la hora demontar redes sencillas y ver en una primera aproximación su comportamiento,pero en redes más complejas, en las que hay que tener en cuenta la distancia ymodelos de propagación más sofisticados, es necesario usar otras aplicaciones es-pecializadas. Debe tener la posibilidad, por tanto, de usar la información extraídadel planificador RF (Radio Frequency) en el simulador de red.

Simulaciones distribuidas: no es un requisito imprescindible, pero se valoraráque el simulador de red permita simular de forma paralela (en diferentes máqui-nas), para agilizar simulaciones complejas.

Uso de protocolos/simulaciones reales: la práctica totalidad de simuladores,por razones comprensibles de integración, implementan los protocolos desde cero.Esto introduce distorsiones que, en menor o mayor medida, influyen en la preci-sión de los resultados. Además, y esto es todavía más importante, hace imposibleel uso a través de las redes simuladas de aplicaciones reales.

6

Esto supone la imposibilidad de facto de estimar las prestaciones de aplicacio-nes reales, y que haya que limitarse a trabajar con aplicaciones muy simplificadas(normalmente incluidas en el propio simulador). Se valorará la posibilidad de usarimplementaciones reales de protocolos (normalmente TCP y UDP) y que las apli-caciones puedan ejecutarse sobre redes simuladas sin modificación de ningún tipo.

Modo emulación: aunque no es propiamente una funcionalidad que se vaya aemplear en este proyecto, se valorará la posibilidad de poder emplearlo en modoemulación. Un emulador de red permite que dispositivos reales interaccionen através de la red simulada. De esta forma es posible evaluar las prestaciones deaplicaciones que necesitan valoración empírica (por ejemplo: la calidad de unacomunicación de VoIP).

Modo de comandos/GUI (Graphical User Interface): se valorarán ambosaspectos, que la aplicación tenga un soporte en modo comando (lo que incluyesi extensión con scripts), pero también que disponga de un interfaz de usuariode fácil uso para la creación rápida e intuitiva de redes y el lanzamiento desimulaciones.

Comunidad y estado del proyecto: un proyecto de software se valora, ademásde por sus características objetivas, por su nivel de actividad, esto es, por la exis-tencia de una comunidad de usuarios y desarrolladores que a su alrededor creennuevos módulos, tutoriales, reportes de problemas, propuestas de mejora, etc.Se valorará también que el simulador se haya estudiado en artículos en revistascientíficas del IEEE.

4.1.3. Evaluación de simuladores

A continuación se evalúan una serie de simuladores de red analizando las caracterís-ticas de cada uno. En función de los requisitos previamente mencionados, los simulado-res seleccionados serían: GloMoSim, J-Sim, GTNetS, SSFNet, NCTUns, OMNeT++,NS-2 y NS-3.

4.1.3.1. GloMoSim

GloMoSim [2] es un entorno de simulación para redes inalámbricas con licencia aca-démica (no es software libre). Está programado en Parsec, un lenguaje basado en Cespecialmente diseñado para la simulación de eventos discretos en redes de comunica-ción de gran escala (soporta miles de nodos).

7

Este simulador se descarta por diversas razones, principalmente porque su desarro-llo está completamente detenido (la última versión estable data de diciembre de 2000).Aparentemente su desarrollador original (Rajive Bagrodia, UCLA) se ha volcado enla versión propietaria de GloMoSim (QualNet) a través de la empresa SNT (ScalableNetwork Technologies), programa del que sí se lanzan nuevas versiones periódicamente.

En el punto en que quedó el desarrollo original GloMoSim tenía un soporte muylimitado de protocolos WiFi (únicamente código para 802.11b en modo ad-hoc, aunqueexiste documentación sobre la implementación de un modo infraestructura y soportepara 802.11e).

4.1.3.2. J-Sim

J-Sim [3] (anteriormente conocido como JavaSim) es un entorno de simulación ba-sado en componentes. El núcleo está programado en Java y usa el lenguaje de scriptingTCL (Tool Command Language) para la definición de escenarios y simulaciones.

A pesar de contar con un buen diseño, flexible y extensible, J-Sim se descarta porsu pobre soporte para protocolos inalámbricos (sólo incluye una versión básica delMAC 802.11, ninguno de los estándares para el nivel físico). Además, su desarrollo seencuentra aparentemente detenido, ya que su última versión estable data de febrero de2004.

4.1.3.3. GTNetS

Georgia Tech Network Simulator [4] es un simulador bajo licencia BSD (BerkeleySoftware Distribution, software libre) desarrollado en C++. Esta aplicación se ha usadotradicionalmente para el diseño de topologías de gran escala y con gran número de nodos(por ejemplo, redes de sensores).Se descarta por el limitado soporte de protocolos WiFi. Además, tiene una comunidadde usuarios muy reducida, no hay listas de correo ni acceso libre al repositorio decódigo.

4.1.3.4. SSFNet

SSFNet [5] comprende un conjunto de modelos de red programados en Java sobrela plataforma de simulación SSF (Scalable Simulation Framework).

SSFNet no es una aplicación pensada para redes inalámbricas, de hecho no se haencontrado ningún modelo para los estándares 802.11. Este hecho es suficiente para

8

excluirlo de la lista de simuladores candidatos. Asimismo, el desarrollo parece dete-nido (la última versión estable, 2.0, es de 2004) y la lista de correo no tiene tráficosignificativo desde hace meses.

4.1.3.5. NCTUns

NCTUns [6] es un simulador y emulador de redes cableadas e inalámbricas desa-rrollado en la Universidad de NCTU (National Chiao Tung University) de Taiwan,comercializado y apoyado por SimReal Inc. (empresa virtual fundada en 2002 con elfin de promover el uso de NCTUns).

Por las características y especificaciones del simulador (muy completas) se hará unestudio en profundidad del mismo.

Análisis

Licencia: Se puede usar, copiar, modificar y distribuir para usos no comercialeso lucrativos. Es por tanto software libre.

Sistema operativo: Fedora Linux 9. Es posible instalarlo en otras distribucionesde Linux con mayor o menor esfuerzo. Ver por ejemplo el proceso de instalaciónen sistemas Debian/Ubuntu. (Aquí poner el enlace a bibliografía)

Código: C++

Protocolos inalámbricos: 802.11a infraestructura AP/cliente, 802.11a ad-hoc,802.11b infraestructura AP/cliente, 802.11b ad-hoc, 802.11e, 802.11p, 802.11d(Mesh y PMP), 802.16e, GPRS (General Packet Radio Service) y DVB-RCST(Digital Video Broadcast - Return Channel Satellite Terminal). Soporta todoslos protocolos en los que estamos interesados excepto 802.11g .

Encaminamiento: Las topologías que se pueden crear son muy limitadas. Unescenario típico, como es un nodo con un interfaz en modo infraestructura ma-naged (cliente) y otro en master (servidor) no puede simularse, ya que no hayforma de intercomunicar ambos interfaces. Esto es así porque un nodo managedse considera móvil, y por tanto no puede conectarse a ningún otro excepto a supunto de acceso (AP: Access Point) por vía inalámbrica.

Nivel físico configurable: En los interfaces inalámbricos las características delcanal son configurables, tal y como se muestra en la Figura 4.1.

9

Figura 4.1: Modelo de canal con NCTUns

Simulaciones distribuidas: Soportadas. El simulador está divido en tres partes,el GUI, el dispatcher y el coordinator. Cada una de las partes pueden correr enordenadores distintos (y los coordinadores en tantas máquinas como se quiera).Un ejemplo de esta arquitectura se muestra en la Figura 4.2.

Figura 4.2: Arquitectura NCTUns

Uso de protocolos/simulaciones reales: Una de las características más des-tacables de NCTUns es que utiliza una pila de protocolos TCP/IP del propiosistema operativo. Esto asegura una mejor aproximación al comportamiento fi-nal de la red y el uso de aplicaciones ya existentes sobre las redes simuladas.

Modo de comandos/GUI: No tiene soporte por línea de comandos o scripting.La topología, configuración de nodos y simulación se inicia a través del interfazgráfico. Un ejemplo se puede observar en la Figura 4.3. Dicho interfaz es bastantecompleto, pero es poco claro y tiene una distribución confusa de opciones y menús.

10

Figura 4.3: Ejemplo del entorno gráfico del NCTUns

Comunidad y estado del proyecto: Pese a que su primera versión estable datade 2002 y que todavía está en desarrollo, NCTUns no ha conseguido estableceruna comunidad amplia de usuario y desarrolladores a su alrededor. Última versiónestable: versión 6.0 de noviembre de 2009.

Comunidad: No se han encontrado módulos para NCTUns hechos por desa-rrolladores externos. NCTUns dispone de una lista de discusión, pero con unvolumen de correos muy bajo, en las que habitualmente las consultas quedan sinrespuesta. El código en desarrollo de NCTUns no está disponible a través de unrepositorio (sólo las versiones estables son descargables). Publicaciones IEEE: 10publicaciones (cuatro a cargo de los desarrolladores originales).

Valoración

NCTUns es un simulador muy interesante en varios aspectos. En primer lugar porimplementar los protocolos de la familia WiFi más usados (excepto 802.11g). Por otraparte, el uso de la pila de protocolos del kernel del Linux y la posibilidad de utilizaraplicaciones reales a través de redes simuladas (incluso en modo emulación) es tambiénuna característica muy atractiva.

Entre los aspectos negativos destaca la rigidez de la herramienta: al estar orientadaa su uso exclusivo mediante un GUI, es imposible cualquier ajuste que no esté disponi-ble a través de interfaz gráfico. Como hemos visto, el encaminamiento entre interfacestrabajando en modos distintos (que no es posible a nivel de red) constituye también

11

una limitación grave para redes de mediana complejidad.

El aspecto más negativo de NCTUns es, sin embargo, su pobre impacto en la comu-nidad tras casi ocho años de existencia. El simulador parece seguir un modelo cerradode desarrollo (sorprende que el código no este disponible en repositorios de acceso li-bre), lo que hace prever que las futuras modificaciones de la herramienta provenganúnicamente de sus creadores.

4.1.3.6. OMNeT++

OMNeT++ [7] es una plataforma de simulación con arquitectura modular y exten-sible, tan flexible que se utiliza en ámbitos tan diversos como el modelado de redes,protocolos, sistemas de colas, multiprocesadores o arquitecturas hardware. En general,es un simulador útil para cualquier tipo de sistema en que pueda modelarse por lasimulación por eventos discretos y el intercambio de mensajes.

El simulador de red OMNeT++ tiene un diseño orientado a objetos, simple y mo-dular, lo que le permite escalar bien en la simulación de grandes redes.

Análisis

Aunque OMNeT++ no proporciona componentes específicos para la simulación deredes, existen entornos especializados -frameworks- desarrollados independientementeal núcleo con sus propios ciclos de publicación. En el ámbito que nos interesa, los másdestacables son INET, Mobility e INETMANET. Como sucede en otros simuladoreslibres, los esfuerzos no están del todo coordinados y dicho frameworks tienen códigorepetido o reimplementado. De estos frameworks, INETMANET es el más reciente eintegra funcionalidad de los otros dos, así que será estudiado en este análisis.

Licencia: OMNeT++ tiene una licencia propia a la que denomina AcademicPublic License, libre sólo para usos académicos (no es, por tanto, software libre).El framework INETMANET, por otro lado, sí es software libre, ya que sus com-ponentes están licenciados bajo la GPL ó LGPL. Para usos no académicos existeOmnest [8], la versión comercial de OMNeT++.

Sistema operativo: GNU/Linux y Microsoft Windows.

Código: C++ y NED (Network Description), lenguaje propio usado para definirla topología de los módulos.

Protocolos inalámbricos: Implementados por entornos (frameworks) especia-lizados. INETMANET soporta los protocolos 802.11a/b/g en modos ad-hoc e

12

infraestructura, con algunas limitaciones: no hay soporte para fragmentación,control de potencia ni PFC (Point Coordinator Function). Para 802.11e existeuna implementación muy limitada y que aparentemente no ha sido validada porla comunidad de OMNeT.

Encaminamiento: INETMANET implementa los protocolos de encaminamien-to dinámico AODV (Ad hoc On-Demand Distance Vector Routing), DSV (Destination-Sequenced Distance Vector Routing), DSR (Dynamic Source Routing), DYMO(Dynamic MANET On-Demand) y OLSR (Optimized Link State Routing).

Nivel físico configurable: El núcleo de la arquitectura de INETMANET es elmódulo de control de canal (ChannelControl). Dependiendo de la distancia y delas características del nivel físico de ambos nodos, decide si éstos están en rangode comunicación o no. El único modelo de propagación implementado es el deespacio libre.

Simulaciones distribuidas: Soportadas.

Uso de protocolos/simulaciones reales: No está soportado. Recientementese han propuesto para el interfaz con aplicaciones reales, pero según los propiosautores sólo es posible para aplicaciones de complejidad reducida. En cuanto aluso de protocolos reales, OppBSD adapta el protocolo TCP/IP del kernel deFreeBSD a OMNeT. Con este proyecto, además, se pueden emular redes queinteractúan con nodos en el mundo real.

Modo comandos/GUI: Soporte completo a través de línea de comandos. Po-tente GUI basado en Eclipse con el que editar módulos (C++), ficheros NEDy ficheros de simulación (INI). Asimismo las simulaciones se pueden lanzar enmodo comando o mediante el interfaz gráfico, que se muestra en la Figura 4.4.

13

Figura 4.4: GUI de OMNeT++

Comunidad y estado del proyecto: Después de años de desarrollo (el proyectose inició en 1992) OMNeT sigue mostrando una gran vitalidad y cuenta con unacomunidad importante a su alrededor. Última versión estable: versión 4.2.2 demarzo de 2012.

Comunidad: OMNeT++ es un simulador bastante popular en el mundo acadé-mico debido a su versatilidad y extensibilidad, y dispone de una gran cantidad dedocumentos disponibles en la red. Existen muchos módulos y desarrollos exter-nos al proyecto, aunque la descoordinación y la dispersión de esfuerzos es notoria.OMNeT++ dispone de una gran cantidad de foros de discusión con un volumenalto de mensajes.

Valoración

OMNeT++ es indudablemente una potente herramienta de simulación, con un di-seño modular, extensible y versátil que permite al usuario un control completo desdesu entorno de programación (ya sea a través de ficheros NED o de módulos C++).Cuenta, además, con un completo soporte tanto por línea de comandos como a travésdel interfaz gráfico (este último sensiblemente mejorado en la última versión).

Entre los aspectos negativos hay que destacar que los frameworks existentes para lasimulación de redes inalámbricas implementados sobre OMNeT son todavía limitados.Si bien los problemas de enrutamiento que hemos visto (que tienen su origen en laexistencia de un único controlador de canal) serían enmendables, la implementación delos protocolos inalámbricos es todavía insuficiente.

14

4.1.3.7. NS-2

NS-2 es un simulador de eventos discretos muy popular en el ámbito académicopor su amplia difusión. Su desarrollo comenzó en 1989 a partir del simulador REAL,y hasta el día de hoy ha contado con soporte y financiación de diferentes entidadespúblicas y privadas (DARPA, Xerox, UCB, Sun, CONSER, etc). NS-2 sigue la filosofíade desarrollo abierta, lo que ha contribuido decisivamente a su crecimiento, convirtién-dose en una de las herramientas más completas tanto en el estudio de redes cableadascomo inalámbricas.

Análisis

Licencia: GNU General Public License (GPL) versión 2 (software libre).

Sistema operativo: Sistemas POSIX como FreeBSD, GNU/Linux, SunOS, So-laris o Cygwin.

Código: Núcleo en C++ e interfaz de usuario en OTcl. OTcl (Object Tcl) es unaextensión de objetos para el lenguaje Tcl. Como capa de interfaz entre C++ yOTcl se usa TclCL.

Protocolos inalámbricos:

• WiFi: Además del módulo CMU (la implementación tradicional de 802.11en ns-2), la versión 2.35 incorpora dos nuevos módulos (que no lo comple-mentan, sino que lo sustituyen por completo; el usuario debe elegir cuál delos tres utiliza):

◦ CMU: Único existente hasta NS-2.33, el modelo desarrollado por laCarnegie Mellon University implementa DCF (Distributed Coordina-tion Function) y usa el esquema RTS/CTS/DATA/ACK para paquetesunicast y DATA para multicast. Según la opinión mayoritaria de la co-munidad se trata de una implementación muy pobre, puesto que obviamuchos aspectos del estándar y lo simplifica hasta tal punto que com-promete la fidelidad de los resultados. Entre las principales carenciasdestacan la falta de beacons, de paquetes de control, control de poten-cia de transmisión o asignación dinámica de canales. De igual forma,no se implementa la exploración de canales (scanning), asociación niautenticación. Las dos últimas carencias han sido resueltas por IlangoPurushothaman para NS-2.35 y ahora se da un soporte mucho más com-pleto para el modo infraestructura.

15

◦ 802.11Ext: Desarrollado por un equipo de Mercedes-Benz y de la uni-versidad de Karlsruhe, implementa un nuevo 802.11 MAC y capa física(Mac802_11Ext y WirelessPhyExt). Entre otras características, el mó-dulo presenta un diseño estructurado del MAC, el cálculo de la SINR(Signal- to-Interference Noise Ratio), soporte para múltiples modulacio-nes, control de pérdida de paquetes en capa física e implementación delmodelo Nakagami de atenuación (adecuado para largas distancias).

◦ dei802mr: Derivada del módulo MCU, la implementación del DEI (De-partment of Information Engineering de la Universidad de Padua) incor-pora modelos físicos con diferentes tasas de transmisión para 802.11b/g.Además lleva a cabo un cálculo más preciso del SINR, del PER (Packet-Error-Rate) a partir de las curvas PER vs SINR vs el tamaño del pa-quete (proporcionadas para 802.11b/g y modificables por el usuario), lapotencia de ruido es configurable en los scripts Tcl. Asimismo, la afec-tación entre nodos se puede limitar según la distancia entre los mismos.En las 3 implementaciones el valor scripts Tcl, mientras que ACKTi-meout SlotTime es un parámetro configurable desde los es un valor joen el código C++. Sería necesario algún ajuste (aunque no debería sercomplicado hacer que el parámetro fuera configurable desde Tcl). Encuanto a la implementación de los diferentes estándares 802.11:

� 802.11a: Soportado por el módulo 802.11Ext.� 802.11b/g: Soportados por el módulo dei802mr con velocidades va-

riables (modo b: 1/2/5.5/11Mb, modo g: 6/9/12/18/24/36/48/54Mb).� 802.11e: Los módulos oficiales de NS-2 no soportan el estándar. Se

han encontrado diferentes implementaciones externas, aunque nin-guna para la última versión de NS-2: El módulo de Claudio Casettiimplementa EDCF/HCF, pero su desarrollo está parado y sólo fun-ciona hasta NS-2.29. Ni Qiang de INRIA desarrolló en 2004 módulospara EDCF y Adaptative EDCF, pero no han sido actualizados yno funcionan en versiones recientes de NS-2. El proyecto Nshccade la Universidad de Pisa implementa HCCA (parche para versión2.29). El proyecto de la Universidad técnica de Berlín (parche pa-ra NS-2.28) da soporte básico para EDCA, aunque no implemen-ta adaptación de velocidad, asociación, autenticación ni gestión deenergía.

Encaminamiento: Están disponibles tres tipos de encaminamiento para comu-nicación unicast: el algoritmo de caminos mínimos de Dijkstra estático (las rutas

16

se computan sólo al inicio de la comunicación), dinámico (las rutas se computancuando hay cambios en la topología durante la simulación) y encaminamientoDV (Distributed Bellmand-Ford, también conocido como Distant-Vector). Si lodesea, el usuario puedo no usar ningún protocolo de encaminamiento y crear ma-nualmente las rutas. Para redes mesh con nodos móviles están implementados losprotocolos DSDV (Destination Sequence Distance Vector), DSR (Dynamic Sour-ce Routing), TORA (Temporally-Ordered Routing Algorithm) y AODV (Ad-hocOn-demand Distance Vector).

Nivel físico configurable: Cada módulo visto en el apartado anterior tienesus particularidades, pero en general los parámetros del canal físico son muyconfigurables.

Simulaciones distribuidas: No soportadas.

Uso de protocolos/simulaciones reales:No es posible usar aplicaciones reales,pero sí pilas TCP (FreeBSD, OpenBSD, IwIP y Linux) a través de Network Si-mulation Cradle.

Modo de emulación: Soportado, con diversos proyectos que añaden extensio-nes.

Modo de comandos/GUI: El interfaz con NS-2 se hace a través de comandos.Existen aplicaciones gráficas como Network Editor (que forma parte de nam [9],módulo oficial de NS-2, ver Figura 4.5), Extended Nam Editor [10], nsbench [11](ver Figura 4.6) o nsg [12]. La opción mayoritaria sigue siendo, sin embargo, lacreación manual de los scripts Tcl. En cuanto a la visualización de los resultados,está disponible el interfaz gráfico oficial nam (Network Animator) y aplicacionesdesarrolladas por terceros como TraceGraph [13] o Trace Analyzer [14].

17

Figura 4.5: GUI del Nam

Figura 4.6: GUI del nsbench

Comunidad y estado del proyecto: Última versión estable: ns-2.35 del 4 denoviembre de 2011.

Publicaciones IEEE: Se han encontrado más de un millar de artículos relacio-nados con el simulador.

18

Valoración

NS-2 es el estándar de facto entre los simuladores libres tanto en el mundo académicocomo en la industria, y por ello dispone de una gran cantidad de código y documen-tación disponible en comparación con el resto de simuladores. Uno de sus principalesinconvenientes es que NS-2 arrastra carencias de diseño (reconocidas por la propiacomunidad) que ha hecho necesario el desarrollo de numerosos parches y extensionesque quedan frecuentemente obsoletos por falta de mantenimiento. También es bastanteaceptado que el desarrollo en NS-2 (con su dualidad C++/Tcl) es extremadamenteincómodo y complejo.

Por último, destacar que si bien NS-2 cumple prácticamente todos los requisitos através de extensiones desarrolladas por terceros, muchas de estas implementaciones noson compatibles entre sí, lo que impediría simular escenarios con todos los protocolosrequeridos.

4.1.3.8. NS-3

NS-3 [15] es un nuevo simulador de red de eventos discretos que pretende convertirseen el sucesor de NS-2. El proyecto está financiado por la NSF-CISE (National ScienceFoundation, Computer & Information Science & Engineering).

NS-3 tiene su punto de partida en el trabajo de Mathieu Lacage en el simuladorYANS (Yet Another Network Simulator), durante el cual se identificaron en NS-2 unconjunto de fallos de diseño que juzgaron lo suficientemente importantes como parainiciar un nuevo simulador desde cero. Entre estos fallos destacaban la falta de versa-tilidad, debido básicamente a la dependencia entre nodos (acoplamiento), el deficienteuso de las técnicas de programación orientada a objetos, y el rígido acoplamiento entreC++ y OTcl.

A diferencia de su predecesor, NS-3 está desarrollado exclusivamente en C++, aun-que permite el interfaz con lenguajes de alto nivel (por ahora sólo Python). Los antiguosscripts para NS-2 (desarrollados en OTcl) no funcionan en NS-3.

NS-3 es un proyecto reciente (iniciado en junio de 2006). Por las características ylas grandes expectativas que NS-3 ha creado en la comunidad, se hará un estudio enprofundidad.

Análisis

19

Licencia: Usa la GNU GPL v2.

Sistema operativo: Sistemas POSIX como GNU/Linux, BSD, OS X yMicrosoftWindows (con Cygwin o MinGW).

Código: Núcleo en C++. Las simulaciones se pueden hacer en C++ o con Pyt-hon. En el futuro se prevé que también se pueda desarrollar el prototipado deprotocolos con Python.

Protocolos inalámbricos:

• 802.11a: El desarrollo original implementa completamente 802.11a en modoinfraestructura (AP/cliente) y ad-hoc.

• 802.11b: Guangyu Pei y Tom Henderson presentaron en el Wns3-2009 (2009Workshop on ns-3) una propuesta para el desarrollo del modelo y su valida-ción, pero no hay todavía código disponible de su implementación.

• 802.11e: De los dos tipos de acceso que contempla HCF (Hybrid Coordi-nation Function), ns-3 implementa EDCA (Enhanced Distributed ChannelAccess) y está en desarrollo el soporte para HCCA (Controlled Access).

• 802.11g: No se ha encontrado ninguna referencia a la implementación delmodo g.

Encaminamiento: Si la simulación no está orientada a pruebas específicas deencaminamiento, por simplicidad se emplean una tabla de enrutado centralizaday única (objeto GlobalRouteManager). Además, existen implementaciones paraencaminamiento estático (tanto para unicast comomulticast) y OLSR (OptimizedLink State Routing). La implementación de Nivel físico configurable: Quagga estáen desarrollo.

Nivel físico configurable: En los interfaces inalámbricos las características delcanal son configurables.

Simulaciones distribuidas: Soportadas.

Simulación de aplicaciones/protocolos reales: Soportadas.

Modo emulación: Soportado, una simulación NS-3 puede enviar datos a travésde redes reales a otros nodos de simulación NS-3.

Modo de comandos/GUI: Todas las operaciones se realizan por línea de co-mandos. Existe un herramienta gráfica llamada PyViz que nos permite la visua-lización gráfica del escenario de simulación, así como las operaciones que realizanlos nodos en dicha simulación (ver Figura 4.7).

20

Figura 4.7: GUI de PyViz

Comunidad y estado del proyecto: Última versión: NS-3.16 del 21 de diciem-bre de 2012.

Comunidad: A pesar de contar con menos de 6 años de vida, NS-3 ya ha es-tablecido una amplia comunidad alrededor (favorecido por seguir un modelo dedesarrollo abierto y marcar una clara orientación en los objetivos del proyecto).Uno de los objetivos declarados de NS-3 es replicar a largo plazo el éxito de NS-2respecto a la enorme cantidad de código externo. NS-3 dispone de varias listasde correo (para desarrolladores y usuarios).

Publicaciones IEEE: Hasta el momento hay 17 artículos publicados [16].

Valoración

NS-3 es un simulador que recoge el testigo de NS-2 en sus mejores aspectos (licen-cia libre, desarrollo abierto, colaboración amplia de la comunidad académica) a la vezque trata de superar las carencias y fallos de diseño (ampliamente compartidos por sucomunidad de usuarios) de una herramienta con veinte años de historia. La cantidadde documentación en forma de tutoriales, detalles de la API, artículos, etc, con la quecuenta es un elemento a destacar.

4.1.4. Conclusiones

En este capítulo se ha hecho un estudio de simuladores de red de eventos discretosno propietarios. De entre ellos, se han visto en más detalle cuatro que, a priori, parecían

21

cumplir el objetivo del proyecto (NCTUns, OMNeT++, NS-2 y NS-3).

De los dos primeros, NSTUns aparece como una aplicación interesante, pero dema-siado rígida (especialmente por su dependencia del interfaz gráfico) y con una comu-nidad demasiado pequeña como para ser una opción fiable. Por su parte OMNeT++cuenta con uno de los mejores diseños -modular y extensible- de entre los simuladoresvistos, pero las limitaciones vistas (especialmente en sus entornos de simulación deredes inalámbricas) son muy severas.

NS-2 es una herramienta potente, con muchos módulos disponibles (aunque no to-dos actualizados), pero compleja e incómoda de usar, además de arrastrar decisionesde diseño que con el tiempo se revelaron no del todo acertadas. Aunque sobre el papeles posible encontrar módulos para todos y cada uno de los escenarios que se necesitan,no es posible simular en un mismo escenario todas ellas (sirva como ejemplo la tríadade implementaciones incompatibles para los niveles MAC y 802.11).

En cuanto a NS-3, cumple la necesaria tarea de recoger la experiencia de NS-2 yque, a pesar de no poder considerarse un producto todavía maduro pues cuenta conimplementaciones todavía limitadas, es un simulador con un buen diseño desde su ori-gen, muy potente y flexible.

Por todas estas razones, se concluye que NS-3 es la opción más sólida conla que trabajar en el proyecto y sin duda la opción más adecuada pensandoen su desarrollo a medio y largo plazo.

22

5

Resultados y discusión

En este capítulo se detallan las tecnologías empleadas en el desarrollo del proyec-to, así como la forma en que se ha llevado a cabo para obtener los resultados de lassimulaciones que hemos previsto de cara a validar la utilidad del simulador NS-3 parala implementación de redes de sensores.

5.1. Contexto tecnológicoEn esta sección vamos a definir y describir una serie de conceptos, protocolos y

dispositivos que van a ser utilizados en la realización de este proyecto.

5.1.1. Redes inalámbricas de sensores (WSN)

Las WSN (Wireless Sensor Networks) son redes formadas por dispositivos indepen-dientes, llamados nodos, que en la mayoría de los casos son capaces de monitorizar elvalor de una o varias magnitudes físicas y transmitir esta información a través de unared formada por estos mismos dispositivos. Para realizar esta tarea, los nodos sensoressuelen estar formados básicamente de un microcontrolador, de un chip radio, de uno ovarios sensores y de una fuente de energía.

Las redes formadas por este tipo de dispositivos suelen ser redes inalámbricas ad-hoc, en las cuales cada nodo de la red es capaz de monitorizar variables del entorno yde actuar como parte de una red multisalto para transmitir la información. Como severá en apartados posteriores dos de las características más importantes en las redesde sensores son las restricciones energéticas y las bajas prestaciones de los dispositivos.

23

5.1.2. Nodo sensor inalámbrico

En general cuando hablamos de un nodo sensor nos referimos a un dispositivo detamaño reducido, de bajo coste, capaz de comunicarse de manera inalámbrica, de pres-taciones limitadas y con un consumo bajo, lo que implica que el alcance de este tipo dedispositivos va a ser también limitado. Esto quiere decir que en la mayoría de los casosno serán capaces de comunicarse a distancias mayores que unas decenas de metros eimplicará la necesidad de crear protocolos de encaminamiento a través de la red, quepermitan incrementar el alcance mediante el envío de mensajes multisalto. Por lo tan-to, en la mayoría de aplicaciones, un nodo sensor no solo tendrá la tarea de medir lasmagnitudes físicas deseadas, deberá ser capaz de encaminar mensajes que le lleguen delos nodos vecinos a través de la red.

Teniendo en cuenta todos los factores comentados hasta el momento, en los siguien-tes apartados realizaremos un resumen de las tecnologías existentes para cada uno delos componentes que acostumbran a componer los nodos sensores.

Los nodos sensores están, fundamentalmente, formados por un microcontrolador,un transceptor, algún tipo de fuente de alimentación, sensores y unidades de memoriaexterna.

Microcontroladores: el microcontrolador es el elemento principal del nodo sen-sor debido a que es el componente encargado de procesar toda la información delmismo mediante tareas como la recolección de datos procedentes de los sensores,el procesado de esta información, la gestión de donde y cuando debe ser enviadadicha información, el control de los actuadores, si es que el nodo dispone de ellos,y en general cualquier operación que realiza el nodo.

Los procesadores utilizados en las redes de sensores son mucho más simples y mo-destos a nivel de prestaciones que los que se utilizan en otro tipo de dispositivos.En este sentido, estos microcontroladores presentan un consumo reducido y, en lamayoría de los casos, disponen de mecanismos para dejar inactivas determinadaspartes del mismo cuando no son necesarias.

Transceptor: esta unidad permite la transmisión y recepción de datos a otrosdispositivos, conectando al nodo en la red de sensores. Un nodo sensor wirelesstípico se comunica utilizado un sistema de RF (Radio Frequency) y algún tipo detecnología PAN (Personal Area Network) . Para la realización de este proyecto sehan simulado las especificaciones técnicas del transceptorMRF24WG0MA/MB

24

(fabricado por Microchip) [20].

Fuente de energía: un suministro de energía apropiado debe ser capaz de ali-mentar al nodo durante horas, meses o años, dependiendo de la aplicación. Comoejemplo de plataforma desatendida, suelen incorporar una alimentación median-te un sistema autónomo (generalmente baterías), combinado con alguna fuentede recarga (células solares, p.e.) o energía auxiliar. Estas estrategias de recargasuelen dar buen resultado en operaciones donde no es posible llevar a cabo unreemplazo de la batería.

Memoria externa: los nodos suelen estar dotados de poca memoria RAM comomemoria de usuario, para las aplicaciones o datos personales, y de algún tipo dememoria no volátil , como la memoria flash, para el almacenamiento de progra-mas y datos permanentes, debido a su bajo coste y una aceptable capacidad dealmacenamiento.

Unidad/es de detección o sensores: un sensor es un dispositivo que midealguna magnitud física y la convierte en una señal que es procesada por el mi-crocontrolador. Entre la amplia gama de tipos de sensores existentes figuran lossensores de aceleración, sísmicos, humedad, iluminación, presión, sonido, térmi-cos, acústicos, visuales, infrarrojos y magnéticos. Los sensores pueden ser pasivoso activos, y direccionales u omnidireccionales.

5.1.3. Topología de las redes de sensores

En la mayoría de casos, las redes de sensores se diseñan con el objetivo de reportarinformación procedente de la red hasta un punto o varios concretos de la misma, dondeesa información puede ser tratada o reenviada a través de cualquier otro tipo de redhasta otro punto. Por lo tanto, en una red de sensores, se tiene una parte de la redque opera en modo infraestructura, ya que la información debe ser enviada a un nodoque juega el papel de punto de acceso y otra parte de la red que funciona de maneraad-hoc, debido a que no todos los nodos de la red disponen de un enlace directo con losnodos que juegan el papel de punto de acceso. Este tipo de redes se denominan redesMesh.

25

Figura 5.1: Ejemplo de red Mesh

Las redes de sensores no disponen de infraestructura asociada, más allá de los no-dos que juegan el papel de recopiladores de información. Este tipo de nodos suelenser denominados como estación base (Base Station) o en algunos casos como sumide-ro (sink). Los demás nodos de la red forman una red ad-hoc en la cual los nodos seasocian para transmitir la información hasta la estación base, a través de múltiplessaltos, jugando todos los nodos el papel de host y de router de manera indistinta. Deesta manera se consiguen redes flexibles, que permiten la inclusión de nuevos nodossin necesidad de estar dentro del alcance de una estación base, ni de crear infraestruc-tura nueva más allá de tener conectividad con cualquier nodo que forme parte de la red.

Redes de sensores multisalto

Tal y como se ha comentado anteriormente, en las redes de sensores se hace necesariala inclusión de mecanismos que permitan transmitir información desde zonas alejadasrespecto al destino que se pretende alcanzar. La solución consiste, en la mayoría de loscasos, en incluir protocolos de encaminamiento (routing) encargados de crear rutas omecanismos que permitan utilizar los propios dispositivos sensores para retransmitirlos paquetes procedentes de los distintos puntos de la red hacia su destino. Un proto-colo de encaminamiento muy usado es AODV (ad hoc on Demmand Distance VectorRouting) que posteriormente describiremos.

5.1.4. Tecnologías de comunicación

Para la comunicación entre los sensores se ha optado por la utilización de tecnologíasde radiofrecuencia. En este apartado se describen las especificaciones del estándar decomunicaciones inalámbricas IEEE 802.11 también llamado WiFi (Wireless Fidelity) ylas especificaciones del estándar IEEE 802.15.4, empleado comúnmente para las redes de

26

sensores. En este proyecto se han empleado el estándar 802.11b y el estándar 802.15.4.

5.1.4.1. Arquitectura de red

Define dos tipos distintos de sistemas y varios modos de asociación entre los dispo-sitivos:

El modo infraestructura utiliza un patrón de Master/Slave siendo el maestro elpunto de acceso, AP, y el esclavo la estación, STA. Las estaciones se conectanentre sí mediante un intermediario, el punto de acceso. Este modo es el que seaplica para punto a multipunto que a su vez funcionan en conexiones de punto apunto.

El modo ad-hoc conecta directamente dispositivos sin necesidad de ningún ele-mento intermedio, utilizándose por ello en enlaces punto a punto. Aplicando estemodo en toda la red se consiguen redes mesh, cuya ventaja principal es podercubrir una mayor área con un menor número de equipos.

El estándar 802.11 define tanto la capa física, PHY, como la capa de acceso al medio,MAC. En la mayoría de ocasiones la siguiente capa, nivel 3, transportará el protocolode internet, IP.

Desde que se definió el estándar en 1997, han surgido diferentes familias que tra-bajan en distintas tasas de transmisión, incluso en distintas frecuencias, que mejoranlas deficiencias detectadas y mejoran las prestaciones. Cada familia añade una letra alnombre de la tecnología y se pueden describir brevemente de la siguiente manera:

802.11, trabaja en la banda de 2.4GHz y alcanza tasas de hasta 2Mbps.

802.11a, trabaja en la banda de 5.8GHz y alcanza tasas de hasta 54Mbps.

802.11b, trabaja en la banda de 2.4GHz y alcanza tasas de hasta 11Mbps.

802.11g, trabaja en la banda de 2.4GHz y alcanza tasas de hasta 54Mbps.

802.11e, extensión que proporciona calidad de servicio (QoS) a redes 802.11a/g/h.

Para este proyecto se ha utilizado el estándar 802.11b, definiendo la tasa de transfe-rencia a un máximo de 1 Mbps.

27

5.1.4.2. Estándar IEEE 802.15.4

El estándar IEEE 802.15.4 [18] define la capa física (PHY) y la capa de control deacceso al medio (MAC) para redes inalámbricas de bajo consumo, como las redes desensores. Esta especificación se desarrolló para dar respuesta a la demanda crecientede un protocolo más sencillo que no consumiera tantos recursos, ya que los estándarespresentes hasta la fecha están orientados a aplicaciones que utilizan mucha energía yun elevado ande de banda. Los protocolos más destacados en ese sentido son el IEEE802.11, comúnmente conocido como WiFi, y el IEEE 802.15.1 o Bluetooth.

En la siguiente tabla se muestra una comparativa entre los tres estándares, dondese reflejan cuantitativamente las diferencias existentes entre ellos:

Estándar Ancho de banda Consumo CoberturaWiFi 54 Mbps 400 mA en Tx | 20 mA en reposo 100 m

Bluetooth 1 Mbps 40 mA en Tx | 0’2 mA en reposo 10 mIEEE 802.15.4 250 Kbps 1’8 mA en Tx | 5’1 µA en reposo 100 m

Tabla 5.1: Comparativa entre estándares inalámbricos

Al comparar sus parámetros, se ve como el estándar 802.15.4 se ha desarrollado pa-ra proveer las capas física y MAC de las redes LR-WPAN (Low-Rate Wireless PersonalArea Network).

Como consecuencia de su bajo consumo tenemos un ancho de banda y una poten-cia de transmisión más reducidas. Por tanto esta tecnología inalámbrica sólo permitecomunicaciones de corto alcance típicamente con distancias de hasta 100 metros.

Este ancho de banda depende también de la frecuencia a la que trabaja el estándar.El 802.15.4 está diseñado para funcionar en la banda de 2’4 GHz a una tasa de 250kbps, en la de 868 MHz a 40 kbps y en la de 915 MHz a 20 kbps. A pesar de tenerestas tres alternativas, se suele utilizar la banda de 2’4 GHz, ya que es común en todoel mundo, mientras que las otras dos frecuencias sólo están disponibles en Europa yEstados Unidos respectivamente.

28

Arquitectura

Se presenta las diferentes capas de la arquitectura como bloques para facilitar su ex-plicación, refiriéndose a cada bloque como una capa. Este sistema está basado en elmodelo de las 7 capas OSI.

Figura 5.2: Arquitectura en capas de IEEE 802.15.4

Capa física

La capa física proporciona el servicio de transmisión de datos sobre el medio físico,así como el interfaz con el servicio de gestión por medio del cual se puede accedera todos los servicios de gestión del nivel. De este manera, la capa física controla eltransceptor de radiofrecuencia y realiza la selección de canales junto con el control deconsumo y de señal.

A continuación se enumeran sus principales funciones:

Activación y desactivación del transceptor de radio.

Detección del nivel de energía en el canal de trabajo.

Brindar un Indicador de Calidad de Enlace (LQI) de los paquetes recibidos,basados en su nivel de potencia.

Realizar una valoración de canal libre (CCA), el cuál será utilizado por la sub-capa MAC para el algoritmo de Acceso Múltiple por Detección de Portadora conEvasión de Colisiones (CSMA/CA).

Elegir el canal de frecuencia de trabajo.

Transmisión a través del canal físico de los mensajes.

29

Aunque como se ha visto el estándar permite transmisión en tres frecuencias distintas:868 MHz, 915 MHz y 2400 MHz, es en ésta última donde más se suele emitir porquees la frecuencia libre de libre emisión a nivel mundial y por tanto la emisión en ellacarece de solicitud de licencias y demás temas burocráticos.

Frecuencia central(MHz)

Banda defrecuencia (MHz)

Nº canales Modulación Tasa detransmisión (Kbps)

868,3 868 - 868.6 1 BPSK 20915 902 - 928 10 BPSK 402400 2400 - 2483.5 16 O-QPSK 250

Tabla 5.2: Características según la banda de trabajo

Subcapa MAC

Transmite tramas MAC usando el canal físico. Además del servicio de datos, ofreceuna interfaz de control y regula el acceso al canal físico. También controla la validaciónde las tramas y las asociaciones entre nodos, y garantiza slots temporales. Por último,ofrece puntos de acceso para servicios seguros.

En resumen, las principales funciones de la subcapa MAC:

Generación de beacon de red (si el dispositivo es un coordinador).

Sincronización de los beacons.

Soporte de asociación y disociación de PAN (Association y Disassociation).

Soporte a la seguridad del dispositivo.

Empleo del mecanismo de CSMA/CA para acceso al canal.

Manejo y mantenimiento del mecanismo GTS (Guaranteed Time Slot).

Enlace fiable entre dos entidades MAC.

Formato general de la trama MAC

El formato general de una trama MAC se muestra en la figura 5.3 . A la trama delMAC se le denomina unidad de datos de protocolos MAC (MPDU) y se compone delencabezado MAC (MHR), unidad de servicio de datos MAC (MSDU), pie de MAC(MFR). El primer campo del encabezado de trama es el campo de control. Este indicael tipo de trama MAC que se pretende trasmitir, especifica el formato y la dirección

30

de campo y controla los mensajes de enterado. En pocas palabras, la trama de controlespecifica como es el resto de la trama de datos y que es lo que contiene.

Figura 5.3: Formato general de la trama MAC

LP HY = Longitud de las cabeceras PHY y de sincronización en bytes (6).LMAC_HDR = Longitud de la cabecera MAC en bytes (3).Laddress = Longitud del campo de información de dirección.LMAC_F T R = Longitud del MAC footer en bytes (2).

El tamaño de las direcciones puede variar entre 0 y 20 bytes. Además, el campo deinformación de direcciones puede contener el identificador de PAN de 16 bits, tanto delremitente como del receptor. Estos identificadores sólo pueden omitirse si no se envíandirecciones. El campo payload de la unidad de datos de protocolo MAC es variable,con la limitación de que una trama MAC completa (MPDU o PSDU) no podrá superarlos 127 bytes de información.

Se ha mencionado que el tamaño máximo de la MPDU es de 127 bytes. En conse-cuencia, el número de bytes de datos que se pueden enviar en un paquete está limitado.Cuando la longitud de dirección se establece en 2 bytes (16 bits), el tamaño máximodel payload es de 114 bytes. Esto se puede calcular de la siguiente manera:

MPDU = LMAC_HDR + Laddress + LMAC_F T R + payload (5.1)

donde, Laddress = 2 ·2 bytes+2 ·2 bytes de los identificadores PAN y las direccionescortas, respectivamente. Al poner los valores correctos en la equación 5.1 para MPDU,nos da 114 bytes como máxima longitud para el campo payload. En cambio, cuando

31

se utilizan direcciones largas de 64 bits, son 102 bytes los que se pueden poner en unpaquete. Finalmente, si no se utilizasen direcciones los identificadores PAN se puedenomitir, lo que significa que la Laddress es cero, y por lo tanto, el payload máximo quese puede tener es de 122 bytes.

Elementos de una red 802.15.4

El estándar define dos tipos de nodo de red:

Dispositivo de funcionalidad completa (Full-Function Device, FFD): tiene dosmodos de funcionamiento, como coordinador de una red de área personal (PAN)o como un nodo normal. Implementa un modelo de comunicación que le per-mite intercambiar mensajes con cualquier otro dispositivo. Además, es capaz deencaminar mensajes actuando como coordinador.

Dispositivo de funcionalidad reducida (Reduced-Function Device, RFD): son dis-positivos muy sencillos, con recursos y necesidades de comunicación muy limita-das. No puede actuar como coordinadores y sólo pueden comunicarse con otrosFFD. Las redes pueden construirse como redes punto a punto o en estrella. Encualquier caso, toda red necesita al menos un FFD que actúe como coordinador.

Se definen dos tipos de topologías de red para éste estándar:

Redes punto a punto: su extensión está limitada únicamente por la distanciaexistente entre cada par de nodos. Debido a que en el estándar no se define capade red, no se soportan funciones de enrutado directo.

Redes en estrella: se forma cuando un FFD decide crear su PAN y se nombra así mismo coordinador (nodo central), tras elegir un identificador de PAN único.Entonces, otros dispositivos pueden unirse a una red totalmente independientedel resto de redes en estrella. Las redes se componen de grupos de dispositivos.Cada dispositivo posee un identificador único de 64 bits, aunque si se dan ciertascondiciones de entorno pueden utilizarse identificadores cortos de 16 bits.

32

Figura 5.4: Topologías de red

5.1.5. Protocolo de encaminamiento (AODV)

El protocolo de encaminamiento AODV fue inicialmente desarrollado por Nokiacon el objetivo de crear un protocolo de encaminamiento para redes móviles ad-hoc,conocidas como MANETs. Es posible encontrar sus características de funcionamientoen el RFC-3561. El objetivo principal es conseguir un protocolo capaz de adaptarserápidamente a los cambios que se puedan producir en la red, ya sea por fallos en algúnnodo o cambios en la topología debido a movilidad, además de conseguir un overheady necesidades de procesamiento reducidas.

El protocolo AODV tiene una estructura de red llamada flat-based, todos los nodosjuegan el mismo rol en la red, reactivo, debido a que las rutas se crean en el momentoen el que son necesarias, y no es multipath, lo que significa que se crea una única rutadesde un origen concreto hasta el destino deseado.

El AODV utiliza tres tipos diferentes de mensajes de control para conseguir enrutarcorrectamente a través de la red: los RREQ (Route Request), los RREP (Route Reply)y los RERR (Route Error).

Cada uno de los nodos de la red dispone de una tabla de rutas con cada uno de losdestinos conocidos por el nodo.

33

5.1.6. Protocolos de transporte

En este apartado se presenta una descripción de los protocolos de transporte em-pleados en nuestra red de sensores: TCP y UDP.

5.1.6.1. TCP

TCP (RFC-793) es un protocolo orientado a conexión. Esto quiere decir que TCPmantiene información del estado de cada cadena de datos de usuario que circula porél. Es responsable de la transferencia de datos entre extremos por la red o redes hastala aplicación de usuario receptora, así como de la transferencia fiable de cada uno delos caracteres que recibe del nivel superior correspondiente.

Cada octeto transmitido lleva asignado un número de secuencia. El módulo TCPreceptor utiliza una rutina de checksum para comprobar la posible existencia de dañosen los datos producidos en el proceso de transmisión. Si son aceptables, se envía unaaceptación positiva (ACK) al módulo TCP remitente. En cambio, si los datos han resul-tado dañados, el receptor los descarta y utiliza un número de secuencia para informaral remitente del problema. TCP también emplea temporizadores para garantizar queno transcurre un lapso de tiempo demasiado grande antes de la transmisión de acep-taciones desde el nodo receptor y/o de la transmisión de datos desde el nodo transmisor.

TCP recibe datos de un protocolo de nivel superior de forma orientada a cadenas,es decir, se envían caracteres separados y no bloques, tramas, datagramas, etc. Losdatos son enviados byte a byte ,y cuando llegan al nivel TCP, los bytes son agrupadospara formar segmentos. Dichos segmentos se transfieren a IP para su transmisión.

TCP, también comprueba la duplicidad de los datos, además de descartar los datosredundantes que puedan aparecer. Además soporta el concepto de función push. Estafunción se utiliza cuando una aplicación desea asegurarse de que todos los datos quehan pasado al nivel inferior se han transmitido.

TCP emplea un esquema de aceptación inclusiva. El número de aceptación aceptatodos los octetos hasta e incluyendo el del número de aceptación menos uno. El móduloTCP receptor se ocupa también de controlar el flujo de los datos del transmisor, lo quees muy útil para evitar el desbordamiento de los dispositivos de almacenamiento yla saturación de la máquina receptora. La idea que utiliza TCP se basa en enviar aldispositivo transmisor un valor de "ventana". Se permite que el transmisor envíe unnúmero máximo de bytes igual al valor de su ventana. Cuando se ha llegado a esevalor, la ventana se cierra y el transmisor debe interrumpir el envío de datos.

34

TCP proporciona transmisión en modo duplex integral entre las entidades que secomunican, así la transmisión se puede efectuar en ambos sentidos sin necesidad deesperar la señal de indicación de cambio de sentido. Aparte de todo esto, también per-mite especificar niveles de seguridad y prioridades de las conexiones.

Como características básicas de este protocolo destacamos:

Permite establecer conexiones de transporte entre puertos de diferentes sistemas.

Establecimiento de conexión mediante protocolo de ida - vuelta - ida.

Control de flujo mediante ventana deslizante.

Separa datos de capas superiores y fragmenta en unidades de 64 Kbytes comomáximo denominadas segmentos.

Utiliza temporizadores y retransmisiones.

Numeración de bytes por offset.

5.1.6.2. UDP

UDP (RFC-768) es un protocolo de transporte no orientado a conexión que pro-porciona un servicio de "datagramas de usuario", que se caracteriza por no incluirmecanismos que eviten la perdida de mensajes, es decir , no ofrece fiabilidad. Lo queimplica que las aplicaciones que lo utilicen deben responsabilizarse de este tipo de pro-blema.

UDP proporciona un servicio con baja sobrecarga de cabecera para protocolos deaplicación, que no necesiten o no puedan usar los servicios orientados a conexión deTCP.

UDP es frecuentemente usado en aplicaciones que hacen un uso intensivo de broad-cast y multicast, así como aplicaciones que necesitan tiempos cortos para la obtenciónde información y peticiones.

Como características básicas de este protocolo destacamos:

Permite que los usuarios puedan transmitir mensajes sin establecimiento de co-nexión y con una sobrecarga de cabecera muy baja, pero sin garantía de entregao de secuenciado.

Transporta Unidades de datos entre puertos de sistemas.

35

Es apropiado para aplicaciones que implementan sus propios controles de errores,bien porque son muy específicos, o por la forma en la que tratan la información(DNS, streaming multimedia, multicast, etc).

UDP agrupa todos los datos que se le solicita enviar en un solo datagrama, yasea 8 bytes (sólo su cabecera) o 64Kbytes, sin importarle este tamaño o la posiblefragmentación en IP.

5.1.7. Estudio de resultados

Para el análisis y evaluación de la red, en el simulador, se han centrado todos losesfuerzos en el estudio del throughput (para TCP), la cantidad de paquetes perdidoso packet loss (para UDP), y el Packet Success Rate (para Lr-Wpan ó 802.15.4).

Throughput

El throughput es el promedio de paquetes de información entregados satisfactoriamentea través de la red por un canal de comunicación en concreto. En nuestras simulacioneslo hemos medido en kilo bits por segundo (kbps).

Se utilizará la siguiente fórmula para el cálculo del throughput en TCP:

Throughput = DatosTotalesRecibidos

T iempoTotal(5.2)

donde,

DatosTotalesRecibidos: Bits recibidos por la fuente desde el destino.

TiempoTotal: Tiempo transcurrido desde que la fuente envía el primer paquetehasta que la fuente recibe el ultimo reconocimiento (ACK).

36

Packet loss

El packet loss es la cantidad de paquetes que se pierden durante la comunicación entredos nodos. Para el cálculo del packet loss se utilizará la siguiente fórmula:

Packet loss = DatosTotalesTransmitidos − DatosTotalesRecibidos (5.3)

donde,

DatosTotalesTransmitidos: Bits transmitidos (paquetes UDP) en el dispositivoorigen (fuente).

DatosTotalesRecibidos: Bits recibidos (paquetes UDP) en el dispositivo destinoenviados por la fuente.

Packet Success Rate (PSR)

El PSR es la tasa de paquetes transmitidos a través del medio y que se han recibi-do con éxito por el nodo destinatario de los paquetes.

PSR = Paquetes recibidos

Paquetes enviados( %) (5.4)

37

5.2. Desarrollo del programaEn esta sección se describe en qué consiste el simulador de redes NS-3 y como se

han desarrollado los tres programas que simulan la red de sensores. Uno de los ficherosimplementa una red de sensores que simula tráfico TCP, otro fichero implementa unared de sensores que simula tráfico UDP, y en último lugar un fichero que implementauna pequeña red de sensores que simula tráfico Lr-Wpan.

5.2.1. Simulador de redes NS-3

El NS-3 es un simulador de redes de eventos discretos con un enfoque especial parasistemas basados en Internet. NS-3 es un programa de espacio de usuario que funcionaen sistemas basados en UNIX, Linux y Windows. En este caso ha sido instalado en laversión 12.04 de Ubuntu, y la versión utilizada del simulador ha sido la 3.19.

En NS-3 las librerías o los componentes para la simulación están escritos en C++y tiene soporte para permitir que los programas para la simulación sean escritos enPhyton. Para mayor detalle sobre el funcionamiento de NS-3 y sus principales clasesver el Anexo A.

5.2.2. Implementación de la red de sensores en NS-3

En este apartado presentamos las decisiones tomadas para implementar la red desensores en el simulador NS-3.

5.2.2.1. Topología

Para este proyecto se han empleado dos topologías:

1. TCP y UDP: consiste en un recinto cuadrangular de 150 metros cuadrados, en elcual los nodos se sitúan inicialmente en una posición aleatoria y a continuacióncomienzan a desplazarse por trayectorias igualmente aleatorias.

2. Lr-Wpan: consiste en un recinto de espacio indefinido en el cual se sitúan dosnodos a 1 metro de distancia que se irán separando hasta una longitud máximade 200 metros.

38

Escenarios TCP y UDP

Debido a las limitaciones del recinto solo se han simulado tres escenarios dependiendodel número de nodos definidos.

En esta simulación se ha querido hacer un profundo análisis centrándose en conocerel rendimiento de un nodo cuando se comunica con los demás y de cómo trabaja la redcon diferentes números de nodos involucrados en la prueba.

La simulación consistirá en la comunicación del 10% de nodos definidos en la redcon el nodo-servidor, que coincidirá con el nodo que se encuentre más centrado en elrecinto.

Escenario 1: para este escenario se definen en la red un total de 100 nodos. El10% de ellos (10 nodos) se comunicará con el nodo central. Como se puede ver enla Figura 5.5 los puntos rojos representan los nodos que hay en la red, y los ejesde ordenadas y abscisas nos indican las dimensiones aproximadas del recinto.

Figura 5.5: Escenario 100 nodos

39

Escenario 2: para este escenario se definen en la red un total de 25 nodos . El10% de ellos (3 nodos) se comunicará con el nodo central. En la Figura 5.6 sepuede ver la representación gráfica de este escenario.

Figura 5.6: Escenario 25 nodos

Escenario 3: para este escenario se definen en la red un total de 16 nodos. El10% de ellos (2 nodos) se comunicará con el nodo central. En la Figura 5.7 sepuede ver la representación gráfica de este escenario.

Figura 5.7: Escenario 16 nodos

40

Escenario Lr-Wpan

Debido a las limitaciones del repositorio Lr-Wpan, el cual se encuentra en desarro-llo, se ha simulado un solo escenario que consta de dos nodos.

En esta simulación se ha querido hacer un profundo análisis centrándose en conocerla tasa de paquetes entregados con éxito cuando los dos nodos en comunicación se vandistanciando.

El escenario de simulación (Figura 5.8) consistirá en dos nodos equidistantes deun metro, de los cuales el nodo situado a la derecha se irá separando del otro enincrementos de un metro, hasta alcanzar una distancia máxima de 200 metros. Estosdos nodos estarán constantemente transmitiéndose datos entre ellos.

Figura 5.8: Escenario Lr-Wpan

41

5.2.2.2. Modelo de pérdidas en la propagación

Uno de los parámetros más importantes cuando se investigan y se utilizan redesinalámbricas son las interferencias (como equipamientos eléctricos, otras redes ina-lámbricas, campos magnéticos, etc), y los obstáculos (como paredes, puertas, techos,personas moviéndose, etc) presentes en los entornos del mundo real. Debido a todasestas interferencias, la fuerza de la señal de transmisión decrece de diferente manera.

Para poder configurar el comportamiento de todas estas interferencias del medio,NS-3 tiene implementados diferentes modelos de propagación de pérdidas (ver Figura5.9). Revisaremos todos los disponibles y escogeremos los que mejor se adapten a nues-tros requisitos.

Figura 5.9: Modelos de pérdidas en la propagación disponibles en NS-3

42

Fixed Rss Loss Model: con este modelo se puede modelar la pérdida en la pro-pagación configurando la intensidad de la señal recibida (RSS, medida en dBm).Este modelo fue descartado porque no tiene en cuenta la distancia entre nodos.

Friis Propagation Loss Model: este modelo utiliza una ecuación que da laintensidad de señal recibida por cada antena dada la distancia entre antenas,cuando se conoce la potencia de emisión y en condiciones ideales. Este modelosería interesante para calcular la intensidad de la señal recibida.

Jakes Propagation Loss Model: el modelo Jakes Propagation Loss Modelpermite la configuración de algunos parámetros físicos como:

• El número de rayos utilizados por defecto para calcular los coeficientes depérdida de intensidad para un camino dado.

• El número de oscilaciones que utiliza por defecto para calcular el coeficientepara un rayo en concreto para un camino dado.

• La frecuencia Doppler en Hz.

• La distribución para escoger las fases iniciales.

Este modelo fue descartado porque en el caso que nos ocupa no se configuranestos parámetros.

Nakagami Propagation Loss Model: este modelo es utilizado para descri-bir las propiedades estadísticas de un canal inalámbrico, que desde que la señalse propaga, se ve afectada por tres fenómenos estadísticamente independientes:pérdida determinística en el trayecto, decremento log-normal y rápido desvane-cimiento multi-trayecto.

Este modelo fue descartado porque tomaba como referencia dos distancias y notenía en cuenta la intensidad de la señal recibida.

Random Propagation Loss Model: este modelo es utilizado cuando un pa-rámetro se introduce dentro de un rango con valores específicos, por ejemplo ladistancia, intensidad de señal, etc. Este modelo ha sido utilizado para introducirla variación de la intensidad de señal recibida.

43

Log Distance Propagation Loss Model: este modelo calcula la intensidadde señal recibida por cada antena, utilizando el modelo log-distance. Para calcularla intensidad de la señal se utiliza la siguiente ecuación:

L = L0 + 10 · n · log10

(d

d0

)(5.5)

Donde:

• L0: Distancia de referencia (m)

• n: Exponente de pérdida en la trayectoria

• d: Distancia entre las antenas (m)

• d0: Distancia de referencia de la antena (m)

• L: Pérdida en la trayectoria (dB)

Three Log Distance Propagation Loss Model: este modelo es similar almodelo Log Distance Propagation Loss, pero este modelo utiliza tres campos pa-ra la distancia en lugar de uno. Para nuestro caso solo es necesario un campopara la distancia, por este motivo se decidió que es mejor utilizar el modelo LogDistance Propagation Loss Model.

Modelo de pérdidas en la propagación utilizado

Para la adaptación de un modelo de pérdidas en la propagación con los modelos dis-ponibles en NS-3, se ha utilizado una combinación de dos de ellos para implementarlas interferencias que se obtendrían en un simulación real:

Log Distance Propagation Loss Model.

Random Propagation Loss Model.

44

5.2.2.3. Implementación red con tráfico TCP y UDP

En esta sección se describe cómo se ha desarrollado el programa para simular la redde sensores, describiendo que clases se han utilizado.

En el Anexo D se encuentra el código del programa. Para saber como ejecutarlover el Anexo B. Y para ver la información asociada al código (atributos, variables ymétodos que tiene) ver el Anexo C.

Nodos

En la simulación se ha comenzado creando nodos utilizando la clase NodeContainer, yse ha creado un objeto con 100, 25 y 16 nodos dependiendo del escenario a simular.

Una vez creados los nodos, se procede a configurar los parámetros de la tarjetade red inalámbrica, para ello se ha utilizado un objeto de la clase NetDeviceContai-ner y para configurar la interfaces de cada nodo se ha utilizado un objeto de la claseIpv4InterfaceContainer puesto que se utiliza el protocolo de Internet versión 4. Unavez configurados todos los parámetros de cada objeto, se ha establecido la posiciónde todos los nodos con la clase MobilityHelper, y se les ha implementado movimientocon el algoritmo RandomWalk2dMobilityModel. Y en último lugar se han instalado losdispositivos y las interfaces en todos los nodos.

Figura 5.10: Visualización del algoritmo RandomWalk2MobilityModel en el escenariode 16 nodos

45

Dispositivos

En los dispositivos se ha configurado la capa de Control de Acceso al Medio (MAC)utilizando la clase NqosWifiMacHelper y estableciendo como protocolo de enrutadoad-hoc. Se ha utilizado la clase YansWifiChannelHelper para configurar el modelo depérdidas en la propagación descrito anteriormente, y para ajustar algunos parámetrosfísicos como la ganancia de la transmisión, la energía de transmisión, el canal de trans-misión, etc, se ha utilizado la clase YansWifiPhyHelper.

Interfaces

Se ha utilizado la clase InternetStackHelper para instalar la torre de protocolos de In-ternet, para asignar direcciones IP a cada interface hemos utilizado Ipv4AddressHelper.Para configurar el encaminamiento de los nodos se ha utilizado AodvHelper.

Aplicaciones

Para instalar las aplicaciones en los nodos se ha utilizado ApplicationContainer y paraenviar tráfico entre los nodos PacketSinkHekper, instalando un generador de tráficoen el cliente con la clase TcpSocketFactory, para el fichero en el que se genera tráfi-co TCP, y con la clase UdpSocketFactory, para el fichero en el que se genera tráfico UDP.

Ejecuciones aleatorias

Para poder realizar simulaciones diferentes, se ha utilizado la clase seedManager paragenerar valores aleatorios cambiando la semilla de generación, introduciéndola comoparámetro en el programa.

La semilla controla la aleatoriedad de las simulaciones, si la misma semilla alea-toria es usada en la misma situación, el simulador produce exactamente los mismosresultados. Una semilla aleatoria distinta produce resultados diferentes.

46

5.2.2.4. Implementación red con tráfico Lr-Wpan

En esta sección se describe cómo se ha desarrollado el programa para simular la redde sensores que implementa tráfico Lr-Wpan (IEEE 802.15.4), describiendo las clasesque se han utilizado.

En el Anexo D se encuentra el código del programa. Para saber como ejecutarlover el Anexo B. Y para ver la información asociada al código (atributos, variables ymétodos que tiene) ver el Anexo C.

Cabe destacar que el repositorio de Lr-Wpan está en desarrollo en NS-3 y por tantosus funciones están limitadas. Por lo cual, no ha sido posible implementar ciertas fun-ciones que si se han implementado en los programas que simulan tráfico TCP y UDP(por ejemplo, asignar direcciones IP a los dispositivos).

Nodos

En la simulación se han creado dos nodos utilizando la clase Node. Una vez creadoslos dos nodos, se procede a configurar los parámetros de la tarjeta de red inalámbrica,para ello se crean dos dispositivos Lr-Wpan con la clase LrWpanNetDevice. A estosdispositivos creados se les asigna direcciones MAC de 16 bits, y finalmente estos dis-positivos son asignados a los nodos creados al inicio.

Canal y modelo de pérdidas

Se ha utilizado la clase SingleModelSpectrumChannel para crear el canal de comu-nicación. Este canal es asignado a los dispositivos creados utilizando la función Set-Channel(). Además, a estos dispositivos se les asigna una posición dentro del canal conla clase ConstantPositionMobilityModel.

Al canal creado se le añade el modelo de pérdidas Log Distance Propagation LossModel utilizando para ello la clase LogDistancePropagationLossModel.

47

5.3. SimulacionesUna vez desarrollado el programa, se han realizado tres tipos de simulaciones:

1. TCP: para el fichero que implementa tráfico TCP se han simulado los tres esce-narios descritos en la sección 5.2.2.1, para los cuales se ha decidido que el 10% delos nodos que se encuentren en la red (elegidos de 8 en 8, es decir, los nodos 1, 9,17,...) transmitan al nodo que se encuentre más centrado en el recinto definido.En este fichero se ha analizado el throughput (ver sección 5.1.7) obtenido en lared de sensores.

2. UDP: para el fichero que implementa tráfico UDP se ha realizado la misma simu-lación que en el apartado anterior, en cambio, para este fichero se han analizadolos packets loss (ver sección 5.1.7).

3. Lr-Wpan: para el fichero que implementa tráfico Lr-Wpan se ha simulado elescenario descrito en la sección 5.2.2.1, para el cual se definen dos nodos que seencuentran constantemente transmitiéndose paquetes LrWpanMAC (con paque-tes de datos definidos en el repositorio Lr-Wpan sin contenido útil), a la vez queva aumentando la distancia entre ellos. En este fichero se han realizado X simula-ciones aumentando para cada una de ellas el tamaño de los paquetes transmitidoscon el fin de analizar el Packet Success Rate (ver sección 5.1.7) obtenido en lared de sensores.

Para llevar a cabo la simulación de los ficheros TCP y UDP mencionados, se ha desa-rrollado un script que permite simular todos los escenarios de los dos ficheros automáti-camente, realizando 30 simulaciones de cada escenario y cambiando en cada simulaciónla semilla para obtener diferentes resultados, de manera que la media obtenida se apro-xime a un valor lo más real posible.

En el Anexo B se ha detallado como ejecutar el script que simula automáticamentelos dos ficheros, el que implementa el protocolo TCP y el del protocolo UDP.

48

5.3.1. Resultados de las simulaciones TCP y UDP

Los resultados de la simulación se han obtenido después de la ejecución de cadaprograma, gracias a la generación de hojas de cálculo (archivos “.xls” ), los cuales al-macenan los resultados de cada ejecución.

Una vez ejecutado el script, dará como resultado una arborescencia de carpetas conla siguiente estructura:

Figura 5.11: Diagrama de carpetas

En último lugar, para obtener el resultado final se hace una media de los resultadosobtenidos en las hojas de calculo contenidas en cada una de las carpetas anteriormentevisualizadas.

49

5.3.1.1. Resultados TCP

En la Tabla 5.3 se detallan los resultados obtenidos, medidos en kbps, para cadadistancia en cada una de las 30 simulaciones realizadas.

Nº de simulación 16 nodos 25 nodos 100 nodos1 333,6685 306,5054 557,62822 383,5400 252,4060 54,52493 356,3622 243,0423 569,07734 359,4299 359,2643 59,53415 347,0844 334,7572 247,79966 359,4299 359,3633 115,50027 285,2474 335,1241 528,39138 359,4195 322,2815 573,35629 359,4195 359,3831 149,939610 357,2008 363,7725 131,326811 359,2009 339,8560 311,116912 333,9609 359,4039 575,985813 354,7497 355,0307 63,820514 359,4143 359,4039 47,463115 359,4195 359,3987 578,679316 357,2008 359,4143 119,333017 359,4143 359,4143 127,274618 0,0260 135,2736 578,566519 359,0413 359,4143 552,016720 359,4195 359,4299 54,388021 325,7425 344,0376 154,412022 313,8249 357,1695 565,934523 315,4891 359,4039 468,286424 359,4039 331,5136 40,277825 359,4143 341,9839 90,329126 294,6921 285,6353 527,802027 348,0872 267,6508 211,240928 327,4217 359,3727 483,375729 223,3672 226,3021 115,940430 349,8690 353,0828 156,5186

Media: 330,665 326,936 293,661

Tabla 5.3: Resultados de las simulaciones TCP

Se puede ver en la Figura 5.12 como decrece el throughput total generado en toda lared al aumentar el número de nodos en la red, esto es debido a que al haber un mayornúmero de nodos se genera más tráfico en la red y por lo tanto hay más probabilida-des de que se pierda un paquete, ya sea por colisiones o por pérdidas de propagaciónproducidas en el medio de comunicación.

50

Figura 5.12: Gráfica con los resultados de la simulación TCP

51

5.3.1.2. Resultados UDP

En la Tabla 5.4 se detallan los resultados obtenidos, medidos en el número depaquetes perdidos (packet loss), para cada distancia en cada una de las 30 simulacionesrealizadas.

Nº de simulación 16 nodos 25 nodos 100 nodos1 2.220 4.469 7.9682 791 8.538 63.3443 6 5.672 4.5104 2 1 38.4825 48 353 29.8606 493 7 35.6157 6.984 945 92.3788 3 2.883 38.4729 4 5 30.74010 0 921 58.84111 3 3.680 27.06112 777 4 63.24613 20 888 39.32914 5 5 34.52515 3 6 47.60016 7 5 49.01917 4 4 14.73418 7.382 11.867 39.23619 7 5 40.07220 2 3 29.67421 2.190 307 31.24022 3.351 0 49.54523 2.443 6 35.88824 0 1.725 32.04025 4 842 38.17226 4.405 4.301 70.05427 659 8.129 50.32428 5.155 5 41.62829 9.080 4.488 39.24130 1.872 73 23.442

Media: 1.597 2.005 39.876

Tabla 5.4: Resultados de las simulaciones UDP

Se puede ver en la Figura 5.13 como aumenta el packet loss al aumentar el númerode nodos en la red. Esto es debido a que, como se explico en la sección 5.2.2.1, de-pendiendo del escenario escogido transmite una mayor o menor cantidad de nodos, enconcreto, el 10% de los nodos que haya en la red.

52

Podemos concluir diciendo que la cantidad de paquetes perdidos es proporcionala la tasa de tráfico que haya en la red (número de nodos transmitiendo información),puesto que contra más tráfico haya más probabilidades hay de que se pierda un pa-quete, ya sea por colisiones o por pérdidas de propagación producidas en el medio decomunicación.

Figura 5.13: Gráfica con los resultados de la simulación UDP

53

5.3.2. Resultados de las simulaciones Lr-Wpan

Los resultados de la simulación se han obtenido después de la ejecución del pro-grama, gracias a la generación de una gráficas comparativas, las cuales almacenan losresultados de cada simulación y que en el Anexo B se detalla como han de generarse.

A continuación, presentamos los resultados obtenidos comparando el Packet SuccessRate en función de la distancia de separación de los nodos. Este programa produce unarchivo de GNUplot que traza la tasa de paquetes satisfactorios en función de la distan-cia para los modelos 802.15.4, asumiendo el modelo de pérdidas Log Distance Propa-gation Loss Model , el modelo de error O-QPSK 2,4 GHz, una potencia de transmisiónpor defecto de 0 dBm, y un tamaño de paquete variable en función de la simulaciónrealizada de la carga útil 802.15.4. Para este programa se han realizado 5 simulacionesen las cuales se ha ido aumentando el tamaño del paquete transmitido entre los nodos.

Se puede ver en las Figuras 5.14, 5.15, 5.16 y 5.17, como el alcance de los nodosdisminuye a medida que se va aumentando el tamaño del paquete, esto es debido a queal ser el tamaño del payload más grande la probabilidad de pérdidas por propagaciónserá mayor, el tiempo de transmisión se incrementa. Y al ser fijos los límites de po-tencia de transmisión y recepción de los nodos, a mayor distancia mayor probabilidadhay de que no se reciba el paquete. Aunque, como se ven en las gráficas las distanciasmáximas de transmisión son muy parecidas porque la diferencia entre la máxima y lamínima longitud de las tramas son muy pequeñas.

Finalmente, en la Figura 5.18 se observa que al sobrepasarse el tamaño máximoestablecido de la trama 802.15.4 (ver sección 5.1.4.2), ésta no puede recibirse en el re-ceptor adecuadamente, independientemente de la distancia entre la fuente y el destino.

54

Figura 5.14: Simulación con un tamaño de paquete de 20 bytes

Figura 5.15: Simulación con un tamaño de paquete de 50 bytes

Figura 5.16: Simulación con un tamaño de paquete de 100 bytes

55

Figura 5.17: Simulación con un tamaño de paquete de 114 bytes

Figura 5.18: Simulación con un tamaño de paquete de 115 bytes

56

6

Conclusiones

Este proyecto se ha realizado con el objetivo de analizar, implementar y simularunas redes de sensores mediante el simulador de redes network simulator en su versiónnúmero 3. Para llegar a este objetivo se ha tenido que profundizar en el conocimientode NS-3, y realizar varias simulaciones que nos permitieran analizar y verificar el com-portamiento y funcionamiento de las redes de sensores.

Se ha comprobado en las simulaciones de TCP y UDP, que las propiedades de unared Manet son muy dinámicas y en consecuencia no se pueden extraer conclusionesgenerales, ya que dependerán del tipo de escenario, del número de nodos, del modelode movilidad, del protocolo de encaminamiento, etc.

En la versión actual del simulador NS-3 la implementación de los protocolos Lr-Wpan y 6LoWpan se encuentran en un estado muy inicial y todavía no cuentan con elsuficiente desarrollo para poder ver el potencial de estos protocolos.

Todavía no está implementada la necesidad de fragmentar los paquetes de nivelessuperiores sobre la capa MAC del protocolo Lr-Wpan que está muy limitada por eltamaño máximo de la MPDU (ver sección 5.1.4.2).

Como líneas futuras de desarrollo para mejorar el análisis de las redes de sensoresmediante el simulador NS-3, se proponen las siguientes tareas:

Cambiar la topología del escenario Lr-Wpan a una topología en estrella y aumen-tar el número de nodos definidos en la red.

Para los escenarios TCP y UDP, simular otros modelos de movilidad.

57

Bibliografía

[1] GNU. La definición de software libre. http://www.gnu.org/philosophy/free-sw.es.html

[2] GloMoSim. http://pcl.cs.ucla.edu/projects/glomosim/

[3] J-Sim. http://sites.google.com/site/jsimofficial/

[4] GTNetS. http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/

[5] SSFNet. http://www.ssfnet.org/homePage.html

[6] NCTU network simulator. http://nsl10.csie.nctu.edu.tw/

[7] OMNeT++. http://www.omnetpp.org/

[8] OMNEST. http://www.omnest.com

[9] Nam: Network Animator. http://www.isi.edu/nsnam/nam/

[10] Extended Nam Editor. http://www.grid.unina.it/grid/ExtendedNamEditor/index.html

[11] NS-2 workbench project. http://www.mnlab.cs.depaul.edu/projects/nsbench/

[12] Nsg2. http://sites.google.com/site/pengjungwu/nsg

[13] Trace Graph - NS-2 trace files analyser. http://www.tracegraph.com

[14] NS-2 Trace Analyzer. http://sourceforge.net/projects/trace-analyzer/

[15] Network Simulator 3. NS-3. http://www.nsnam.org/

[16] Publicaciones en IEEE del NS-3. http://www.nsnam.org/wiki/index.php/Papers

[17] Instalación del NS-3. http://www.nsnam.org/wiki/index.php/Installation

[18] IEEE 802.15.4. http://www.ietf.org/rfc/rfc4944.txt

[19] GNUplot. http://www.gnuplot.info/

58

[20] Transceptor MRF24WG0MA/MB.http://ww1.microchip.com/downloads/en/DeviceDoc/61170B.pdf

Última vez visitados todas las direcciones: 13 de junio de 2014.

59

Anexo A

Simulador NS-3

En el presente anexo se describe el alcance de NS-3, los mecanismos y protocolosdisponibles, los principales casos de uso y los objetos más utilizados.

A.1. Alcance de NS-3NS-3 esta principalmente dirigido a la simulación de redes basadas en IPv4 e IPv6,

aunque también soporta otras arquitecturas como redes de sensores. NS-3 puede sermodificado y ampliado por los usuarios. Los usuarios tienen a su disposición programasde ejemplo que permiten iniciarse en el simulador, para que una vez lo conozcan,escriban nuevos programas, modifiquen los existentes, o creen nuevos modelos queayuden a ampliar las funcionalidades del simulador.

A.2. Mecanismos y protocolos soportadosNS-3 posee una implementación modular que contiene diferentes librerías que dan

soporte al simulador (también es posible que los usuarios desarrollen sus propias libre-rías). Nombramos las más importantes:

Core library: ofrece soporte para aspectos genéricos del simulador como gene-ración de números aleatorios, utilizar punteros inteligentes, callbacks u objetos dedepuración.

Simulator library: define los parámetros requeridos para la ejecución de unasimulación, como el tiempo de simulación, objetos, planificadores y eventos.

Common library: define objetos independientes como paquetes genéricos.

Node library: define las clases abstractas de objetos fundamentales del simula-dor como nodos, canales y dispositivos de la red.

60

Internet-node: define los modelos relacionados con Internet, por ejemplo, losprotocolos TCP y UDP.

La implementación modular, permite la compilación individual de pequeñas partes, demanera que a la hora de compilar solo se compile la del programa que ha cambiado.Los programas de ejecución de NS-3 pueden ser construidos estática o dinámicamentevinculados a las librerías.

NS-3 ofrece soporte para:

Construcción de redes virtuales (nodos, canales, aplicaciones), planificadores deeventos, generadores de topologías, temporizadores, variables aleatorias y otrotipo de objetos para la simulación de sistemas de eventos discretos basados enInternet y en otros tipos de redes.

Simular procesos que emiten y consumen paquetes de red reales.

Simular múltiples procesos en diferentes máquinas.

Animar las redes simuladas.

Detección, registro, cálculo y estadísticas de la simulación.

A.3. Casos de usoPara utilizar NS-3 es necesario conocer como está diseñado. Para ello, en esta sec-

ción se describen modelos de uso y las tendencias a la hora de simular de la comunidadde investigación de redes.

Ampliación del simulador

Los usuarios están interesados en ampliar el simulador escribiendo o modificando losprogramas de simulación. Para llevarlo a cabo, NS-3 utiliza el diseño orientado a ob-jetos con clases polimórficas que permiten a los usuarios modificar los aspectos quenecesite. Para facilitar la anexión de nuevos modelos, NS-3 utiliza una arquitecturabasada en componentes que permite la adición de los nuevos modelos en tiempo decompilación o de ejecución sin necesidad de modificar los modelos base de NS-3.

61

Configuración

NS-3 permite a los usuarios redefinir valores y tipos de clases sin tener que recom-pilar el simulador entero. En la base de datos vienen integrados valores por defecto quepuede ser modificados utilizando la línea de comandos.

Seguimiento

NS-3 cuenta con un sistema de devolución de llamada basado en el seguimiento dela diferencia entre la fuente y el destino. Las trazas de los paquetes están disponiblesen el formato “pcap” y pueden ser analizadas utilizando analizadores de tráfico comopor ejemplo Wireshark o Tcpdump.

Integración del software

Ns-3 está orientado a reutilizar software existente, por ejemplo, el uso de programas yotras aplicaciones utilizadas en NS-2. Por ello, el diseño de NS-3 se realizó basándoseen técnicas de encapsulamiento, separando la aplicación de la implementación.

El diseño de NS-3 facilita la integración entre la simulación y los experimentos, per-mitiendo la simulación conjunta de código simulado y aplicaciones reales, mejorandoasí las implementaciones del mundo real.

A.4. Objetos clave para la simulaciónEn este apartado trataremos los objetos primarios para realizar una simulación ba-

sada en enviar y recibir paquetes entre nodos en el simulador.

En la Figura A.1 se puede observar gráficamente la relación entre los objetos.

62

Figura A.1: Arquitectura de los objetos clave de una simulación en NS-3

Node

Node es la clase principal de NS-3. Esta clase puede ser instanciada (no es una claseabstracta).

El diseño de esta clase, utiliza patrones de software para permitir la encapsulaciónde Applications y NetDevices (clases explicadas posteriormente), y así poder disponerde la implementación de otras funciones, como por ejemplo, la implementación del pro-tocolo de transporte TCP/IP.

NetDevice y Channel

La clase NetDevice representa el interfaz físico de un nodo (por ejemplo, un inter-faz Ethernet).

La clase Channel implementa el camino lógico por el cual fluye la información, de-finiendo las características del mismo.

Packet

Los objetos de la clase Packet, contienen un buffer de bytes. El contenido de estebuffer se espera que corresponda byte a byte con el contenido de un paquete de unared real, con todas las cabeceras de los protocolos y toda la información que contiene.

El diseño de esta clase fue orientado por unos cuantos casos de uso:

Evitar cambiar el núcleo del simulador para introducir nuevos tipos de cabeceras.

Maximizar la manera de integrar la realidad con el código de los sistemas.

63

Implementar un soporte fácil para la fragmentación, desfragmentación y la con-catenación, que son muy importantes en sistemas inalámbricos. Tiene que sermuy natural la implementación del diseño del paquete para que sea posible frag-mentar el paquete en múltiples fragmentos, para poder ensamblarlos a posteriorifácilmente.

Hacer que la gestión de memoria del objeto sea eficiente.

Permitir tanto a las aplicaciones simuladas como a las aplicaciones reales la uti-lización del mismo paquete.

Applications

Applications son procesos definidos por el usuario, para generar tráfico y poder mandardatos a través de las redes simuladas. NS-3 provee de un framework para desarrollardiferentes tipos de aplicaciones, que tienen diferentes patrones de tráfico.

Para poner en funcionamiento una Application, basta con crearla y asociarla a unobjeto de la clase Node, y la aplicación mandará tráfico a otros nodos a través desockets.

64

Anexo B

Manual de usuario

En el presente anexo se detalla como ha de instalarse el simulador NS-3 [17], inclu-yendo el software necesario para ello, así como, la manera en la que ha de utilizarse elsimulador para la ejecución de los programas descritos en el Anexo D.

B.1. Instalación de NS-3

B.1.1. Requisitos previos

El núcleo de NS-3 requiere una versión 3.4 ó superior del gcc/g++, y la versión 2.4o superior de Phyton. Las diferentes opciones de NS-3 necesitan soporte adicional, porello, proporcionamos una lista con los paquetes necesarios (para sistemas Debian/U-buntu). Cabe destacar, que la siguiente lista de paquetes es la requerida para Ubuntu12.04, para otras versiones u otros sistemas basados en Debian pueden variar ligera-mente:

Requisitos mínimos para C++: este es el conjunto mínimo de paquetes necesariospara ejecutar NS-3 desde un paquete de liberación.

sudo apt -get install gcc g++

Requisitos mínimos para Python: este es el conjunto mínimo de paquetes nece-sarios para trabajar con enlaces de Python desde un paquete publicado.

sudo apt -get install python python -dev

65

Mercurial, es necesario para trabajar con los repositorios de desarrollo ns-3.

sudo apt -get install mercurial

Ejecución de enlaces de Python desde el árbol de desarrollo de ns-3 (ns-3-dev)requiere bazaar.

sudo apt -get install bzr

Depuración.

sudo apt -get install gdb valgrind

GNU Scientific Library (GSL), soporte para modelos de error WiFi más precisos.

sudo apt -get install gsl -bin libgsl0 -dev libgsl0ldbl

El Network Simulation Cradle (nsc) requiere del analizador léxico flex, y el gene-rador de análisis bison.

sudo apt -get install bison flex libfl -dev

Tcpdump, para leer trazas de paquetes pcap.

sudo apt -get install tcpdump

Base de datos de apoyo para las estadísticas framework.

sudo apt -get install sqlite sqlite3 -dev libsqlite3

XML, versión del almacén de configuración (requiere la versión 2.7 ó mayor delibxml2.

sudo apt -get install libxml2 libxml2 -dev

66

GTK, para la configuración del sistema.

sudo apt -get install libgtk2 .0-0 libgtk2 .0- dev

Para experimentar con las máquinas virtuales y ns-3.

sudo apt -get install vtun lxc

Soporte para utils/check-style.py estilo de código de programa de comprobación.

sudo apt -get install uncrustify

Doxygen y LATEX, para generar la documentación.

sudo apt -get install doxygen graphviz imagemagick

sudo apt -get install texlive texlive -extra -utils texlive -

latex -extra

El manual y tutorial de ns-3 está escrito en reStructuredText para Sphinx (doc /tutorial, doc / manual, doc / modelos), y las figuras típicamente en dia.

sudo apt -get install python - sphinx dia

Herramienta gráfica PyViz que permite la visualización gráfica del escenario desimulación.

sudo apt -get install python - pygraphviz python -kiwi python -

pygoocanvas libgoocanvas -dev

Apoyo al módulo OpenFlow (requiere algunas bibliotecas Boost).

sudo apt -get install libboost -signals -dev libboost -

filesystem -dev

67

B.1.2. Descarga e instalación de NS-3 usando Mercurial

Mercurial es un sistema de control de versiones multiplataforma, para desarrolla-dores de software. Está implementado principalmente haciendo uso del lenguaje deprogramación Python, pero incluye una implementación binaria de diff escrita en C.Mercurial es, sobre todo, un programa para la línea de comandos. Todas las operacionesde Mercurial se invocan como opciones dadas a su programa motor, hg (cuyo nombrehace referencia al símbolo químico del mercurio). Para el acceso a repositorios median-te red, Mercurial usa un protocolo eficiente, basado en HTTP, que persigue reducir eltamaño de los datos a transferir, así como la proliferación de peticiones y conexionesnuevas.

Una vez hemos visto que es y para que se utiliza Mercurial, vamos a proceder adescargar el simulador NS-3 ayudándonos de esta herramienta. Una práctica comúnes crear un directorio llamado repos en el directorio principal bajo el cual se puedemantener los repositorios locales de Mercurial. Adoptando este método obtendremosuna copia de ns-3-allinone escribiendo las siguientes sentencias en el shell de Linux:

mkdir repos

cd repos

hg clone http:// code.nsnam.org/ns -3- allinone

A continuación, vamos a descargar las opciones más comunes utilizadas en NS-3,para ello nos vamos a la carpeta ns-3-allinone introduciendo en el shell:

cd ns -3- allinone

./ download .py -n ns -3- dev

B.1.3. Construcción del ns-3 con build.py

Entramos en el directorio repos/ns-3-allinone y, procedemos a construir la distri-bución de NS-3 introduciendo en el shell:

./ build.py

Una vez que el proyecto se ha construido correctamente no se utilizarán los scriptsde ns-3-allinone. Ahora vamos a interactuar directamente con el Waf. Para interactuarcon el Waf debemos estar en el directorio repos/ns-3-allinone/ns-3-dev.

68

B.1.4. Configuración con Waf

Ingresamos en el directorio repos/ns-3-allinone/ns-3-dev:

cd repos/ns -3- allinone /ns -3- dev

Configuramos:

./ waf configure

Compilamos las opciones:

./ waf

B.1.5. Pruebas

Todas estas ejecuciones que se van a describir a continuación deben realizarse en eldirectorio repos/ns-3-allinone/ns-3-dev:

Verificar el proceso de instalación:

./ waf check

Para poder realizar tests y ejecutar los ejemplos incluidos en el simulador, hayque habilitarlos:

./ waf configure --enable -tests --enable - examples

Finalmente, ejecutamos el test para comprobar que el programa se ha instaladocorrectamente:

./ test.py

69

B.2. Modo de uso

B.2.1. Parámetros de entrada de los programas TCP y UDP

Tanto el fichero pfc_tcp.cc, como el fichero pfc_udp.cc tienen los mismos paráme-tros de entrada. Como se ha comentado en la sección 5.3 del capítulo 5 de esta memoria,se ha desarrollado un script que ejecuta de manera automática estos dos ficheros, peroen dicho script se pueden configurar dichos parámetros para hacer que la simulación seajuste a especificaciones que se desee.

Estos parámetros son:

nodes: número de nodos que se desea definir en la red de simulación.

time: tiempo que se desea emplear para la simulación.

channel: frecuencia del canal empleada para la simulación.

pcap: indica si se desea exportar la captura de los paquetes en ficheros de formato“.pcap”.

seed: número de semilla empleado para la simulación.

client: número de nodo escogido como cliente en la simulación.

server : número de nodo escogido como servidor en la simulación.

printroutes: indica si se desea exportar la tabla de rutas de los nodos en ficherosde texto plano.

distance: distancia de separación entre los nodos que conforman la red de simu-lación.

B.2.1.1. Ejecución de la simulación

Para efectuar la simulación debemos colocar los tres ficheros (pfc_tcp.cc, pfc_udp.ccy pfcscript.sh) en el directorio /repos/ns-3-allinone/ns-3-dev/scratch.

Una vez colocados estos tres ficheros en dicho directorio, ejecutamos el script ha-ciendo doble clic. De las 4 opciones que se nos proporcionan (ver figura B.1), escogemosEjecutar en un terminal. De esta manera se abriría un terminal en el cual se ejecu-taría la simulación, desde el cual se nos pregunta por el número de simulaciones quese desean efectuar (ver figura B.2). Para este proyecto se han realizado 30 simulaciones.

70

Figura B.1: Ejecución del script

Figura B.2: Numero de simulaciones a efectuar

Cabe destacar que también se pueden ejecutar los ficheros pfc_tcp.cc y pfc_udp.ccde manera independiente, para ello, realizamos los siguientes pasos (ver figura B.3):

1. Abrimos un terminal.

2. Nos colocamos en el directorio /repos/ns-3-allinone/ns-3-dev introduciendo:

cd repos/ns -3- allinone /ns -3- dev

3. Una vez en el directorio ejecutamos el fichero que deseemos introduciendo (elnombre del fichero va sin comillas):

./ waf --run pfc_tcp

./ waf --run pfc_udp

71

4. Si se desease introducir los parámetros comentados en el apartado anterior intro-ducimos:

./ waf --run " pfc_tcp --pcap =0 -channel =6 time =60"

./ waf --run " pfc_tcp --pcap =0 -channel =6 time =60"

Para estos casos, se ha ejecutado la simulación indicando que no deseamos expor-tar la captura de los paquetes en ficheros “.pcap”, que seleccionamos el canal 6,y que deseamos efectuar la simulación empleando 60 segundos. En nuestro casosolo hemos introducido 3 parámetros pero se pueden introducir todos los men-cionados en el apartado anterior.

Figura B.3: Ejemplo ejecución del fichero pfc_tcp.cc

72

B.2.2. Parámetros de entrada del programa Lr-Wpan

El fichero lr-wpan.cc consta de los siguientes parámetros de entrada:

txPower : potencia de transmisión de los nodos medidos en dBm.

packetSize: indica el tamaño de los paquetes transmitidos entre los nodos en lasimulación.

channelNumber : frecuencia del canal empleada para la simulación.

pcap: indica si se desea exportar la captura de los paquetes en ficheros de formato“.pcap”.

B.2.2.1. Ejecución de la simulación

Para efectuar la simulación debemos colocar el fichero (lr-wpan.cc) en el directorio/repos/ns-3-allinone/ns-3-dev/scratch.

Una vez situado el fichero en el directorio indicado, realizamos los siguientes pasospara su ejecución (ver Figura B.4):

1. Abrimos un terminal.

2. Nos colocamos en el directorio /repos/ns-3-allinone/ns-3-dev introduciendo:

cd repos/ns -3- allinone /ns -3- dev

3. Una vez en el directorio ejecutamos el fichero que deseemos introduciendo (elnombre del fichero va sin comillas):

./ waf --run lr -wpan

4. Si se desease introducir los parámetros comentados en el apartado anterior intro-ducimos:

./ waf --run "lr -wpan --packetSize =100 -pcap =0"

Para estos casos, se ha ejecutado la simulación indicando que no deseamos ex-portar la captura de los paquetes en ficheros “.pcap”, y que deseamos efectuar lasimulación empleando un tamaño de paquete de 100 Bytes. En nuestro caso solohemos introducido 2 parámetros pero se pueden introducir todos los mencionadosen el apartado anterior.

73

Figura B.4: Ejemplo ejecución del fichero pfc_tcp.cc

B.2.2.2. Generación de los ficheros GNUplot

Una vez ejecutado el fichero lr-wpan.cc, éste genera un fichero “.plt” con la gráficaque compara el PSR en función de la distancia entre los nodos. Este fichero no es legiblepor si solo, si no que es necesario compilarlo con el programa GNUplot [19].

GNUplot es una herramienta GNU que nos permitirá dibujar fácilmente gráficascon los datos numéricos obtenidos del fichero “.plt” que genera la simulación. Una vezejecutamos en GNUplot el fichero “.plt”, éste nos generará un archivo “.eps” legible yen el cual podemos ver la gráfica anteriormente mencionada.

Instalación de GNUplot

Para la instalación de la herramienta GNUplot realizamos los siguientes pasos:

1. Abrimos la terminal.

2. Instalamos el programa introduciendo el siguiente comando en el terminal:

sudo apt -get install gnuplot

74

Conversión del archivo “.plt” a “.eps”

Para la conversión del archivo “.plt” generado en la simulación a “.eps”, se ha de seguirlos siguientes pasos:

1. Abrimos un terminal.

2. Nos colocamos en el directorio donde se aloja el fichero “.plt”, que en nuestro casoes /repos/ns-3-allinone/ns-3-dev, introduciendo:

cd repos/ns -3- allinone /ns -3- dev

3. Una vez en el directorio ejecutamos el programa GNUplot y entraremos en elprompt de GNUplot introduciendo:

gnuplot

4. Dentro del prompt de GNUplot introducimos el siguiente comando para la gene-ración del archivo “.eps”:

load " nombre_del_fichero .plt"

Figura B.5: Ejemplo de utilización de la herramienta GNUplot

75

Anexo C

Manual de mantenimiento

En el presente anexo se adjunta la documentación del código de los programaspfc_tcp.cc, pfc_udp.cc y lr-wpan.cc la cual ha sido generada con Doxygen.

En esta documentación se detalla el significado y uso de cada variable declarada enel programa, así como, la funcionalidad de cada método.

76

Documentación del código

Generado por Doxygen 1.7.6.1

Lunes, 16 de Junio de 2014 18:38:00

Indice general

1 Índice de estructura de datos 1

1.1 Estructura de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Indice de archivos 3

2.1 Lista de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Documentación de las estructuras de datos 5

3.1 Referencia de la Clase MeshTestTCP . . . . . . . . . . . . . . . . . . 5

3.1.1 Descripción detallada . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.2 Documentación del constructor y destructor . . . . . . . . . . . 7

3.1.2.1 MeshTestTCP . . . . . . . . . . . . . . . . . . . . . 7

3.1.3 Documentación de las funciones miembro . . . . . . . . . . . . 7

3.1.3.1 Configure . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.3.2 CreateNodes . . . . . . . . . . . . . . . . . . . . . . 8

3.1.3.3 GetCalculatedNodes . . . . . . . . . . . . . . . . . . 8

3.1.3.4 InstallApplication . . . . . . . . . . . . . . . . . . . . 9

3.1.3.5 InstallInternetStack . . . . . . . . . . . . . . . . . . 9

3.1.3.6 Run . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.4 Documentación de los campos . . . . . . . . . . . . . . . . . . 9

3.1.4.1 interfaces . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.4.2 m_channel . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.4.3 m_client . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.4.4 m_defaultSeed . . . . . . . . . . . . . . . . . . . . . 10

3.1.4.5 m_distance . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.4.6 m_nodes . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.4.7 m_pcap . . . . . . . . . . . . . . . . . . . . . . . . 10

II ÍNDICE GENERAL

3.1.4.8 m_printRoutes . . . . . . . . . . . . . . . . . . . . . 10

3.1.4.9 m_seed . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.4.10 m_server . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.4.11 m_servPort . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.4.12 m_timeEnd . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.4.13 m_timeStart . . . . . . . . . . . . . . . . . . . . . . 11

3.1.4.14 m_timeTotal . . . . . . . . . . . . . . . . . . . . . . 11

3.1.4.15 m_totalTime . . . . . . . . . . . . . . . . . . . . . . 11

3.1.4.16 mesh . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.4.17 meshDevices . . . . . . . . . . . . . . . . . . . . . . 11

3.1.4.18 nodes . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Referencia de la Clase MeshTestUDP . . . . . . . . . . . . . . . . . . 12

3.2.1 Descripción detallada . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.2 Documentación del constructor y destructor . . . . . . . . . . . 14

3.2.2.1 MeshTestUDP . . . . . . . . . . . . . . . . . . . . . 14

3.2.3 Documentación de las funciones miembro . . . . . . . . . . . . 14

3.2.3.1 Configure . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.3.2 CreateNodes . . . . . . . . . . . . . . . . . . . . . . 15

3.2.3.3 GetCalculatedNodes . . . . . . . . . . . . . . . . . . 15

3.2.3.4 InstallApplication . . . . . . . . . . . . . . . . . . . . 15

3.2.3.5 InstallInternetStack . . . . . . . . . . . . . . . . . . 16

3.2.3.6 Run . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.4 Documentación de los campos . . . . . . . . . . . . . . . . . . 16

3.2.4.1 interfaces . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.4.2 m_channel . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.4.3 m_client . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.4.4 m_defaultSeed . . . . . . . . . . . . . . . . . . . . . 17

3.2.4.5 m_distance . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.4.6 m_nodes . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.4.7 m_pcap . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.4.8 m_printRoutes . . . . . . . . . . . . . . . . . . . . . 17

3.2.4.9 m_seed . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.4.10 m_server . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.4.11 m_servPort . . . . . . . . . . . . . . . . . . . . . . . 17

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

ÍNDICE GENERAL III

3.2.4.12 m_timeEnd . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.4.13 m_timeStart . . . . . . . . . . . . . . . . . . . . . . 18

3.2.4.14 m_timeTotal . . . . . . . . . . . . . . . . . . . . . . 18

3.2.4.15 m_totalTime . . . . . . . . . . . . . . . . . . . . . . 18

3.2.4.16 mesh . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.4.17 meshDevices . . . . . . . . . . . . . . . . . . . . . . 18

3.2.4.18 nodes . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Documentación de archivos 19

4.1 Referencia del Archivo lr-wpan.cc . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Descripción detallada . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.2 Documentación de las funciones . . . . . . . . . . . . . . . . . 20

4.1.2.1 LrWpanErrorDistanceCallback . . . . . . . . . . . . . 20

4.1.2.2 main . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.2.3 NS_LOG_COMPONENT_DEFINE . . . . . . . . . . 21

4.1.3 Documentación de las variables . . . . . . . . . . . . . . . . . 21

4.1.3.1 g_received . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Referencia del Archivo pfc_tcp.cc . . . . . . . . . . . . . . . . . . . . . 21

4.2.1 Descripción detallada . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.2 Documentación de los ’defines’ . . . . . . . . . . . . . . . . . . 22

4.2.2.1 length . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.3 Documentación de las funciones . . . . . . . . . . . . . . . . . 22

4.2.3.1 esNumerico . . . . . . . . . . . . . . . . . . . . . . 22

4.2.3.2 main . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.3.3 NS_LOG_COMPONENT_DEFINE . . . . . . . . . . 23

4.3 Referencia del Archivo pfc_udp.cc . . . . . . . . . . . . . . . . . . . . 23

4.3.1 Descripción detallada . . . . . . . . . . . . . . . . . . . . . . . 24

4.3.2 Documentación de los ’defines’ . . . . . . . . . . . . . . . . . . 24

4.3.2.1 length . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3.3 Documentación de las funciones . . . . . . . . . . . . . . . . . 24

4.3.3.1 esNumerico . . . . . . . . . . . . . . . . . . . . . . 24

4.3.3.2 main . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3.3.3 NS_LOG_COMPONENT_DEFINE . . . . . . . . . . 25

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

Capıtulo 1

Indice de estructura de datos

1.1. Estructura de datos

Lista de estructuras con una breve descripción:

MeshTestTCPClase compuesta por los metodos y atributos necesarios para reali-zar la simulacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

MeshTestUDPClase compuesta por los metodos y atributos necesarios para reali-zar la simulacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Índice de estructura de datos

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

Capıtulo 2

Indice de archivos

2.1. Lista de archivos

Lista de todos los archivos con descripciones breves:

lr-wpan.cc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19pfc_tcp.cc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21pfc_udp.cc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Indice de archivos

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

Capıtulo 3

Documentacion de las estructuras dedatos

3.1. Referencia de la Clase MeshTestTCP

Clase compuesta por los metodos y atributos necesarios para realizar la simulacion.

Metodos publicos

MeshTestTCP ()

Constructor.

void Configure (int argc, char ∗∗argv, char ∗seed, char ∗distance, char ∗server)

Define el metodo ’Configure()’ y lo expone como metodo publico.

int Run ()

Define el metodo ’Run()’ y lo expone como metodo publico.

int GetCalculatedNodes ()

Define el metodo ’GetCalculatedNodes()’ y lo expone como metodo publico.

Metodos privados

void CreateNodes ()

Define el metodo ’CreateNodes()’.

void InstallInternetStack ()

Define el metodo ’InstallInternetStack()’.

void InstallApplication ()

Define el metodo ’InstallApplication()’.

6 Documentación de las estructuras de datos

Atributos privados

int m_nodes

Numero de nodos definidos en la red de la simulacion.

double m_totalTime

Tiempo de la simulacion.

int m_channel

Frecuencia del canal.

bool m_pcap

Indica si se desea exportar la captura de los paquetes en ficheros de formato pcap.

int m_seed

Numero de semilla.

int m_defaultSeed

Semilla por defecto.

int m_client

Numero de nodo escogido como cliente en la simulacion.

int m_server

Numero de nodo escogido como servidor en la simulacion.

uint16_t m_servPort

Numero de puerto del servidor.

bool m_printRoutes

Indica si se desea exportar la tabla de rutas de los nodos en ficheros de texto plano.

int m_distance

Distancia de separacion entre los nodos que conforman la red de simulacion.

float m_timeTotal

Objeto para controlar la duracion total de la simulacion.

float m_timeStart

Objeto para controlar el comienzo de la simulacion.

float m_timeEnd

Objeto para controlar el fin de la simulacion.

NodeContainer nodes

Contenedor de los nodos de la red.

NetDeviceContainer meshDevices

Contenedor de los dispositivos asociados a los nodos de la red.

Ipv4InterfaceContainer interfaces

Contenedor de las interfaces asociadas a los dispositivos de la red.

WifiHelper mesh

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

3.1 Referencia de la Clase MeshTestTCP 7

3.1.1. Descripcion detallada

Clase compuesta por los metodos y atributos necesarios para realizar la simulacion.

Ver tambien

m_nodesm_totalTimem_channelm_pcapm_seedm_defaultSeedm_clientm_serverm_servPortm_printRoutesm_distancem_timeTotalm_timeStartm_timeEndCreateNodes ()Configure ()InstallInternetStack ()InstallApplication ()Run ()

Definición en la línea 75 del archivo pfc_tcp.cc.

3.1.2. Documentacion del constructor y destructor

3.1.2.1. MeshTestTCP ( )

Constructor.

Establece los valores por defecto de las variables.

Metodo Constructor por defecto.

Definición en la línea 160 del archivo pfc_tcp.cc.

3.1.3. Documentacion de las funciones miembro

3.1.3.1. void Configure ( int argc, char ∗∗ argv, char ∗ seed, char ∗ distance, char ∗ server )

Define el metodo ’Configure()’ y lo expone como metodo publico.

Recibe los argumentos pasados como parametros de la simulacion y establece losdatos de entrada de NS-3.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

8 Documentación de las estructuras de datos

Ver tambien

Configure ()

Metodo Configure.

Parametrosargc Numero de argumentos recibidos como parametro de la simulacion.

Son los argumentos defectivos definidos en el script.argv Vector con los argumentos recibidos como parametro de la simulacion.seed Semilla para la generacion de simulaciones aleatorias

distance Distancias definidas para la separacion de los nodos que conforman lared de la simulacion

server Numero de nodo elegido con el cual se comunicaran los nodos-clientes.Dicho nodo hara el trabajo de nodo-servidor

Definición en la línea 193 del archivo pfc_tcp.cc.

3.1.3.2. void CreateNodes ( ) [private]

Define el metodo ’CreateNodes()’.

Crea el numero de nodos que conforman la red, las caracteristicas del canal, la posicionde los nodos y el algoritmo de movimiento de los nodos.

Ver tambien

CreateNodes ()

Metodo CreateNodes.

Definición en la línea 234 del archivo pfc_tcp.cc.

3.1.3.3. int GetCalculatedNodes ( )

Define el metodo ’GetCalculatedNodes()’ y lo expone como metodo publico.

Obtiene el numero de nodos definidos en la red a simular.

Ver tambien

GetCalculatedNodes()

Metodo GetCalculatedNodes()

Devuelve

int Numero de nodos definidos en la red

Definición en la línea 180 del archivo pfc_tcp.cc.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

3.1 Referencia de la Clase MeshTestTCP 9

3.1.3.4. void InstallApplication ( ) [private]

Define el metodo ’InstallApplication()’.

Instala el protocolo a nivel de aplicacion en los nodos seleccionados.

Ver tambien

InstallApplication ()

Metodo InstallApplication. TCP protocol

Definición en la línea 335 del archivo pfc_tcp.cc.

3.1.3.5. void InstallInternetStack ( ) [private]

Define el metodo ’InstallInternetStack()’.

Instala la pila de protocolos de Internet a los nodos de la red, y les proporciona enca-minamiento. Ademñas de definir las direcciones Ip de los mismos.

Ver tambien

InstallInternetStack ()

Metodo InstallInternetstack.

Definición en la línea 306 del archivo pfc_tcp.cc.

3.1.3.6. int Run ( )

Define el metodo ’Run()’ y lo expone como metodo publico.

Ejecutar la simulacion en NS-3, y capturar los resultados obtenidos en la simulacion.

Ver tambien

Run ()

Metodo Run.

Devuelve

0 si se ha ejecutado correctamente.

Definición en la línea 394 del archivo pfc_tcp.cc.

3.1.4. Documentacion de los campos

3.1.4.1. Ipv4InterfaceContainer interfaces [private]

Contenedor de las interfaces asociadas a los dispositivos de la red.

Definición en la línea 134 del archivo pfc_tcp.cc.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

10 Documentación de las estructuras de datos

3.1.4.2. int m_channel [private]

Frecuencia del canal.

Definición en la línea 105 del archivo pfc_tcp.cc.

3.1.4.3. int m_client [private]

Numero de nodo escogido como cliente en la simulacion.

Definición en la línea 113 del archivo pfc_tcp.cc.

3.1.4.4. int m_defaultSeed [private]

Semilla por defecto.

Definición en la línea 111 del archivo pfc_tcp.cc.

3.1.4.5. int m_distance [private]

Distancia de separacion entre los nodos que conforman la red de simulacion.

Definición en la línea 121 del archivo pfc_tcp.cc.

3.1.4.6. int m_nodes [private]

Numero de nodos definidos en la red de la simulacion.

Definición en la línea 101 del archivo pfc_tcp.cc.

3.1.4.7. bool m_pcap [private]

Indica si se desea exportar la captura de los paquetes en ficheros de formato pcap.

Definición en la línea 107 del archivo pfc_tcp.cc.

3.1.4.8. bool m_printRoutes [private]

Indica si se desea exportar la tabla de rutas de los nodos en ficheros de texto plano.

Definición en la línea 119 del archivo pfc_tcp.cc.

3.1.4.9. int m_seed [private]

Numero de semilla.

Definición en la línea 109 del archivo pfc_tcp.cc.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

3.1 Referencia de la Clase MeshTestTCP 11

3.1.4.10. int m_server [private]

Numero de nodo escogido como servidor en la simulacion.

Definición en la línea 115 del archivo pfc_tcp.cc.

3.1.4.11. uint16 t m_servPort [private]

Numero de puerto del servidor.

Definición en la línea 117 del archivo pfc_tcp.cc.

3.1.4.12. float m_timeEnd [private]

Objeto para controlar el fin de la simulacion.

Definición en la línea 128 del archivo pfc_tcp.cc.

3.1.4.13. float m_timeStart [private]

Objeto para controlar el comienzo de la simulacion.

Definición en la línea 126 del archivo pfc_tcp.cc.

3.1.4.14. float m_timeTotal [private]

Objeto para controlar la duracion total de la simulacion.

Definición en la línea 124 del archivo pfc_tcp.cc.

3.1.4.15. double m_totalTime [private]

Tiempo de la simulacion.

Definición en la línea 103 del archivo pfc_tcp.cc.

3.1.4.16. WifiHelper mesh [private]

Definición en la línea 136 del archivo pfc_tcp.cc.

3.1.4.17. NetDeviceContainer meshDevices [private]

Contenedor de los dispositivos asociados a los nodos de la red.

Definición en la línea 132 del archivo pfc_tcp.cc.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

12 Documentación de las estructuras de datos

3.1.4.18. NodeContainer nodes [private]

Contenedor de los nodos de la red.

Definición en la línea 130 del archivo pfc_tcp.cc.

La documentación para esta clase fue generada a partir del siguiente fichero:

pfc_tcp.cc

3.2. Referencia de la Clase MeshTestUDP

Clase compuesta por los metodos y atributos necesarios para realizar la simulacion.

Metodos publicos

MeshTestUDP ()

Constructor.

void Configure (int argc, char ∗∗argv, char ∗seed, char ∗distance, char ∗server)

Define el metodo ’Configure()’ y lo expone como metodo publico.

int Run ()

Define el metodo ’Run()’ y lo expone como metodo publico.

int GetCalculatedNodes ()

Define el metodo ’GetCalculatedNodes()’ y lo expone como metodo publico.

Metodos privados

void CreateNodes ()

Define el metodo ’CreateNodes()’.

void InstallInternetStack ()

Define el metodo ’InstallInternetStack()’.

void InstallApplication ()

Define el metodo ’InstallApplication()’.

Atributos privados

int m_nodes

Numero de nodos definidos en la red de la simulacion.

double m_totalTime

Tiempo de la simulacion.

int m_channel

Frecuencia del canal.

bool m_pcap

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

3.2 Referencia de la Clase MeshTestUDP 13

Indica si se desea exportar la captura de los paquetes en ficheros de formato pcap.

int m_seed

Numero de semilla.

int m_defaultSeed

Semilla por defecto.

int m_client

Numero de nodo escogido como cliente en la simulacion.

int m_server

Numero de nodo escogido como servidor en la simulacion.

uint16_t m_servPort

Numero de puerto del servidor.

bool m_printRoutes

Indica si se desea exportar la tabla de rutas de los nodos en ficheros de texto plano.

int m_distance

Distancia de separacion entre los nodos que conforman la red de simulacion.

float m_timeTotal

Objeto para controlar la duracion total de la simulacion.

float m_timeStart

Objeto para controlar el comienzo de la simulacion.

float m_timeEnd

Objeto para controlar el fin de la simulacion.

NodeContainer nodes

Contenedor de los nodos de la red.

NetDeviceContainer meshDevices

Contenedor de los dispositivos asociados a los nodos de la red.

Ipv4InterfaceContainer interfaces

Contenedor de las interfaces asociadas a los dispositivos de la red.

WifiHelper mesh

3.2.1. Descripcion detallada

Clase compuesta por los metodos y atributos necesarios para realizar la simulacion.

Ver tambien

m_nodesm_totalTimem_channelm_pcapm_seedm_defaultSeedm_clientm_serverm_servPortm_printRoutes

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

14 Documentación de las estructuras de datos

m_distancem_timeTotalm_timeStartm_timeEndCreateNodes ()Configure ()InstallInternetStack ()InstallApplication ()Run ()

Definición en la línea 74 del archivo pfc_udp.cc.

3.2.2. Documentacion del constructor y destructor

3.2.2.1. MeshTestUDP ( )

Constructor.

Establece los valores por defecto de las variables.

Metodo Constructor por defecto.

Definición en la línea 159 del archivo pfc_udp.cc.

3.2.3. Documentacion de las funciones miembro

3.2.3.1. void Configure ( int argc, char ∗∗ argv, char ∗ seed, char ∗ distance, char ∗ server )

Define el metodo ’Configure()’ y lo expone como metodo publico.

Recibe los argumentos pasados como parametros de la simulacion y establece losdatos de entrada de NS-3.

Ver tambien

Configure ()

Metodo Configure.

Parametrosargc Numero de argumentos recibidos como parametro de la simulacion.

Son los argumentos defectivos definidos en el script.argv Vector con los argumentos recibidos como parametro de la simulacion.seed Semilla para la generacion de simulaciones aleatorias

distance Distancias definidas para la separacion de los nodos que conforman lared de la simulacion

server Numero de nodo elegido con el cual se comunicaran los nodos-clientes.Dicho nodo hara el trabajo de nodo-servidor

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

3.2 Referencia de la Clase MeshTestUDP 15

Definición en la línea 192 del archivo pfc_udp.cc.

3.2.3.2. void CreateNodes ( ) [private]

Define el metodo ’CreateNodes()’.

Crea el numero de nodos que conforman la red, las caracteristicas del canal, la posicionde los nodos y el algoritmo de movimiento de los nodos.

Ver tambien

CreateNodes ()

Metodo CreateNodes.

Definición en la línea 233 del archivo pfc_udp.cc.

3.2.3.3. int GetCalculatedNodes ( )

Define el metodo ’GetCalculatedNodes()’ y lo expone como metodo publico.

Obtiene el numero de nodos definidos en la red a simular.

Ver tambien

GetCalculatedNodes()

Metodo GetCalculatedNodes()

Devuelve

int Numero de nodos definidos en la red

Definición en la línea 179 del archivo pfc_udp.cc.

3.2.3.4. void InstallApplication ( ) [private]

Define el metodo ’InstallApplication()’.

Instala el protocolo a nivel de aplicacion en los nodos seleccionados.

Ver tambien

InstallApplication ()

Metodo InstallApplication. UDP protocol

Definición en la línea 333 del archivo pfc_udp.cc.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

16 Documentación de las estructuras de datos

3.2.3.5. void InstallInternetStack ( ) [private]

Define el metodo ’InstallInternetStack()’.

Instala la pila de protocolos de Internet a los nodos de la red, y les proporciona enca-minamiento. Ademñas de definir las direcciones Ip de los mismos.

Ver tambien

InstallInternetStack ()

Metodo InstallInternetstack.

Definición en la línea 304 del archivo pfc_udp.cc.

3.2.3.6. int Run ( )

Define el metodo ’Run()’ y lo expone como metodo publico.

Ejecutar la simulacion en NS-3, y capturar los resultados obtenidos en la simulacion.

Ver tambien

Run ()

Metodo Run.

Devuelve

0 si se ha ejecutado correctamente.

Definición en la línea 390 del archivo pfc_udp.cc.

3.2.4. Documentacion de los campos

3.2.4.1. Ipv4InterfaceContainer interfaces [private]

Contenedor de las interfaces asociadas a los dispositivos de la red.

Definición en la línea 133 del archivo pfc_udp.cc.

3.2.4.2. int m_channel [private]

Frecuencia del canal.

Definición en la línea 103 del archivo pfc_udp.cc.

3.2.4.3. int m_client [private]

Numero de nodo escogido como cliente en la simulacion.

Definición en la línea 111 del archivo pfc_udp.cc.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

3.2 Referencia de la Clase MeshTestUDP 17

3.2.4.4. int m_defaultSeed [private]

Semilla por defecto.

Definición en la línea 109 del archivo pfc_udp.cc.

3.2.4.5. int m_distance [private]

Distancia de separacion entre los nodos que conforman la red de simulacion.

Definición en la línea 120 del archivo pfc_udp.cc.

3.2.4.6. int m_nodes [private]

Numero de nodos definidos en la red de la simulacion.

Definición en la línea 99 del archivo pfc_udp.cc.

3.2.4.7. bool m_pcap [private]

Indica si se desea exportar la captura de los paquetes en ficheros de formato pcap.

Definición en la línea 105 del archivo pfc_udp.cc.

3.2.4.8. bool m_printRoutes [private]

Indica si se desea exportar la tabla de rutas de los nodos en ficheros de texto plano.

Definición en la línea 117 del archivo pfc_udp.cc.

3.2.4.9. int m_seed [private]

Numero de semilla.

Definición en la línea 107 del archivo pfc_udp.cc.

3.2.4.10. int m_server [private]

Numero de nodo escogido como servidor en la simulacion.

Definición en la línea 113 del archivo pfc_udp.cc.

3.2.4.11. uint16 t m_servPort [private]

Numero de puerto del servidor.

Definición en la línea 115 del archivo pfc_udp.cc.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

18 Documentación de las estructuras de datos

3.2.4.12. float m_timeEnd [private]

Objeto para controlar el fin de la simulacion.

Definición en la línea 127 del archivo pfc_udp.cc.

3.2.4.13. float m_timeStart [private]

Objeto para controlar el comienzo de la simulacion.

Definición en la línea 125 del archivo pfc_udp.cc.

3.2.4.14. float m_timeTotal [private]

Objeto para controlar la duracion total de la simulacion.

Definición en la línea 123 del archivo pfc_udp.cc.

3.2.4.15. double m_totalTime [private]

Tiempo de la simulacion.

Definición en la línea 101 del archivo pfc_udp.cc.

3.2.4.16. WifiHelper mesh [private]

Definición en la línea 135 del archivo pfc_udp.cc.

3.2.4.17. NetDeviceContainer meshDevices [private]

Contenedor de los dispositivos asociados a los nodos de la red.

Definición en la línea 131 del archivo pfc_udp.cc.

3.2.4.18. NodeContainer nodes [private]

Contenedor de los nodos de la red.

Definición en la línea 129 del archivo pfc_udp.cc.

La documentación para esta clase fue generada a partir del siguiente fichero:

pfc_udp.cc

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

Capıtulo 4

Documentacion de archivos

4.1. Referencia del Archivo lr-wpan.cc

#include <ns3/test.h> #include <ns3/log.h> #include <ns3/callback.-h> #include <ns3/packet.h> #include <ns3/simulator.h>#include <ns3/lr-wpan-error-model.h> #include <ns3/propagation-loss-model.-h> #include <ns3/lr-wpan-net-device.h> #include <ns3/spectrum-value.-h> #include <ns3/lr-wpan-spectrum-value-helper.h> #include<ns3/lr-wpan-mac.h> #include <ns3/node.h> #include <ns3/net-device.-h> #include <ns3/single-model-spectrum-channel.h> #include<ns3/mac16-address.h> #include <ns3/constant-position-mobility-model.-h> #include <ns3/uinteger.h> #include <ns3/nstime.h>×#include <ns3/abort.h> #include <ns3/command-line.h>×#include <ns3/gnuplot.h> #include <ns3/lr-wpan-module.-h> #include "ns3/netanim-module.h" #include <fstream>×#include <iostream> #include <string> #include <vector>

Funciones

NS_LOG_COMPONENT_DEFINE ("LrWpanErrorDistancePlot")

static void LrWpanErrorDistanceCallback (McpsDataIndicationParams params, -Ptr< Packet > p)

Metodo que calcula el numero de paquetes recibidos con exito.

int main (int argc, char ∗argv[ ])

Punto de entrada del programa que lanza la simulacion.

Variables

static uint32_t g_received = 0

20 Documentación de archivos

4.1.1. Descripcion detallada

Autor

Antonio Conejero Diaz

Version

1.0

Fecha

23-06-2014

Definición en el archivo lr-wpan.cc.

4.1.2. Documentacion de las funciones

4.1.2.1. static void LrWpanErrorDistanceCallback ( McpsDataIndicationParams params,Ptr< Packet > p ) [static]

Metodo que calcula el numero de paquetes recibidos con exito.

Metodo LrWpanErrorDistanceCallback.

Parametrosparams Parametros sobre la recepcion del paquete

p Paquete enviado

Definición en la línea 56 del archivo lr-wpan.cc.

4.1.2.2. int main ( int argc, char ∗ argv[ ] )

Punto de entrada del programa que lanza la simulacion.

Metodo main.

Parametrosargc Numero de argumentos recibidos como parametro de la simulacion.

Son los argumentos defectivos definidos en el script.argv Vector con los argumentos recibidos como parametro de la simulacion.

Devuelve

0 si se ha ejecutado correctamente.

Definición en la línea 68 del archivo lr-wpan.cc.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

4.2 Referencia del Archivo pfc_tcp.cc 21

4.1.2.3. NS_LOG_COMPONENT_DEFINE ( ”LrWpanErrorDistancePlot” )

4.1.3. Documentacion de las variables

4.1.3.1. uint32 t g_received = 0 [static]

Definición en la línea 45 del archivo lr-wpan.cc.

4.2. Referencia del Archivo pfc tcp.cc

#include <iostream> #include <cmath> #include <sstream>#include <fstream> #include <stdio.h> #include "ns3/mesh-module.-h" #include "ns3/mesh-helper.h" #include "ns3/aodv-module.-h" #include "ns3/core-module.h" #include "ns3/wifi-module.-h" #include "ns3/yans-wifi-helper.h" #include "ns3/nqos-wifi-mac-helper.-h" #include "ns3/ssid.h" #include "ns3/internet-stack-helper.-h" #include "ns3/network-module.h" #include "ns3/internet-module.-h" #include "ns3/ipv4-address-helper.h" #include "ns3/ipv4-global-routing-helper.-h" #include "ns3/mobility-module.h" #include "ns3/mobility-helper.-h" #include "ns3/packet-sink.h" #include "ns3/applications-module.-h" #include "ns3/flow-monitor-module.h"

Estructuras de datos

class MeshTestTCP

Clase compuesta por los metodos y atributos necesarios para realizar la simulacion.

’defines’

#define length(x) (sizeof(x)/sizeof(x[0]))

Funciones

NS_LOG_COMPONENT_DEFINE ("TestMeshScript")int esNumerico (char Cadena[ ])

Método para controlar que una entrada tenga valor numérico.

int main (int argc, char ∗argv[ ])

Punto de entrada del programa que lanza la simulacion.

4.2.1. Descripcion detallada

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

22 Documentación de archivos

Autor

Antonio Conejero Diaz

Version

2.0

Fecha

23-06-2014

Definición en el archivo pfc_tcp.cc.

4.2.2. Documentacion de los ’defines’

4.2.2.1. #define length( x ) (sizeof(x)/sizeof(x[0]))

Definición en la línea 45 del archivo pfc_tcp.cc.

4.2.3. Documentacion de las funciones

4.2.3.1. int esNumerico ( char Cadena[ ] )

Método para controlar que una entrada tenga valor numérico.

ParametrosCadena array de caracteres con los valores a controlar.

Precondicion

No aplica.

Postcondicion

No aplica.

Devuelve

-1 si no es numérico, y su valor si es numérico.

Definición en la línea 440 del archivo pfc_tcp.cc.

4.2.3.2. int main ( int argc, char ∗ argv[ ] )

Punto de entrada del programa que lanza la simulacion.

Metodo main.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

4.3 Referencia del Archivo pfc_udp.cc 23

Parametrosargc Numero de argumentos recibidos como parametro de la simulacion.

Son los argumentos defectivos definidos en el script.argv Vector con los argumentos recibidos como parametro de la simulacion.

Devuelve

0 si se ha ejecutado correctamente.

Definición en la línea 459 del archivo pfc_tcp.cc.

4.2.3.3. NS_LOG_COMPONENT_DEFINE ( ”TestMeshScript” )

4.3. Referencia del Archivo pfc udp.cc

#include <iostream> #include <cmath> #include <sstream>#include <fstream> #include <stdio.h> #include "ns3/mesh-module.-h" #include "ns3/mesh-helper.h" #include "ns3/aodv-module.-h" #include "ns3/core-module.h" #include "ns3/wifi-module.-h" #include "ns3/yans-wifi-helper.h" #include "ns3/nqos-wifi-mac-helper.-h" #include "ns3/ssid.h" #include "ns3/internet-stack-helper.-h" #include "ns3/network-module.h" #include "ns3/internet-module.-h" #include "ns3/ipv4-address-helper.h" #include "ns3/ipv4-global-routing-helper.-h" #include "ns3/mobility-module.h" #include "ns3/mobility-helper.-h" #include "ns3/packet-sink.h" #include "ns3/applications-module.-h" #include "ns3/flow-monitor-module.h"

Estructuras de datos

class MeshTestUDP

Clase compuesta por los metodos y atributos necesarios para realizar la simulacion.

’defines’

#define length(x) (sizeof(x)/sizeof(x[0]))

Funciones

NS_LOG_COMPONENT_DEFINE ("TestMeshScript")int esNumerico (char Cadena[ ])

Método para controlar que una entrada tenga valor numérico.

int main (int argc, char ∗argv[ ])

Punto de entrada del programa que lanza la simulacion.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

24 Documentación de archivos

4.3.1. Descripcion detallada

Autor

Antonio Conejero Diaz

Version

2.0

Fecha

23-06-2014

Definición en el archivo pfc_udp.cc.

4.3.2. Documentacion de los ’defines’

4.3.2.1. #define length( x ) (sizeof(x)/sizeof(x[0]))

Definición en la línea 45 del archivo pfc_udp.cc.

4.3.3. Documentacion de las funciones

4.3.3.1. int esNumerico ( char Cadena[ ] )

Método para controlar que una entrada tenga valor numérico.

ParametrosCadena array de caracteres con los valores a controlar.

Precondicion

No aplica.

Postcondicion

No aplica.

Devuelve

-1 si no es numérico, y su valor si es numérico.

Definición en la línea 437 del archivo pfc_udp.cc.

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

4.3 Referencia del Archivo pfc_udp.cc 25

4.3.3.2. int main ( int argc, char ∗ argv[ ] )

Punto de entrada del programa que lanza la simulacion.

Metodo main.

Parametrosargc Numero de argumentos recibidos como parametro de la simulacion.

Son los argumentos defectivos definidos en el script.argv Vector con los argumentos recibidos como parametro de la simulacion.

Devuelve

0 si se ha ejecutado correctamente.

Definición en la línea 456 del archivo pfc_udp.cc.

4.3.3.3. NS_LOG_COMPONENT_DEFINE ( ”TestMeshScript” )

Generado el Lunes, 16 de Junio de 2014 18:38:00 para Documentación del código por Doxygen

Anexo D

Código fuente de los programas

En el presente anexo se muestran el código empleado para la realización, tanto delos programas que implementan tráfico TCP y UDP, como del script que los ejecutade manera automática. Y el programa que implementa el estándar IEEE 802.15.4.

D.1. pfc_tcp.ccCódigo del programa pfc_tcp.cc, el cual implementa tráfico TCP.

1 /**@file pfc_tcp .cc

2 @author Antonio Conejero Diaz

3 @version 2.0

4 @date 23 -06 -2014

5 */

6

7 # include <iostream >

8 # include <cmath >

9 # include <sstream >

10 # include <fstream >

11 # include <stdio.h> // Para escribir los resultados obtenidos en

un fichero de texto

12

13 // Cabeceras para crear la red y las caracteristicas de los

nodos

14 # include "ns3/mesh - module .h"

15 # include "ns3/mesh - helper .h"

16 # include "ns3/aodv - module .h"

17 # include "ns3/core - module .h"

18 # include "ns3/wifi - module .h"

19

108

20

21 // Cabeceras para adaptar las caracteristicas del canal y

asignar la mobilidad

22 # include "ns3/yans -wifi - helper .h"

23 # include "ns3/nqos -wifi -mac - helper .h"

24 # include "ns3/ssid.h"

25 # include "ns3/internet -stack - helper .h"

26

27 // Cabeceras para asignales las direcciones IP y la torre de

protocolos a los nodos

28 # include "ns3/network - module .h"

29 # include "ns3/internet - module .h"

30 # include "ns3/ipv4 -address - helper .h"

31 # include "ns3/ipv4 -global -routing - helper .h"

32

33 // Cabeceras para la movilidad

34 # include "ns3/mobility - module .h"

35 # include "ns3/mobility - helper .h"

36

37 // Cabeceras para la transmision TCP

38 # include "ns3/packet -sink.h"

39 # include "ns3/ applications - module .h"

40

41 // Cabecera para monitorizar las transmisiones realizadas entre

los nodos

42 # include "ns3/flow -monitor - module .h"

43

44 // Calcular la longitud de un array

45 # define length (x) ( sizeof (x)/ sizeof (x[0]))

46

47 using namespace ns3;

48

49

50

51 NS_LOG_COMPONENT_DEFINE (" TestMeshScript ");

52

53

54 /** @brief Clase compuesta por los metodos y atributos

necesarios para realizar la simulacion .

55 * @see m_nodes

56 * @see m_totalTime

109

57 * @see m_channel

58 * @see m_pcap

59 * @see m_seed

60 * @see m_defaultSeed

61 * @see m_client

62 * @see m_server

63 * @see m_servPort

64 * @see m_printRoutes

65 * @see m_distance

66 * @see m_timeTotal

67 * @see m_timeStart

68 * @see m_timeEnd

69 * @see CreateNodes ()

70 * @see Configure ()

71 * @see InstallInternetStack ()

72 * @see InstallApplication ()

73 * @see Run ()

74 */

75 class MeshTestTCP

76 {

77 // Public method

78 public :

79 /** @brief Constructor */

80 MeshTestTCP ();

81

82

83 /** @brief Define el metodo ’Configure ()’ y lo expone

como metodo publico

84 * @see Configure ()

85 */

86 void Configure (int argc , char ** argv , char* seed ,

char* distance , char* server );

87

88 /** @brief Define el metodo ’Run ()’ y lo expone como

metodo publico

89 * @see Run ()

90 */

91 int Run ();

92

93 /** @brief Define el metodo ’GetCalculatedNodes ()’ y lo

expone como metodo publico

110

94 * @see GetCalculatedNodes ()

95 */

96 int GetCalculatedNodes ();

97

98 // Private attributes

99 private :

100 /// @brief Numero de nodos definidos en la red de la

simulacion

101 int m_nodes ;

102 /// @brief Tiempo de la simulacion

103 double m_totalTime ;

104 /// @brief Frecuencia del canal

105 int m_channel ;

106 /// @brief Indica si se desea exportar la captura de

los paquetes en ficheros de formato pcap

107 bool m_pcap ;

108 /// @brief Numero de semilla

109 int m_seed ;

110 /// @brief Semilla por defecto

111 int m_defaultSeed ;

112 /// @brief Numero de nodo escogido como cliente en la

simulacion

113 int m_client ;

114 /// @brief Numero de nodo escogido como servidor en la

simulacion

115 int m_server ;

116 /// @brief Numero de puerto del servidor

117 uint16_t m_servPort ;

118 /// @brief Indica si se desea exportar la tabla de

rutas de los nodos en ficheros de texto plano

119 bool m_printRoutes ;

120 /// @brief Distancia de separacion entre los nodos que

conforman la red de simulacion

121 int m_distance ;

122

123 /// @brief Objeto para controlar la duracion total de

la simulacion

124 float m_timeTotal ;

125 /// @brief Objeto para controlar el comienzo de la

simulacion

126 float m_timeStart ;

111

127 /// @brief Objeto para controlar el fin de la

simulacion

128 float m_timeEnd ;

129 /// @brief Contenedor de los nodos de la red

130 NodeContainer nodes;

131 /// @brief Contenedor de los dispositivos asociados a

los nodos de la red

132 NetDeviceContainer meshDevices ;

133 /// @brief Contenedor de las interfaces asociadas a los

dispositivos de la red

134 Ipv4InterfaceContainer interfaces ;

135

136 WifiHelper mesh;

137

138 // Private methods

139 private :

140 /** @brief Define el metodo ’CreateNodes ()’

141 * @see CreateNodes ()

142 */

143 void CreateNodes ();

144

145 /** @brief Define el metodo ’InstallInternetStack ()’

146 * @see InstallInternetStack ()

147 */

148 void InstallInternetStack ();

149

150 /** @brief Define el metodo ’InstallApplication ()’

151 * @see InstallApplication ()

152 */

153 void InstallApplication ();

154 };

155

156

157 /** Metodo Constructor por defecto .

158 * @brief Establece los valores por defecto de las variables .

159 */

160 MeshTestTCP :: MeshTestTCP () : m_nodes (8) ,

161 m_totalTime (120.0) ,

162 m_channel (3) ,

163 m_pcap (true),

164 m_seed (23) ,

112

165 m_defaultSeed (9) ,

166 m_client (0) ,

167 m_server (1) ,

168 m_servPort (5001) ,

169 m_printRoutes (true),

170 m_distance (100)

171 {

172 // NOTHING TO DO HERE

173 }

174

175

176 /** Metodo GetCalculatedNodes ()

177 * @brief Obtiene el numero de nodos definidos en la red a

simular

178 * @return int Numero de nodos definidos en la red

179 */

180 int MeshTestTCP :: GetCalculatedNodes (){

181 return m_nodes ;

182 }

183

184

185 /** Metodo Configure .

186 * @brief Recibe los argumentos pasados como parametros de la

simulacion y establece los datos de entrada de NS -3.

187 * @param argc Numero de argumentos recibidos como parametro de

la simulacion . Son los argumentos defectivos definidos en el

script .

188 * @param argv Vector con los argumentos recibidos como

parametro de la simulacion .

189 * @param seed Semilla para la generacion de simulaciones

aleatorias

190 * @param distance Distancias definidas para la separacion de

los nodos que conforman la red de la simulacion

191 * @param server Numero de nodo elegido con el cual se

comunicaran los nodos - clientes . Dicho nodo hara el trabajo de

nodo - servidor

192 */

193 void MeshTestTCP :: Configure (int argc , char *argv [], char *seed

, char *distance , char * server )

194 {

195

113

196 std :: cout << " Configure >>>>> \n";

197

198 CommandLine cmd;

199

200 SeedManager :: SetSeed ( m_defaultSeed );

201

202 Config :: SetDefault ("ns3 :: WifiRemoteStationManager ::

RtsCtsThreshold ",StringValue ("3000"));

203

204 Config :: SetDefault ("ns3 :: WifiRemoteStationManager ::

FragmentationThreshold ", StringValue ("3000"));

205

206 cmd. AddValue ("nodes", " Number of nodes in the network [

Default 8]", m_nodes );

207 m_server = atoi( server );

208 cmd. AddValue (" server ", "Node server [ Default 1]", m_server )

;

209 cmd. AddValue (" client ", "Node client [ Default 0]", m_client )

;

210 cmd. AddValue ("time", " Simulation time , seconds [120 s]",

m_totalTime );

211 cmd. AddValue (" channel ", " Select channel of transmision [

Default 3]", m_channel );

212 cmd. AddValue ("pcap", " Enable PCAP traces on interfaces . [

Default 1]", m_pcap );

213 m_seed = atoi(seed);

214 cmd. AddValue ("seed", "Set the seed for random values [

Default 9]", m_seed );

215 cmd. AddValue (" printRoutes ", "Print routing table dumps.",

m_printRoutes );

216 m_distance = atoi( distance );

217 cmd. AddValue (" distance ", " distance between nodes [ Default

100]",m_distance );

218 cmd.Parse (argc , argv);

219 NS_LOG_DEBUG (" Number of nodes: " << m_nodes );

220 NS_LOG_DEBUG (" Simulation time: " << m_totalTime << " s");

221

222 std :: cout << "\t Time of simulation : " << m_totalTime << "\

n";

223 std :: cout << "\t Seed: " << m_seed << "\n";

224 std :: cout << "\t Server : " << m_server << "\n";

114

225 std :: cout << "\t Distance : " << m_distance << "\n";

226

227 std :: cout << " Configure <<<<<< \n";

228 }

229

230

231 /** Metodo CreateNodes .

232 * @brief Crea el numero de nodos que conforman la red , las

caracteristicas del canal , la posicion de los nodos y el

algoritmo de movimiento de los nodos.

233 */

234 void MeshTestTCP :: CreateNodes () {

235

236 std :: cout << " CreateNodes >>>>> \n";

237

238 // Calcula los nodos que han de crearse en funcion de la

distancia introducida

239 int nodosfila = 500 / m_distance ;

240 m_nodes = nodosfila * nodosfila ;

241 NS_LOG_DEBUG (" Number of nodes: " << m_nodes );

242 // Parameters Loss Propagation Model

243 double m_referenceDistance = 1.0; // m

244 double m_exponent = 1.7;

245 double m_referenceLoss = 40.178882771; // L0 = 20 log (4 pi

feqChann3 / 3 exp8)

246 double m_EnergyDet = -86.0;

247 double m_ccath = -99.0;

248 double m_txpower = 18.0; // dbm

249

250 SeedManager :: SetRun ( m_seed );

251 NS_LOG_INFO (" Building chain topology .");

252 nodes. Create ( m_nodes );

253 mesh. SetStandard ( WIFI_PHY_STANDARD_80211b );

254 NqosWifiMacHelper wifiMac = NqosWifiMacHelper :: Default ();

255 // Configure YansWifiChannel

256 YansWifiPhyHelper wifiPhy = YansWifiPhyHelper :: Default ();

257

258 wifiPhy .Set(" EnergyDetectionThreshold ", DoubleValue (

m_EnergyDet )); // defulat val is -96 dBm

259 wifiPhy .Set(" CcaMode1Threshold ", DoubleValue ( m_ccath )); //

default val is -99 dBm

115

260 wifiPhy .Set(" TxGain ", DoubleValue (1.0)); // Use 5.0 to

extend range to about 300 meters

261 wifiPhy .Set(" RxGain ", DoubleValue (1.0)); // Use 5.0 to

extend range to about 300 meters

262 wifiPhy .Set(" TxPowerLevels ", UintegerValue (1) );

263 wifiPhy .Set(" TxPowerEnd ", DoubleValue ( m_txpower ) ); //

default val is 16.0206 dBm

264 wifiPhy .Set(" TxPowerStart ", DoubleValue ( m_txpower ) ); //

default val is 16.0206 dBm

265 wifiPhy .Set(" RxNoiseFigure ", DoubleValue (7.0) ); // defulat

val is 7dB

266 wifiPhy .Set(" ChannelNumber ", UintegerValue ( m_channel ));

267

268

269

270 YansWifiChannelHelper wifiChannel ;

271 wifiChannel . AddPropagationLoss ("ns3 ::

LogDistancePropagationLossModel "," Exponent ",DoubleValue (

m_exponent )," ReferenceDistance ",DoubleValue (

m_referenceDistance )," ReferenceLoss ",DoubleValue (

m_referenceLoss ));

272 wifiChannel . SetPropagationDelay ("ns3 ::

ConstantSpeedPropagationDelayModel ","Speed",DoubleValue

(3.0 e8));

273 wifiChannel . AddPropagationLoss ("ns3 ::

RandomPropagationLossModel "," Variable ", StringValue ("ns3

:: UniformRandomVariable [Min =27.0| Max =43.0] "));

274 wifiPhy . SetChannel ( wifiChannel . Create ());

275 Ssid ssid = Ssid ("wifi - default ");

276 mesh. SetRemoteStationManager ("ns3 :: ConstantRateWifiManager

", " DataMode ", StringValue (" DsssRate1Mbps "));

277 wifiMac . SetType ("ns3 :: AdhocWifiMac ");

278 meshDevices = mesh. Install (wifiPhy , wifiMac , nodes);

279

280 // POSICIONAMIENTO DE LOS NODOS

281 MobilityHelper mobility ;

282 mobility . SetPositionAllocator ("ns3 ::

RandomDiscPositionAllocator ",

283 "X", StringValue ("100.0"),

284 "Y", StringValue ("100.0"),

116

285 "Rho", StringValue ("ns3 ::

UniformRandomVariable [Min =0|

Max =30]"));

286 mobility . SetMobilityModel ("ns3 :: RandomWalk2dMobilityModel "

,

287 "Mode", StringValue ("Time"),

288 "Time", StringValue ("2s"),

289 "Speed", StringValue ("ns3 ::

ConstantRandomVariable [ Constant

=1.0]"),

290 " Bounds ", StringValue ("

0|200|0|200 "));

291 mobility . InstallAll ();

292

293

294 if ( m_pcap ){

295 std :: cout << "\t CreateNodes : m_pcap ->" << m_pcap << "\

n";

296 wifiPhy . EnablePcapAll (std :: string ("mp -"));

297 }

298

299 std :: cout << " CreateNodes <<<<< \n";

300 }

301

302

303 /** Metodo InstallInternetstack .

304 * @brief Instala la pila de protocolos de Internet a los nodos

de la red , y les proporciona encaminamiento . Ademñas de

definir las direcciones Ip de los mismos .

305 */

306 void MeshTestTCP :: InstallInternetStack ()

307 {

308

309 std :: cout << " InstallInternetStack >>>>> \n";

310

311 NS_LOG_INFO (" Installing internet stack on all nodes and

assigning IP Addresses .");

312 AodvHelper aodv;

313 InternetStackHelper internetStack ;

314 // Usamos el AODV para proporcionar encaminamiento sin esto

el nodo no ve a los nodos que no alcance fisicamente

117

315 internetStack . SetRoutingHelper (aodv);

316 internetStack . Install (nodes);

317 Ipv4AddressHelper address ;

318 address . SetBase (" 10.0.0.0 ", " 255.255.0.0 ");

319 interfaces = address . Assign ( meshDevices );

320

321 // Imprimimos las tablas de rutas

322 if ( m_printRoutes )

323 {

324 Ptr < OutputStreamWrapper > routingStream = Create <

OutputStreamWrapper > ("mp. routes ", std :: ios :: out);

325 aodv. PrintRoutingTableAllAt ( Seconds (8) , routingStream

);

326 }

327

328 std :: cout << " InstallInternetStack <<<<<< \n";

329 }

330

331

332 /** Metodo InstallApplication .

333 * @brief Instala el protocolo a nivel de aplicacion en los

nodos seleccionados

334 */

335 void MeshTestTCP :: InstallApplication ()

336 {

337

338 std :: cout << " InstallApplication >>>>> \n";

339

340 NS_LOG_INFO (" Create applications .");

341

342 // Definimos el tamaño de paquete

343 uint32_t nPackets = 127;

344

345 Config :: SetDefault ("ns3 :: WifiRemoteStationManager ::

RtsCtsThreshold ",StringValue ("6000"));

346

347 Config :: SetDefault ("ns3 :: WifiRemoteStationManager ::

FragmentationThreshold ", StringValue ("6000"));

348

349

350 /// TCP protocol

118

351

352 Config :: SetDefault ("ns3 :: TcpSocket :: SegmentSize ",

UintegerValue (1460) );

353 Config :: SetDefault ("ns3 :: TcpSocket :: RcvBufSize ",

UintegerValue (900000) );

354 Config :: SetDefault ("ns3 :: TcpSocket :: SndBufSize ",

UintegerValue (900000) );

355 Address sinkLocalAddress ( InetSocketAddress ( Ipv4Address ::

GetAny (), m_servPort ));

356 PacketSinkHelper TCPsinkHelper ("ns3 :: TcpSocketFactory ",

sinkLocalAddress );

357 ApplicationContainer TCPsinkApp = TCPsinkHelper . Install (

nodes.Get ( m_server ));

358 TCPsinkApp .Start ( Seconds (0.001) );

359 TCPsinkApp .Stop ( Seconds ( m_totalTime ));

360 // Creamos la aplicacion OnOff para mandar datos TCP

361 OnOffHelper TCPsourceHelper ("ns3 :: TcpSocketFactory ",

Address ());

362

363 char buffer [50];

364 sprintf (buffer , "ns3 :: ConstantRandomVariable [ Constant= %f]"

, m_totalTime );

365

366 TCPsourceHelper . SetAttribute (" OnTime ", StringValue ( buffer

));

367 TCPsourceHelper . SetAttribute (" OffTime ", StringValue ("ns3

:: ConstantRandomVariable [ Constant =0]"));

368 AddressValue remoteAddress ( InetSocketAddress ( interfaces .

GetAddress ( m_server ), m_servPort ));

369 TCPsourceHelper . SetAttribute (" Remote ", remoteAddress );

370 TCPsourceHelper . SetAttribute (" DataRate ", DataRateValue (

DataRate ("250 kbps")));

371 TCPsourceHelper . SetAttribute (" PacketSize ", UintegerValue (

nPackets ));

372 ApplicationContainer TCPsourceApp ;

373

374 // Calculamos el 10 % de los nodos que van a transmitir

375 int tx = 0.1 * m_nodes ;

376

377 int i=0;

378 do{

119

379 TCPsourceApp .Add ( TCPsourceHelper . Install (nodes.Get(i)

));

380 i=i+8;

381 } while (i<tx);

382

383 TCPsourceApp .Start ( Seconds (0.005) );

384 TCPsourceApp .Stop ( Seconds ( m_totalTime ));

385

386 std :: cout << " InstallApplication <<<<<< \n";

387 }

388

389

390 /** Metodo Run.

391 * @brief Ejecutar la simulacion en NS -3, y capturar los

resultados obtenidos en la simulacion .

392 * @return 0 si se ha ejecutado correctamente .

393 */

394 int MeshTestTCP :: Run ()

395 {

396 CreateNodes ();

397 InstallInternetStack ();

398 InstallApplication ();

399 m_timeStart =clock ();

400 Simulator :: Stop ( Seconds ( m_totalTime ));

401

402 // Instalamos FlowMonitor en todos los nodos

403 FlowMonitorHelper flowmon ;

404 Ptr < FlowMonitor > monitor = flowmon . InstallAll ();

405

406 Simulator :: Run ();

407

408 monitor -> CheckForLostPackets ();

409 Ptr < Ipv4FlowClassifier > classifier = DynamicCast <

Ipv4FlowClassifier > ( flowmon . GetClassifier ());

410 std ::map <FlowId , FlowMonitor :: FlowStats > stats = monitor ->

GetFlowStats ();

411

412 // Creamos el fichero donde se guardaran los resultados

413 FILE * Alfa = fopen (" Resultados Throughput TCP.xls", "a+t"

);

414

120

415 for (std ::map <FlowId , FlowMonitor :: FlowStats >::

const_iterator i = stats.begin (); i != stats.end (); ++i

)

416 {

417 Ipv4FlowClassifier :: FiveTuple t = classifier -> FindFlow

(i->first);

418 std :: cout << "Flow " << i->first << " (" << t.

sourceAddress << " -> " << t. destinationAddress << ")

\n";

419 std :: cout << " Tx Bytes: " << i-> second . txBytes << "

\n";

420 std :: cout << " Rx Bytes: " << i-> second . rxBytes << "

\n";

421 std :: cout << " Throughput TCP: " << i-> second . rxBytes

* 8.0 / m_totalTime / 1024 << " Kbps\n";

422 // Para guardar los rsultados obtenidos en un fichero

423 fprintf (Alfa , " %f\n",i-> second . rxBytes * 8.0 /

m_totalTime / 1024);

424 }

425 fclose (Alfa);

426

427 Simulator :: Destroy ();

428 m_timeEnd =clock ();

429 m_timeTotal =( m_timeEnd - m_timeStart )/( double )

CLOCKS_PER_SEC ;

430 std :: cout << "The time of the simulation is: " <<

m_timeTotal << "\n";

431 return 0;

432 }

433

434 /** @brief Método para controlar que una entrada tenga valor

numérico .

435 @param Cadena array de caracteres con los valores a

controlar .

436 @pre No aplica .

437 @post No aplica .

438 @return -1 si no es numérico , y su valor si es numérico .

439 */

440 int esNumerico (char Cadena [])

441 {

442 if (( Cadena [0] == 48) && ( strlen ( Cadena ) == 1))

121

443 {

444 return 0;

445 }

446 else

447 {

448 return (atoi( Cadena ) == 0)? -1 : atoi( Cadena );

449 }

450 }

451

452

453 /** Metodo main.

454 * @brief Punto de entrada del programa que lanza la simulacion .

455 * @param argc Numero de argumentos recibidos como parametro de

la simulacion . Son los argumentos defectivos definidos en el

script .

456 * @param argv Vector con los argumentos recibidos como

parametro de la simulacion .

457 * @return 0 si se ha ejecutado correctamente .

458 */

459 int main (int argc , char *argv [])

460 {

461 int distances [3];

462 distances [0] = 50;

463 distances [1] = 100;

464 distances [2] = 125;

465 int servers [3];

466 servers [0] = 44;

467 servers [1] = 12;

468 servers [2] = 6;

469

470 char buffer [100];

471 char mode [12];

472 sprintf (mode ,"TCP");

473

474 do {

475 std :: cout << "\n Numero de simulaciones :" << "\r\n";

476 // Recogemos el número

477 std :: cin >> buffer ;

478 } while (! esNumerico ( buffer ));

479

480 int trials = atoi( buffer );

122

481 int tests = length ( distances );

482

483 sprintf (buffer , "mkdir -p simulates ");

484 system ( buffer );

485 sprintf (buffer , "rm -r -f simulates/ %s", mode);

486 system ( buffer );

487 sprintf (buffer , "mkdir -p simulates/ %s", mode);

488 system ( buffer );

489

490 for(int i=1; i <= trials ; i++){

491

492 std :: cout << "\n ### TRIAL " << i << " \r\n";

493

494 char seed [12];

495 sprintf (seed , " %d", i);

496

497 sprintf (buffer , "mkdir -p simulates/ %s/ %s", mode , seed

);

498 system ( buffer );

499

500 for (int j =0; j<tests; j++){

501

502 char distance [12];

503 sprintf (distance , " %d", distances [j]);

504 char server [12];

505 sprintf (server , " %d", servers [j]);

506

507 MeshTestTCP t;

508 t. Configure (argc , argv ,

509 seed , distance , server );

510 t.Run ();

511

512 char nodes [12];

513 sprintf (nodes , " %d", t. GetCalculatedNodes ());

514

515 // Guardar los archivos resultantes

516 sprintf (buffer , "mkdir -p simulates/ %s/ %s/ nodos_ %s

/", mode , seed , nodes);

517 system ( buffer );

518

123

519 sprintf (buffer , "cp mp -*. pcap simulates/ %s/ %s/

nodos_ %s/", mode , seed , nodes);

520 system ( buffer );

521 sprintf (buffer , "rm mp -*. pcap");

522 system ( buffer );

523 sprintf (buffer , "cp mp. routes simulates/ %s/ %s/

nodos_ %s/", mode , seed , nodes);

524 system ( buffer );

525 sprintf (buffer , "rm mp. routes ");

526 system ( buffer );

527 sprintf (buffer , "cp *. xls simulates/ %s/ %s/ nodos_ %s

/", mode , seed , nodes);

528 system ( buffer );

529 sprintf (buffer , "rm *. xls");

530 system ( buffer );

531 }

532 }

533

534 return 0;

535 }

124

D.2. pfc_udp.ccCódigo del programa pfc_udp.cc, el cual implementa tráfico UDP.

1 /**@file pfc_udp .cc

2 @author Antonio Conejero Diaz

3 @version 2.0

4 @date 23 -06 -2014

5 */

6

7 # include <iostream >

8 # include <cmath >

9 # include <sstream >

10 # include <fstream >

11 # include <stdio.h> // Para escribir los resultados obtenidos en

un fichero de texto

12

13 // Cabeceras para crear la red y las caracteristicas de los

nodos

14 # include "ns3/mesh - module .h"

15 # include "ns3/mesh - helper .h"

16 # include "ns3/aodv - module .h"

17 # include "ns3/core - module .h"

18 # include "ns3/wifi - module .h"

19

20

21 // Cabeceras para adaptar las caracteristicas del canal y

asignar la mobilidad

22 # include "ns3/yans -wifi - helper .h"

23 # include "ns3/nqos -wifi -mac - helper .h"

24 # include "ns3/ssid.h"

25 # include "ns3/internet -stack - helper .h"

26

27 // Cabeceras para asignales las direcciones IP y la torre de

protocolos a los nodos

28 # include "ns3/network - module .h"

29 # include "ns3/internet - module .h"

30 # include "ns3/ipv4 -address - helper .h"

31 # include "ns3/ipv4 -global -routing - helper .h"

32

33 // Cabeceras para la movilidad

125

34 # include "ns3/mobility - module .h"

35 # include "ns3/mobility - helper .h"

36

37 // Cabeceras para la transmision UDP

38 # include "ns3/packet -sink.h"

39 # include "ns3/ applications - module .h"

40

41 // Cabecera para monitorizar las transmisiones realizadas entre

los nodos

42 # include "ns3/flow -monitor - module .h"

43

44 // Calcular la longitud de un array

45 # define length (x) ( sizeof (x)/ sizeof (x[0]))

46

47 using namespace ns3;

48

49

50

51 NS_LOG_COMPONENT_DEFINE (" TestMeshScript ");

52

53 /** @brief Clase compuesta por los metodos y atributos

necesarios para realizar la simulacion .

54 * @see m_nodes

55 * @see m_totalTime

56 * @see m_channel

57 * @see m_pcap

58 * @see m_seed

59 * @see m_defaultSeed

60 * @see m_client

61 * @see m_server

62 * @see m_servPort

63 * @see m_printRoutes

64 * @see m_distance

65 * @see m_timeTotal

66 * @see m_timeStart

67 * @see m_timeEnd

68 * @see CreateNodes ()

69 * @see Configure ()

70 * @see InstallInternetStack ()

71 * @see InstallApplication ()

72 * @see Run ()

126

73 */

74 class MeshTestUDP

75 {

76 // Public method

77 public :

78 /** @brief Constructor */

79 MeshTestUDP ();

80

81 /** @brief Define el metodo ’Configure ()’ y lo expone

como metodo publico

82 * @see Configure ()

83 */

84 void Configure (int argc , char ** argv , char* seed ,

char* distance , char* server );

85

86 /** @brief Define el metodo ’Run ()’ y lo expone como

metodo publico

87 * @see Run ()

88 */

89 int Run ();

90

91 /** @brief Define el metodo ’GetCalculatedNodes ()’ y lo

expone como metodo publico

92 * @see GetCalculatedNodes ()

93 */

94 int GetCalculatedNodes ();

95

96 // Private attributes

97 private :

98 /// @brief Numero de nodos definidos en la red de la

simulacion

99 int m_nodes ;

100 /// @brief Tiempo de la simulacion

101 double m_totalTime ;

102 /// @brief Frecuencia del canal

103 int m_channel ;

104 /// @brief Indica si se desea exportar la captura de

los paquetes en ficheros de formato pcap

105 bool m_pcap ;

106 /// @brief Numero de semilla

107 int m_seed ;

127

108 /// @brief Semilla por defecto

109 int m_defaultSeed ;

110 /// @brief Numero de nodo escogido como cliente en la

simulacion

111 int m_client ;

112 /// @brief Numero de nodo escogido como servidor en la

simulacion

113 int m_server ;

114 /// @brief Numero de puerto del servidor

115 uint16_t m_servPort ;

116 /// @brief Indica si se desea exportar la tabla de

rutas de los nodos en ficheros de texto plano

117 bool m_printRoutes ;

118

119 /// @brief Distancia de separacion entre los nodos que

conforman la red de simulacion

120 int m_distance ;

121

122 /// @brief Objeto para controlar la duracion total de

la simulacion

123 float m_timeTotal ;

124 /// @brief Objeto para controlar el comienzo de la

simulacion

125 float m_timeStart ;

126 /// @brief Objeto para controlar el fin de la

simulacion

127 float m_timeEnd ;

128 /// @brief Contenedor de los nodos de la red

129 NodeContainer nodes;

130 /// @brief Contenedor de los dispositivos asociados a

los nodos de la red

131 NetDeviceContainer meshDevices ;

132 /// @brief Contenedor de las interfaces asociadas a los

dispositivos de la red

133 Ipv4InterfaceContainer interfaces ;

134

135 WifiHelper mesh;

136

137 // Private methods

138 private :

139 /** @brief Define el metodo ’CreateNodes ()’

128

140 * @see CreateNodes ()

141 */

142 void CreateNodes ();

143

144 /** @brief Define el metodo ’InstallInternetStack ()’

145 * @see InstallInternetStack ()

146 */

147 void InstallInternetStack ();

148

149 /** @brief Define el metodo ’InstallApplication ()’

150 * @see InstallApplication ()

151 */

152 void InstallApplication ();

153 };

154

155

156 /** Metodo Constructor por defecto .

157 * @brief Establece los valores por defecto de las variables .

158 */

159 MeshTestUDP :: MeshTestUDP () : m_nodes (8) ,

160 m_totalTime (120.0) ,

161 m_channel (3) ,

162 m_pcap (true),

163 m_seed (23) ,

164 m_defaultSeed (9) ,

165 m_client (0) ,

166 m_server (1) ,

167 m_servPort (5001) ,

168 m_printRoutes (true),

169 m_distance (100)

170 {

171 // NOTHING TO DO HERE

172 }

173

174

175 /** Metodo GetCalculatedNodes ()

176 * @brief Obtiene el numero de nodos definidos en la red a

simular

177 * @return int Numero de nodos definidos en la red

178 */

179 int MeshTestUDP :: GetCalculatedNodes (){

129

180 return m_nodes ;

181 }

182

183

184 /** Metodo Configure .

185 * @brief Recibe los argumentos pasados como parametros de la

simulacion y establece los datos de entrada de NS -3.

186 * @param argc Numero de argumentos recibidos como parametro de

la simulacion . Son los argumentos defectivos definidos en el

script .

187 * @param argv Vector con los argumentos recibidos como

parametro de la simulacion .

188 * @param seed Semilla para la generacion de simulaciones

aleatorias

189 * @param distance Distancias definidas para la separacion de

los nodos que conforman la red de la simulacion

190 * @param server Numero de nodo elegido con el cual se

comunicaran los nodos - clientes . Dicho nodo hara el trabajo de

nodo - servidor

191 */

192 void MeshTestUDP :: Configure (int argc , char *argv [], char *seed

, char *distance , char * server )

193 {

194

195 std :: cout << " Configure >>>>> \n";

196

197 CommandLine cmd;

198

199 SeedManager :: SetSeed ( m_defaultSeed );

200

201 Config :: SetDefault ("ns3 :: WifiRemoteStationManager ::

RtsCtsThreshold ",StringValue ("3000"));

202

203 Config :: SetDefault ("ns3 :: WifiRemoteStationManager ::

FragmentationThreshold ", StringValue ("3000"));

204

205 cmd. AddValue ("nodes", " Number of nodes in the network [

Default 8]", m_nodes );

206 m_server = atoi( server );

207 cmd. AddValue (" server ", "Node server [ Default 1]", m_server )

;

130

208 cmd. AddValue (" client ", "Node client [ Default 0]", m_client )

;

209 cmd. AddValue ("time", " Simulation time , seconds [120 s]",

m_totalTime );

210 cmd. AddValue (" channel ", " Select channel of transmision [

Default 3]", m_channel );

211 cmd. AddValue ("pcap", " Enable PCAP traces on interfaces . [

Default 1]", m_pcap );

212 m_seed = atoi(seed);

213 cmd. AddValue ("seed", "Set the seed for random values [

Default 9]", m_seed );

214 cmd. AddValue (" printRoutes ", "Print routing table dumps.",

m_printRoutes );

215 m_distance = atoi( distance );

216 cmd. AddValue (" distance ", " distance between nodes [ Default

100]",m_distance );

217 cmd.Parse (argc , argv);

218 NS_LOG_DEBUG (" Number of nodes: " << m_nodes );

219 NS_LOG_DEBUG (" Simulation time: " << m_totalTime << " s");

220

221 std :: cout << "\t Simulation time: " << m_totalTime << "\n";

222 std :: cout << "\t Seed: " << m_seed << "\n";

223 std :: cout << "\t Server : " << m_server << "\n";

224 std :: cout << "\t Distance : " << m_distance << "\n";

225

226 std :: cout << " Configure <<<<<< \n";

227 }

228

229

230 /** Metodo CreateNodes .

231 * @brief Crea el numero de nodos que conforman la red , las

caracteristicas del canal , la posicion de los nodos y el

algoritmo de movimiento de los nodos.

232 */

233 void MeshTestUDP :: CreateNodes () {

234

235 std :: cout << " CreateNodes >>>>> \n";

236

237 // Calcula los nodos que han de crearse en funcion de la

distancia introducida

238 int nodosfila = 500 / m_distance ;

131

239 m_nodes = nodosfila * nodosfila ;

240 NS_LOG_DEBUG (" Number of nodes: " << m_nodes );

241 // Parameters Loss Propagation Model

242 double m_referenceDistance = 1.0; // m

243 double m_exponent = 1.7;

244 double m_referenceLoss = 40.178882771; // L0 = 20 log (4 pi

feqChann3 / 3 exp8)

245 double m_EnergyDet = -86.0;

246 double m_ccath = -99.0;

247 double m_txpower = 18.0; // dbm

248

249 SeedManager :: SetRun ( m_seed );

250 NS_LOG_INFO (" Building chain topology .");

251 nodes. Create ( m_nodes );

252 mesh. SetStandard ( WIFI_PHY_STANDARD_80211b );

253 NqosWifiMacHelper wifiMac = NqosWifiMacHelper :: Default ();

254 // Configure YansWifiChannel

255 YansWifiPhyHelper wifiPhy = YansWifiPhyHelper :: Default ();

256

257 wifiPhy .Set(" EnergyDetectionThreshold ", DoubleValue (

m_EnergyDet )); // defulat val is -96 dBm

258 wifiPhy .Set(" CcaMode1Threshold ", DoubleValue ( m_ccath )); //

default val is -99 dBm

259 wifiPhy .Set(" TxGain ", DoubleValue (1.0)); // Use 5.0 to

extend range to about 300 meters

260 wifiPhy .Set(" RxGain ", DoubleValue (1.0)); // Use 5.0 to

extend range to about 300 meters

261 wifiPhy .Set(" TxPowerLevels ", UintegerValue (1) );

262 wifiPhy .Set(" TxPowerEnd ", DoubleValue ( m_txpower ) ); //

default val is 16.0206 dBm

263 wifiPhy .Set(" TxPowerStart ", DoubleValue ( m_txpower ) ); //

default val is 16.0206 dBm

264 wifiPhy .Set(" RxNoiseFigure ", DoubleValue (7.0) ); // defulat

val is 7dB

265 wifiPhy .Set(" ChannelNumber ", UintegerValue ( m_channel ));

266

267

268

269 YansWifiChannelHelper wifiChannel ;

270 wifiChannel . AddPropagationLoss ("ns3 ::

LogDistancePropagationLossModel "," Exponent ",DoubleValue (

132

m_exponent )," ReferenceDistance ",DoubleValue (

m_referenceDistance )," ReferenceLoss ",DoubleValue (

m_referenceLoss ));

271 wifiChannel . SetPropagationDelay ("ns3 ::

ConstantSpeedPropagationDelayModel ","Speed",DoubleValue

(3.0 e8));

272 wifiChannel . AddPropagationLoss ("ns3 ::

RandomPropagationLossModel "," Variable ", StringValue ("ns3

:: UniformRandomVariable [Min =27.0| Max =43.0] "));

273 wifiPhy . SetChannel ( wifiChannel . Create ());

274 Ssid ssid = Ssid ("wifi - default ");

275 mesh. SetRemoteStationManager ("ns3 :: ConstantRateWifiManager

", " DataMode ", StringValue (" DsssRate1Mbps "));

276 wifiMac . SetType ("ns3 :: AdhocWifiMac ");

277 meshDevices = mesh. Install (wifiPhy , wifiMac , nodes);

278

279 // POSICIONAMIENTO DE LOS NODOS

280 MobilityHelper mobility ;

281 mobility . SetPositionAllocator ("ns3 ::

RandomDiscPositionAllocator ",

282 "X", StringValue ("150.0"),

283 "Y", StringValue ("150.0"),

284 "Rho", StringValue ("ns3 ::

UniformRandomVariable [Min =0|

Max =30]"));

285 mobility . SetMobilityModel ("ns3 :: RandomWalk2dMobilityModel "

,

286 "Mode", StringValue ("Time"),

287 "Time", StringValue ("2s"),

288 "Speed", StringValue ("ns3 ::

ConstantRandomVariable [ Constant

=1.0]"),

289 " Bounds ", StringValue ("

0|200|0|200 "));

290 mobility . InstallAll ();

291

292 if ( m_pcap ){

293 std :: cout << "\t CreateNodes : m_pcap ->" << m_pcap << "\

n";

294 wifiPhy . EnablePcapAll (std :: string ("mp -"));

295 }

133

296

297 std :: cout << " CreateNodes <<<<< \n";

298 }

299

300

301 /** Metodo InstallInternetstack .

302 * @brief Instala la pila de protocolos de Internet a los nodos

de la red , y les proporciona encaminamiento . Ademñas de

definir las direcciones Ip de los mismos .

303 */

304 void MeshTestUDP :: InstallInternetStack ()

305 {

306

307 std :: cout << " InstallInternetStack >>>>> \n";

308

309 NS_LOG_INFO (" Installing internet stack on all nodes and

assigning IP Addresses .");

310 AodvHelper aodv;

311 InternetStackHelper internetStack ;

312 // Usamos el AODV para proporcionar encaminamiento sin esto

el nodo no ve a los nodos que no alcance fisicamente

313 internetStack . SetRoutingHelper (aodv);

314 internetStack . Install (nodes);

315 Ipv4AddressHelper address ;

316 address . SetBase (" 10.0.0.0 ", " 255.255.0.0 ");

317 interfaces = address . Assign ( meshDevices );

318

319 // Imprimimos las tablas de rutas

320 if ( m_printRoutes )

321 {

322 Ptr < OutputStreamWrapper > routingStream = Create <

OutputStreamWrapper > ("mp. routes ", std :: ios :: out);

323 aodv. PrintRoutingTableAllAt ( Seconds (8) , routingStream

);

324 }

325

326 std :: cout << " InstallInternetStack <<<<<< \n";

327 }

328

329

330 /** Metodo InstallApplication .

134

331 * @brief Instala el protocolo a nivel de aplicacion en los

nodos seleccionados

332 */

333 void MeshTestUDP :: InstallApplication ()

334 {

335

336 std :: cout << " InstallApplication >>>>> \n";

337

338 NS_LOG_INFO (" Create applications .");

339

340 // Definimos el tamaño de paquete

341 uint32_t nPackets = 127;

342

343 Config :: SetDefault ("ns3 :: WifiRemoteStationManager ::

RtsCtsThreshold ",StringValue ("6000"));

344

345 Config :: SetDefault ("ns3 :: WifiRemoteStationManager ::

FragmentationThreshold ", StringValue ("6000"));

346

347

348 /// UDP protocol

349

350 Config :: SetDefault ("ns3 :: UdpSocket :: RcvBufSize ",

UintegerValue (900000) );

351 Address sinkLocalAddress ( InetSocketAddress ( Ipv4Address ::

GetAny (), m_servPort ));

352 PacketSinkHelper UDPsinkHelper ("ns3 :: UdpSocketFactory ",

sinkLocalAddress );

353 ApplicationContainer UDPsinkApp = UDPsinkHelper . Install (

nodes.Get ( m_server ));

354 UDPsinkApp .Start ( Seconds (0.001) );

355 UDPsinkApp .Stop ( Seconds ( m_totalTime ));

356 // Creamos la aplicacion OnOff para mandar datos UDP

357 OnOffHelper UDPsourceHelper ("ns3 :: UdpSocketFactory ",

Address ());

358

359 char buffer [50];

360 sprintf (buffer , "ns3 :: ConstantRandomVariable [ Constant= %f]"

, m_totalTime );

361

135

362 UDPsourceHelper . SetAttribute (" OnTime ", StringValue ( buffer

));

363 UDPsourceHelper . SetAttribute (" OffTime ", StringValue ("ns3

:: ConstantRandomVariable [ Constant =0]"));

364 AddressValue remoteAddress ( InetSocketAddress ( interfaces .

GetAddress ( m_server ), m_servPort ));

365 UDPsourceHelper . SetAttribute (" Remote ", remoteAddress );

366 UDPsourceHelper . SetAttribute (" DataRate ", DataRateValue (

DataRate ("250 kbps")));

367 UDPsourceHelper . SetAttribute (" PacketSize ", UintegerValue (

nPackets ));

368 ApplicationContainer UDPsourceApp ;

369

370 // Calculamos el 10 % de los nodos que van a transmitir

371 int tx = 0.1 * m_nodes ;

372

373 int i=0;

374 do{

375 UDPsourceApp .Add ( UDPsourceHelper . Install (nodes.Get(i)

));

376 i=i+8;

377 } while (i<tx);

378

379 UDPsourceApp .Start ( Seconds (0.005) );

380 UDPsourceApp .Stop ( Seconds ( m_totalTime ));

381

382 std :: cout << " InstallApplication <<<<<< \n";

383 }

384

385

386 /** Metodo Run.

387 * @brief Ejecutar la simulacion en NS -3, y capturar los

resultados obtenidos en la simulacion .

388 * @return 0 si se ha ejecutado correctamente .

389 */

390 int MeshTestUDP :: Run ()

391 {

392 CreateNodes ();

393 InstallInternetStack ();

394 InstallApplication ();

395 m_timeStart =clock ();

136

396 Simulator :: Stop ( Seconds ( m_totalTime ));

397

398 // Instalamos FlowMonitor en todos los nodos

399 FlowMonitorHelper flowmon ;

400 Ptr < FlowMonitor > monitor = flowmon . InstallAll ();

401

402 Simulator :: Run ();

403

404 monitor -> CheckForLostPackets ();

405 Ptr < Ipv4FlowClassifier > classifier = DynamicCast <

Ipv4FlowClassifier > ( flowmon . GetClassifier ());

406 std ::map <FlowId , FlowMonitor :: FlowStats > stats = monitor ->

GetFlowStats ();

407

408 // Creamos el fichero donde se guardaran los resultados

409 FILE * Alfa = fopen (" Resultados perdidas UDP.xls", "a+t");

410

411 for (std ::map <FlowId , FlowMonitor :: FlowStats >::

const_iterator i = stats.begin (); i != stats.end (); ++i

)

412 {

413 Ipv4FlowClassifier :: FiveTuple t = classifier -> FindFlow

(i->first);

414 std :: cout << "Flow " << i->first << " (" << t.

sourceAddress << " -> " << t. destinationAddress << ")

\n";

415 std :: cout << " Tx Packets : " << i-> second . txPackets

<< "\n";

416 std :: cout << " Rx Packets : " << i-> second . rxPackets

<< "\n";

417 std :: cout << " Lost Packets : " << (i-> second .

txPackets ) - (i-> second . rxPackets ) << "\n";

418 // Para guardar los rsultados obtenidos en un fichero

419 fprintf (Alfa , " %d\n" ,(i-> second . txPackets ) - (i->

second . rxPackets ));

420 }

421 fclose (Alfa);

422

423 Simulator :: Destroy ();

424 m_timeEnd =clock ();

137

425 m_timeTotal =( m_timeEnd - m_timeStart )/( double )

CLOCKS_PER_SEC ;

426 std :: cout << "The time of the simulation is: " <<

m_timeTotal << "\n";

427 return 0;

428 }

429

430

431 /** @brief Método para controlar que una entrada tenga valor

numérico .

432 @param Cadena array de caracteres con los valores a

controlar .

433 @pre No aplica .

434 @post No aplica .

435 @return -1 si no es numérico , y su valor si es numérico .

436 */

437 int esNumerico (char Cadena [])

438 {

439 if (( Cadena [0] == 48) && ( strlen ( Cadena ) == 1))

440 {

441 return 0;

442 }

443 else

444 {

445 return (atoi( Cadena ) == 0)? -1 : atoi( Cadena );

446 }

447 }

448

449

450 /** Metodo main.

451 * @brief Punto de entrada del programa que lanza la simulacion .

452 * @param argc Numero de argumentos recibidos como parametro de

la simulacion . Son los argumentos defectivos definidos en el

script .

453 * @param argv Vector con los argumentos recibidos como

parametro de la simulacion .

454 * @return 0 si se ha ejecutado correctamente .

455 */

456 int main (int argc , char *argv [])

457 {

458 int distances [3];

138

459 distances [0] = 50;

460 distances [1] = 100;

461 distances [2] = 125;

462 int servers [3];

463 servers [0] = 44;

464 servers [1] = 12;

465 servers [2] = 6;

466

467 char buffer [100];

468 char mode [12];

469 sprintf (mode ,"UDP");

470

471 do {

472 std :: cout << "\n Numero de simulaciones :" << "\r\n";

473 // Recogemos el número

474 std :: cin >> buffer ;

475 } while (! esNumerico ( buffer ));

476

477 int trials = atoi( buffer );

478 int tests = length ( distances );

479

480 sprintf (buffer , "mkdir -p simulates ");

481 system ( buffer );

482 sprintf (buffer , "rm -r -f simulates/ %s", mode);

483 system ( buffer );

484 sprintf (buffer , "mkdir -p simulates/ %s", mode);

485 system ( buffer );

486

487 for(int i=1; i <= trials ; i++){

488

489 std :: cout << "\n ### TRIAL " << i << " \r\n";

490

491 char seed [12];

492 sprintf (seed , " %d", i);

493

494 sprintf (buffer , "mkdir -p simulates/ %s/ %s", mode , seed

);

495 system ( buffer );

496

497 for (int j =0; j<tests; j++){

498

139

499 char distance [12];

500 sprintf (distance , " %d", distances [j]);

501 char server [12];

502 sprintf (server , " %d", servers [j]);

503

504 MeshTestUDP t;

505 t. Configure (argc , argv ,

506 seed , distance , server );

507 t.Run ();

508

509 char nodes [12];

510 sprintf (nodes , " %d", t. GetCalculatedNodes ());

511

512 // Guardar los archivos resultantes

513 sprintf (buffer , "mkdir -p simulates/ %s/ %s/ nodos_ %s

/", mode , seed , nodes);

514 system ( buffer );

515

516 sprintf (buffer , "cp mp -*. pcap simulates/ %s/ %s/

nodos_ %s/", mode , seed , nodes);

517 system ( buffer );

518 sprintf (buffer , "rm mp -*. pcap");

519 system ( buffer );

520 sprintf (buffer , "cp mp. routes simulates/ %s/ %s/

nodos_ %s/", mode , seed , nodes);

521 system ( buffer );

522 sprintf (buffer , "rm mp. routes ");

523 system ( buffer );

524 sprintf (buffer , "cp *. xls simulates/ %s/ %s/ nodos_ %s

/", mode , seed , nodes);

525 system ( buffer );

526 sprintf (buffer , "rm *. xls");

527 system ( buffer );

528 }

529 }

530

531 return 0;

532 }

140

D.3. pfcscript.shCódigo del script pfcscript.sh, el cual ejecuta de manera automática los ficheros

pfc_tcp.cc y pfc_udp.cc.

1 #!/ bin/sh

2 echo Run TEST

3 #run experiments

4 start=‘date "+ %s"‘

5

6 # estamos en /ns -3- dev/ scratch

7 cd ..

8 rm -r -f simulates

9

10 # estamos en /ns -3- dev/

11 echo "Start Simulation TCP"

12 ./ waf --run " pfc_tcp --pcap =0 -channel =6 -time =60"

13 echo "Start Simulation UDP"

14 ./ waf --run " pfc_udp --pcap =0 -channel =6 -time =60"

15 end=‘date "+ %s"‘

16 elapsed =$((end -start))

17 echo Elapsed time testing 1: $elapsed seconds

18 echo

19 echo " Finish simulation "

141

D.4. lr-wpan.ccCódigo del programa lr-wpan.cc, el cual implementa tráfico lr-wpan.

1 /**@file lr -wpan.cc

2 @author Antonio Conejero Diaz

3 @version 1.0

4 @date 23 -06 -2014

5 */

6

7 # include <ns3/test.h>

8 # include <ns3/log.h>

9 # include <ns3/ callback .h>

10 # include <ns3/ packet .h>

11 # include <ns3/ simulator .h>

12 # include <ns3/lr -wpan -error -model.h>

13 # include <ns3/ propagation -loss -model.h>

14 # include <ns3/lr -wpan -net - device .h>

15 # include <ns3/spectrum -value.h>

16 # include <ns3/lr -wpan -spectrum -value - helper .h>

17 # include <ns3/lr -wpan -mac.h>

18 # include <ns3/node.h>

19 # include <ns3/net - device .h>

20 # include <ns3/single -model -spectrum - channel .h>

21 # include <ns3/mac16 - address .h>

22 # include <ns3/constant -position -mobility -model.h>

23 # include <ns3/ uinteger .h>

24 # include <ns3/ nstime .h>

25 # include <ns3/abort.h>

26 # include <ns3/command -line.h>

27 # include <ns3/ gnuplot .h>

28 # include <ns3/lr -wpan - module .h>

29 # include "ns3/netanim - module .h"

30

31 # include <fstream >

32 # include <iostream >

33 # include <string >

34 # include <vector >

35

36 using namespace ns3;

37 using namespace std;

142

38

39 static uint32_t g_received = 0;

40

41 NS_LOG_COMPONENT_DEFINE (" LrWpanErrorDistancePlot ");

42

43

44 /** Metodo LrWpanErrorDistanceCallback .

45 * @brief Metodo que calcula el numero de paquetes recibidos con

exito

46 * @param params Parametros sobre la recepcion del paquete

47 * @param p Paquete enviado

48 */

49 static void

50 LrWpanErrorDistanceCallback ( McpsDataIndicationParams params ,

Ptr <Packet > p)

51 {

52 g_received ++;

53 }

54

55

56 /** Metodo main.

57 * @brief Punto de entrada del programa que lanza la simulacion .

58 * @param argc Numero de argumentos recibidos como parametro de

la simulacion . Son los argumentos defectivos definidos en el

script .

59 * @param argv Vector con los argumentos recibidos como

parametro de la simulacion .

60 * @return 0 si se ha ejecutado correctamente .

61 */

62 int main (int argc , char *argv [])

63 {

64 std :: ostringstream os;

65 std :: ofstream berfile ("802.15.4 - psr - distance .plt");

66

67 int minDistance = 1; // minima distancia de separacion inicial

entre los nodos

68 int maxDistance = 200; // metros

69 int increment = 1; // incremento de la distancia en metros

70 int maxPackets = 1000; // maximo numero de paquetes a enviar

71 int packetSize = 50; // 114 es el valor máximo que puede tomar

72 double txPower = 0; // potencia de transmision

143

73 uint32_t channelNumber = 11; // frecuecia del canal en el que

transmitir

74 bool pcap = true; // booleano para determinar si querermos

generar los paquetes pcap de la simulacion

75

76

77

78 CommandLine cmd;

79

80 cmd. AddValue (" txPower ", " transmit power (dBm)", txPower );

81 cmd. AddValue (" packetSize ", " packet (MSDU) size (bytes)",

packetSize );

82 cmd. AddValue (" channelNumber ", " channel number ",

channelNumber );

83 cmd. AddValue ("pcap", " Enable PCAP traces on interfaces . [

Default 1]", pcap);

84

85

86 cmd.Parse (argc , argv);

87

88 os << " Packet (MSDU) size = " << packetSize << " bytes; tx

power = " << txPower << " dBm; channel = " << channelNumber

;

89

90 Gnuplot psrplot = Gnuplot ("802.15.4 - psr - distance .eps");

91 Gnuplot2dDataset psrdataset ("802.15.4 - psr -vs - distance ");

92

93 Ptr <Node > n0 = CreateObject <Node > ();

94 Ptr <Node > n1 = CreateObject <Node > ();

95 Ptr < LrWpanNetDevice > dev0 = CreateObject < LrWpanNetDevice > ();

96 Ptr < LrWpanNetDevice > dev1 = CreateObject < LrWpanNetDevice > ();

97 dev0 -> SetAddress ( Mac16Address ("00:01"));

98 dev1 -> SetAddress ( Mac16Address ("00:02"));

99 Ptr < SingleModelSpectrumChannel > channel = CreateObject <

SingleModelSpectrumChannel > ();

100 Ptr < LogDistancePropagationLossModel > model = CreateObject <

LogDistancePropagationLossModel > ();

101 channel -> AddPropagationLossModel (model);

102 dev0 -> SetChannel ( channel );

103 dev1 -> SetChannel ( channel );

104 n0 -> AddDevice (dev0);

144

105 n1 -> AddDevice (dev1);

106 Ptr < ConstantPositionMobilityModel > mob0 = CreateObject <

ConstantPositionMobilityModel > ();

107 dev0 -> GetPhy () ->SetMobility (mob0);

108 Ptr < ConstantPositionMobilityModel > mob1 = CreateObject <

ConstantPositionMobilityModel > ();

109 dev1 -> GetPhy () ->SetMobility (mob1);

110

111 LrWpanSpectrumValueHelper svh;

112 Ptr < SpectrumValue > psd = svh. CreateTxPowerSpectralDensity (

txPower , channelNumber );

113 dev0 -> GetPhy () -> SetTxPowerSpectralDensity (psd);

114

115 McpsDataIndicationCallback cb0;

116 cb0 = MakeCallback (& LrWpanErrorDistanceCallback );

117 dev1 -> GetMac () -> SetMcpsDataIndicationCallback (cb0);

118

119 McpsDataRequestParams params ;

120 params . m_srcAddrMode = SHORT_ADDR ;

121 params . m_dstAddrMode = SHORT_ADDR ;

122 params . m_dstPanId = 0;

123 params . m_dstAddr = Mac16Address ("00:02");

124 params . m_msduHandle = 0;

125 params . m_txOptions = 0;

126

127 Ptr <Packet > p;

128 mob0 -> SetPosition ( Vector (0 ,0 ,0));

129 mob1 -> SetPosition ( Vector ( minDistance ,0 ,0));

130 for (int j = minDistance ; j < maxDistance ; )

131 {

132 for (int i = 0; i < maxPackets ; i++)

133 {

134 p = Create <Packet > ( packetSize );

135 Simulator :: Schedule ( Seconds (i),

136 & LrWpanMac :: McpsDataRequest ,

137 dev0 -> GetMac (), params , p);

138 }

139

140 // Tracing pcap

141 LrWpanHelper lrWpanHelper ;

142 if(pcap){

145

143 lrWpanHelper . EnablePcapAll (std :: string ("lr -wpan"), true

);

144 }

145

146 Simulator :: Run ();

147 NS_LOG_DEBUG (" Received " << g_received << " packets for

distance " << j);

148 psrdataset .Add (j, g_received / 1000.0) ;

149 g_received = 0;

150 j += increment ;

151 mob1 -> SetPosition ( Vector (j ,0 ,0));

152 }

153

154

155 psrplot . AddDataset ( psrdataset );

156

157 psrplot . SetTitle (os.str ());

158 psrplot . SetTerminal (" postscript eps color enh \" Times -

BoldItalic \"");

159 psrplot . SetLegend (" distance (m)", " Packet Success Rate (PSR)

");

160 psrplot . SetExtra ("set xrange [0:200]\ n\

161 set yrange [0:1]\ n\

162 set grid\n\

163 set style line 1 linewidth 5\n\

164 set style increment user");

165 psrplot . GenerateOutput ( berfile );

166 berfile .close ();

167

168

169

170 Simulator :: Destroy ();

171 return 0;

172 }

146