Diseño de modelos de hardware y firmware para implementar un entorno de …laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Tesis-Grado... · 2020. 1. 23. · Este capitulo hace una introducción

UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE INGENIERÍA ELECTRÓNICA

MEMORIA DE LA TESIS DE GRADO

Diseño de modelos de hardware yfirmware para implementar un entornode simulación de algoritmos para WSN

Autor:Leonardo Ariel Giaccone

Director:Ing. Federico Giordano Zacchigna

Codirector:Dr. Ing. Ariel Lutenberg

Jurados:Dr. Ing. Pablo Gomez (FIUBA)

Ing. Juan Manuel Cruz (FIUBA, UTN-FRBA)Dr. Ing. Mariano Garcia Inza

Este trabajo fue realizado en la Ciudad Autónoma de Buenos Aires, entreFebrero de 2019 y Diciembre de 2019.

III

Resumen

El trabajo realizado presenta el diseño y desarrollo de un entorno desimulación para Redes Inalámbricas de Sensores (WSN, del inglés, WirelessSensor Networks) que utiliza un enfoque modular para el modelo del nodoa simular. En particular, en este trabajo se eligió el nodo NodeMCU basado

en el SoC ESP8266 de Espressif para realizar los modelos y mostrar lametodología. Dicho entorno de simulación funciona sobre el popularsimulador de redes NS3. Se realizó con el objetivo de poder depurar

algoritmos distribuidos sin necesidad de realizar la implementación física dela red o reescribir el código a utilizar, reduciendo así, tiempo y costos

durante el desarrollo de un proyecto.

Para realizar este trabajo se debió estudiar por un lado el hardware y la capade firmware del nodo y por otro los distintos simuladores de redes

disponibles para luego realizar el modelo del nodo y diseñar una capa defirmware para dicho modelo.

V

Agradecimientos

En primer lugar quiero agradecer a Federico Zacchigna, director de tesis, y aAriel Lutenberg, co-director, por guiarme en la realización de esta tesis y portodo el tiempo que dedicaron a ayudarme a solucionar cada problema que sefue presentando. Sin ustedes no hubiera podido finalizar el trabajo.

A mis padres, Raul y Graciela, y a mis hermanos, Romina y Javier, quienes meenseñaron la importancia del esfuerzo, la dedicación y el compromiso paraalcanzar mis objetivos y por darme la fuerza para no bajar los brazos cuandomás lo necesité.

A mis abuelos, quienes hoy ya no están presentes, pero durante toda la ca-rrera se alegraban con cada parcial que aprobaba y me daban fuerza y apoyocuando no lo hacia. Sin duda hoy estarían muy contentos de verme terminaresta etapa.

A toda familia, gracias por el apoyo que me brindaron durante la carrera y laspalabras de aliento para ayudarme a terminar este trabajo en los momentosque más me costó.

A mis amigos de la infancia, ustedes son parte importante de mi vida desdehace más de 25 años y saben lo importante que es para mi poder terminar lacarrera. Gracias por todos los consejos, el apoyo y las veces que me bancaronque no estuviera presente en alguna reunión por quedarme estudiando.

A mis amigos de la facultad y del trabajo, con muchos de ustedes compartícursadas, noches de estudio, trabajos prácticos, discusiones, alegrías y frus-traciones. Les agradezco ya que haberlo compartido con ustedes hace quehoy sean todos buenos recuerdos que me generan risas y alegría.

A los miembros del jurado: Juan, Pablo y Mariano, por haber aceptado dedi-car su tiempo a evaluar este trabajo.

A todos ustedes, gracias!

VII

Índice general

Carátula I

Resumen III

Agradecimientos V

1. Introducción General 11.1. Redes Inalámbricas de Sensores (WSN) . . . . . . . . . . . . . 11.2. Simulación en WSN . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . 51.2.2. Problemática actual . . . . . . . . . . . . . . . . . . . . . 8

1.3. Motivación, objetivo y alcance . . . . . . . . . . . . . . . . . . . 81.3.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . 81.3.2. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3.3. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2. Introducción Específica 92.1. Introducción al entorno desarrollado . . . . . . . . . . . . . . . 92.2. El simulador Ns-3 . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1. Componentes básicos . . . . . . . . . . . . . . . . . . . 122.2.2. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3. Wi-Fi - El estándar 802.11 . . . . . . . . . . . . . . . . . . . . . 142.4. El nodo NodeMCU . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.1. El SoC ESP8266 . . . . . . . . . . . . . . . . . . . . . . . 17Microcontrolador y memoria . . . . . . . . . . . . . . . 17Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Radio y Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . 18Periféricos . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.2. El módulo ESP-12E . . . . . . . . . . . . . . . . . . . . . 182.4.3. La placa NodeMCU . . . . . . . . . . . . . . . . . . . . . 182.4.4. El firmware para el NodeMCU . . . . . . . . . . . . . . . 19

3. Diseño e Implementación 213.1. Estructura del entorno de simulación . . . . . . . . . . . . . . . 213.2. Componentes de la simulación . . . . . . . . . . . . . . . . . . 22

3.2.1. Simulación de la parte física . . . . . . . . . . . . . . . . 223.2.2. Simulación del firmware de los nodos . . . . . . . . . . 303.2.3. Estructura de soporte y archivos de configuración . . . 34

Archivos de configuración de la simulación . . . . . . . 34Herramientas auxiliares / scripts . . . . . . . . . . . . . 36Archivos de salida . . . . . . . . . . . . . . . . . . . . . 38

VIII

4. Ensayos y Resultados 434.1. Introducción a los ensayos . . . . . . . . . . . . . . . . . . . . . 434.2. Ensayo 1 - Hola mundo! . . . . . . . . . . . . . . . . . . . . . . 43

Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3. Ensayo 2 - Algoritmo de sincronización con 4 nodos . . . . . . 484.4. Ensayo 3 - Algoritmo de sincronización con 30 nodos . . . . . 524.5. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5. Conclusiones 555.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . 555.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

A. Calculo de pérdida por propagación con modelo Friis 57

B. Ejemplo de uso de un helper 59

C. APIs implementadas 61C.1. GPIO APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61C.2. Timer APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62C.3. UART APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63C.4. UDP APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64C.5. UDP APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

D. Manual de usuario 75D.1. Antes de empezar . . . . . . . . . . . . . . . . . . . . . . . . . . 75D.2. Preparar el entorno . . . . . . . . . . . . . . . . . . . . . . . . . 75D.3. Configurar la simulación . . . . . . . . . . . . . . . . . . . . . . 76D.4. Iniciar la simulación . . . . . . . . . . . . . . . . . . . . . . . . 77D.5. Archivos de salida . . . . . . . . . . . . . . . . . . . . . . . . . 78

Bibliografía 81

IX

Índice de figuras

1.1. Esquema de un nodo WSN. . . . . . . . . . . . . . . . . . . . . 21.2. Diseño en capas de abstracción. . . . . . . . . . . . . . . . . . . 31.3. Representacion de la capa HAL en una implementación sin SO

y otra con SO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4. Distintas topologías de redes WSN. . . . . . . . . . . . . . . . . 4

2.1. Esquema del entorno de simulación. . . . . . . . . . . . . . . . 92.2. Organización del simulador ns-3. Imagen tomada del manual

de ns-3 [30]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3. Capas de abstracción del modelo OSI. Imagen tomada de Geeks

for Geeks [31] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4. Modos de operación de una red Wi-Fi. . . . . . . . . . . . . . . 162.5. El nodo NodeMCU y sus principales componentes. . . . . . . 162.6. Diagrama de bloques del ESP8266. Imagen tomada de la hoja

de datos del ESP8266 [34]. . . . . . . . . . . . . . . . . . . . . . 17

3.1. Estructuras de archivos de interés. . . . . . . . . . . . . . . . . 223.2. Diagrama de flujo - scratch/WSN_sim.cc. . . . . . . . . . . 233.3. Estructura de archivos del firmware del nodo NodeMCU. . . . 313.4. Archivos de configuración de la simulación. . . . . . . . . . . . 353.5. Estructura modular jerárquica en el VCD. . . . . . . . . . . . . 383.6. Salida de la simulación. . . . . . . . . . . . . . . . . . . . . . . 383.7. Reportes de energía consumida. . . . . . . . . . . . . . . . . . . 393.8. Visualización del estado de los pines GPIO utilizando GTKWave. 393.9. Visualización de la simulación utilizando NetAnim. . . . . . . 403.10. Archivo de salida .pcap abierto con Wireshark. . . . . . . . . . 403.11. Archivo de salida de reporte de una UART. . . . . . . . . . . . 41

4.1. Esquema de la red del Ensayo 1. . . . . . . . . . . . . . . . . . 444.2. Diagramas de flujo de los nodos de el Ensayo 1. . . . . . . . . 444.3. Red implementada para el Ensayo 1. . . . . . . . . . . . . . . . 454.4. Salidas de la UART de los nodos AP (A) real y (B) simulado. . 464.5. Salidas de la UART de los nodos STA (A) real y (B) simulado. 474.6. Esquema de red del Ensayo 2. . . . . . . . . . . . . . . . . . . . 484.7. Esquema de intercambio de mensajes para sincronización. . . 484.8. Implementación de la red real para el Ensayo 2. . . . . . . . . 494.9. Extracto de la UART de cada nodo mostrando el nivel de topo-

logía de red. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.10. Sincronización de las señales en el osciloscopio. . . . . . . . . 504.11. Extracto de la UART de cada nodo simulado mostrando el ni-

vel de topología de red. . . . . . . . . . . . . . . . . . . . . . . . 51

X

4.12. Sincronización en nodos simulados visualizado con GtkWave. 514.13. Distribución de los nodos del Ensayo 3. Imagen tomada utili-

zando NetAnim. . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.14. Sincronización en nodos simulados del Ensayo 3 visualizado

con GtkWave. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

D.1. Archivos de configuración de la simulación. . . . . . . . . . . . 76D.2. Inicio de la simulación. . . . . . . . . . . . . . . . . . . . . . . . 77D.3. Salida de la simulación. . . . . . . . . . . . . . . . . . . . . . . 78D.4. Reportes de energía consumida. . . . . . . . . . . . . . . . . . . 78D.5. Visualización del estado de los pines GPIO utilizando GTKWave. 79D.6. Visualización de la simulación utilizando NetAnim. . . . . . . 79D.7. Archivo de salida .pcap abierto con Wireshark. . . . . . . . . . 80D.8. Archivo de salida de reporte de una UART. . . . . . . . . . . . 80

XI

Índice de Tablas

1.1. Resumen simuladores . . . . . . . . . . . . . . . . . . . . . . . 7

2.1. Revisiones del estándar 802.11 . . . . . . . . . . . . . . . . . . . 15

3.1. Scripts de soporte . . . . . . . . . . . . . . . . . . . . . . . . . . 36

XIII

Dedicado a mis padres y a mis abuelos.

1

Capítulo 1

Introducción General

Este capitulo hace una introducción a las Redes Inalámbricas de Sensores, susaplicaciones y el estado del arte de las herramientas utilizadas para simular-las. Se identifica la problemática actual de estos simuladores que motivó elpresente trabajo y se definen los objetivos y alcance del mismo.

1.1. Redes Inalámbricas de Sensores (WSN)

Una Red Inalámbrica de Sensores (WSN, del inglés, Wireless Sensor Networks)es un conjunto de nodos distribuidos espacialmente, con capacidad de medirdistintos fenómenos físicos utilizando uno o más sensores y que se comuni-can entre sí de forma inalámbrica para procesar datos de manera cooperativa[1][2].

Gracias al avance de la tecnología en microcontroladores y comunicacionesinalámbricas en los últimos años, se han podido desarrollar nodos con carac-terísticas sumamente convenientes para ser utilizados en este tipo de redescomo ser bajo costo y bajo consumo energético. Como consecuencia, el usode las WSN ha ido creciendo y abarcando un mayor rango de aplicaciones.Algunas aplicaciones típicas de WSN puede ser [3][4]:

Monitoreo de regiones: la red se despliega sobre una región en parti-cular donde se desea monitorear cierto fenómeno.

Aplicaciones en el ambito de la salud[5]: se pueden utilizar distintossensores en este ámbito: implantados, de montaje superficial en el cuer-po o ropa, o simplemente ubicados en el ambiente. Algunos ejemplosde aplicaciones en el ámbito de la salud:

- Monitoreo de la postura física del paciente.

- Monitoreo remoto de datos fisiológicos.

- Administración de medicamentos a un paciente.

Aplicaciones relacionadas al medio ambiente: existe una gran canti-dad de aplicaciones relacionadas con el medio ambiente. En muchasde ellas la zona donde se debe desplegar la red es de difícil acceso odemasiado hostil para colocar redes cableadas lo que hace a las redesinalámbricas ideales para este tipo de aplicaciones. Algunos ejemplos:

2 Capítulo 1. Introducción General

- Detección de incendios forestales.

- Detección de avalanchas.

- Mediciones de contaminación en el aire.

- Monitoreo de la calidad del agua.

Aplicaciones hogareñas:

- Automatización del hogar.

- Lectura de medidores de manera remota.

Aplicaciones militares:

- Detectar intrusión de enemigos en una determinada zona.

- Detección de ataques.

- Asistencia para apuntar a objetivos.

Aplicaciones de infraestructura urbana:

- Monitoreo de salud estructural.

- Smart Cities.

Cuando se habla de nodos, se refiere a un sistema embebido [6] cuyo hardwareestá típicamente compuesto por cuatro módulos [1][7], como se muestra enla figura 1.1:

Un microcontrolador que ejecuta las instrucciones y algoritmos progra-mados, y a su vez maneja a los otros módulos.

Una radio la cual le permite al nodo la comunicación inalámbrica (pue-de ser WiFi, Zigbee, Bluetooth, etc).

Uno o más sensores para recolectar información del medio físico.

Una unidad de energía capaz de almacenar energía y en algunas oca-siones recolectarla.

FIGURA 1.1: Esquema de un nodo WSN.

El software de dicho sistema embebido suele implementarse en capas de abs-tracción. Pueden existir tantas capas como sean necesarias (figura 1.2). Cabemencionar que si bien no existe un limite teórico en cuanto a la cantidad decapas que se pueden utilizar, sí existe una relación de compromiso entre la

1.1. Redes Inalámbricas de Sensores (WSN) 3

cantidad de capas utilizadas y el tiempo de procesamiento que requiere pa-sar por todas ellas. Por lo tanto, es conveniente que la cantidad de capas deabstracción no sea muy elevada.Cada capa es independiente y posee una interfaz bien definida que le per-mite interactuar con las capas por encima o por debajo de la misma. Estametodología de diseño le permite al desarrollador enfocarse unicamente enla interfaz de la capa con la que esta interactuando abstrayéndose de lo quepueda llegar a existir en otros niveles de la implementación. En particular,esta metodología es especialmente útil para abstraerse del hardware.

FIGURA 1.2: Diseño en capas de abstracción.

La capa de abstracción del hardware se conoce como HAL (del inglés, Hardwa-re Abstraction Layer). Se trata de la capa posicionada inmediatamente encimadel hardware (capa 1 en la figura 1.2) y su función es brindarle a las capas quese posicionan por encima de la HAL, una misma interfaz independientemen-te del hardware que se esté utilizando. De esta manera, se puede reutilizar unaaplicación en distintas plataformas de hardware sin necesidad de cambiar elcódigo.

En la figura 1.3a se muestra una representación de la capa HAL. Se observaen la figura 1.3b que la HAL a su vez puede estar dividida en sub-capas:

La HAL de bajo nivel, está constituida por funciones especificas delhardware que se utiliza.

La HAL de alto nivel, que provee una abstracción común a las capaspor encima de la HAL. Este nivel de abstracción se mantiene constanteaunque difiera el hardware.

En implementaciones donde se utiliza un sistema operativo (SO), es estequien se encarga de brindar una abstracción del hardware además de otrosniveles superiores (figura 1.3c). Algunos SO ya incluyen las librerías de firm-ware para cierto hardware y otros utilizan las propietarias del fabricante.

De esta manera se consigue que el desarrollo de una aplicación resulte aisla-do del hardware, permitiendo, además la portabilidad de la aplicación de unsistema a otro.

Cabe mencionar que la capa de aplicaciones también suele estar dividida ensubcapas, pero al no ser de interés para este trabajo se la representará comouna única capa de abstracción.


(A) Capa de abstracciónde hardware - HAL.

(B) HAL sin SistemaOperativo

(C) HAL con SistemaOperativo

FIGURA 1.3: Representacion de la capa HAL en una imple-mentación sin SO y otra con SO

En los proyectos donde se implementa una WSN se busca que los nodos ten-gan dos características principales: que sean de bajo costo y de bajo consumoenergético. Dado que una WSN puede estar compuesta de hasta cientos oincluso miles de nodos, si el costo de cada uno de ellos no es bajo, la imple-mentación puede resultar económicamente inviable. Por otro lado, recargarla energía de los nodos puede no ser factible en muchas aplicaciones ya seaporque los nodos estén ubicados en lugares de difícil acceso físico, o porqueel tiempo y esfuerzo requerido para recolectar, recargar, y volver a distribuirlos nodos pueda ser demasiado alto si la WSN está compuesta por una grancantidad de nodos. Por lo tanto es necesario que el consumo energético seabajo para que los nodos puedan mantenerse operativos durante periodos detiempo mayores.

El consumo energético está relacionado en gran parte a las transmisiones deradio que un nodo realiza. Es por ello que existen diversos protocolos de co-municación y de administración de la topologia de la red [8] para minimizarla cantidad de transmisiones.

Existen diferentes topologías de red que una WSN puede adoptar como ser:centrada en un nodo -donde existe un nodo central que recolecta la informa-ción del resto para procesarla y/o comunicarla al exterior de la red-, distribui-da -donde todos los nodos son iguales y el procesamiento se hace en conjuntoentre todos ellos-, o variaciones de estas topologías como se muestra en la Fi-gura 1.4. El tipo de topología que se implemente tendrá un impacto directoen el consumo de energía y en el rendimiento de la aplicación.

(A) Centrada en un nodo. (B) Distribuida. (C) Posibles variantes.

FIGURA 1.4: Distintas topologías de redes WSN.

1.2. Simulación en WSN 5

Las funciones que deben cumplir las WSN son cada vez más complejas y serequiere que se mantengan operativas durante periodos de tiempo cada vezmás extensos. Por consiguiente, es de gran importancia que durante la etapade desarrollo se pueda comprobar el correcto funcionamiento tanto del soft-ware que se ejecuta en los nodos, como también de la red de la que son parte,para poder así prever el comportamiento del conjunto y optimizar paráme-tros críticos como ser el consumo de energía.

1.2. Simulación en WSN

Realizar el despliegue de una red WSN es, en la gran mayoría de los casos,costoso y lleva tiempo. Por lo tanto, es deseable poder depurar el funciona-miento del conjunto sin necesidad de realizar un despliegue de la red. Enestos casos, es necesario realizar simulaciones. En la seccion 1.2.1 se presen-tan diferentes herramientas para este fin.

1.2.1. Estado del arte

Existe un gran variedad de herramientas para simular redes WSN [9-15]. Al-gunos de los simuladores más utilizados son:

Omnet++Es un simulador de diseño modular, implementado en C++ y de código abier-to lo que hace que tenga un gran potencial de expansión y personalización[16]. Proporciona un alto nivel de detalle en el análisis de redes a nivel depaquetes. Además posee una interfaz gráfica que hace que comenzar a utili-zarlo sea sencillo. Como puntos en contra se puede decir que no tiene tantosmodelos disponibles como otros simuladores y que en ciertos casos donde losmódulos son desarrollados por grupos de investigación independiente, sonincompatibles entre sí.

NS-3Al igual que Omnet++, el simulador NS3 es un simulador de eventos con undiseño modular, implementado en C++ y además es compatible con Python[17]. Es gratuito bajo la licencia GNU GPLv2. Incluye gran cantidad de mode-los de los protocolos más populares como ser TCP/IP, UDP, IPv4, IPv6, IEEE802.11 (incluidas las versiones b/g/n), IEEE 802.15.4 y WiMAX, entre otros.Proporciona archivos de salida en formato .pcap que pueden ser analizadoscon herramientas como Wireshark o TCPDump para cada una de las interfacessimuladas en la red. La principal desventaja que posee es que al tener tantosmodelos y configuraciones posibles, la curva de aprendizaje es muy empina-da al principio.


COOJA/MSPSimCooja [18] es, principalmente, un simulador para ciertos nodos1 que ejecutenaplicaciones basadas en el sistema operativo Contiki [19]. Sin embargo, so-porta también nodos simulados pero su funcionalidad debe estar escrita enlenguaje Java.Por su lado, MSPSim [20] es un emulador de nodos basados en el micro-controlador MSP430 de Texas Instruments que también utilicen el sistemaoperativo Contiki. Combina simulación de ciclos de ejecución del microcon-trolador para ciertos componentes (como conversores analógico-digital) consimulación de eventos para otros componentes (como por ejemplo el radio).MSPSim se puede integrar en COOJA permitiendo simulaciones con nodosdonde se carga el código y nodos donde directamente se cargan los archivosde firmware ELF y IHEX.COOJA y MSPSim son las mejores opciones para desarrollar aplicaciones ba-sadas en el sistema operativo Contiki. Sin embargo, para otras opciones laherramienta no provee soporte.

TOSSIMEs un simulador para aplicaciones que se ejecuten sobre el sistema operativoTinyOS [21]. Sin embargo, reemplazando unos pocos componentes de Tin-yOS, TOSSIM simula también el comportamiento del hardware pero solo delnodo MicaZ. TOSSIM está escrito en C++ pero soporta Python.La principal desventaja, además de las limitaciones de tener que usar el siste-ma operativo TinyOS y que solo soporte el hardware del nodo MicaZ, es queTOSSIM asume que todos los nodos de la red ejecutan exactamente el mismocódigo lo cual lo hace poco flexible.De todas maneras, es una excelente opción para aplicaciones que utilizan elsistema operativo TinyOS [22].

CastaliaEs un framework que se ejecuta sobre Omnet++. Castalia [23] se destaca portener modelos de radio y comunicación sumamente realistas. Además, poseeun modelo de canal basado en datos empíricos provenientes de distintas me-diciones para calcular tiempos de propagación de la señal y pérdida de señalpor propagación. Por otro lado, Castalia agrega un módulo de movilidad pa-ra los nodos, modelos de energía y consumo, y también modela el drift delclock de un microcontrolador.Los nodos son implementados por módulos compuestos, es decir módulos ysub-módulos, que representan cada uno de los componentes de los mismos.Por ejemplo las capas del stack de comunicación, la(s) aplicación(es), los sen-sores, etc.Lamentablemente, parece no recibir actualizaciones ni mantenimiento2.

Estos simuladores se dividen en tres grandes categorías:

1MicaZ, Eth1120, Exp2420, Exp1101, Exp1120, CC430, Sky, Wismote, Z12La ultima actualización al repositorio en Github fue hace 2 años.

1.2. Simulación en WSN 7

Simuladores de propósito general: se enfocan principalmente en si-mular los aspectos de comunicación y topologías de las redes WSN. Enestos simuladores el nodo es una abstracción formada por varios mó-dulos independientes que modelan los distintos aspectos del nodo realcomo ser las distintas capas del stack de comunicación, los sensores queposee, el perfil energético, etc. Al ser modular, le permite al usuario in-tercambiar dichos módulos, o incluso generar propios, para obtener unnodo con distintos componentes y funciones.Con respecto al código que se ejecuta en estos simuladores, se debe re-escribir el código utilizado en el “nodo real” para adaptarlo al “nodovirtual”, resultando así un código distinto al ejecutado en el primero. Espor esto que se considera a este tipo de simuladores útiles para desarro-llar nuevos protocolos de comunicación pero poco fiables para depuraraplicaciones.

Simuladores a nivel de código: usan el mismo código en la simulacióny en el “nodo real.” Poseen restricciones en cuanto al hardware que seutiliza e incluso son orientados a nodos que ejecutan un sistema opera-tivo especifico.

Simuladores a nivel de firmware (o emuladores): utilizan el mismofirmware que se graba en los nodos para correr la simulación. Emulanel hardware del nodo por completo y son, por lo tanto, completamentedependientes del nodo que se utiliza.

En la tabla 1.1 se muestra un resumen de los simuladores mencionados ante-riormente incluyendo la categoría a la que pertenecen.

TABLA 1.1: Resumen de simuladores disponibles

Simulador Categoría Características Limitaciones

Omnet++ General Diseño modular. Pocos modelos.Fácil de usar.

ns-3 General Variedad de modelos. Difícil de usar.

COOJA Código Para SO Contiki. Sólo SO Contiki.

MSPSim Emulador Integrado con COOJA. MicrocontroladoresMSP430 de Texas.

TOSSIM Código Para SO TinyOS. Mismo código entodos los nodos.

Castalia General Modelos de radio y Poca actualizacióncanal muy realistas.


1.2.2. Problemática actual

A pesar de la gran cantidad de simuladores existentes, para nodos que nosean los soportados por los simuladores de nivel de código o a nivel de firm-ware, o aplicaciones que no utilicen un sistema operativo de los menciona-dos anteriormente, sigue sin existir una herramienta que permita simular unaWSN utilizando el mismo código que va a utilizar en los nodos.

1.3. Motivación, objetivo y alcance

1.3.1. Motivación

Con el creciente uso de redes WSN, surgen nuevos nodos constantementepara poder satisfacer nuevas necesidades o necesidades conocidas de maneramás eficiente. Considerando la problemática de la sección 1.2.2 se entiendeque existe, por lo tanto, una necesidad de disponer de una herramienta quele permita al usuario simular la red que se desea implementar sin importar elnodo que elija o si este utiliza o no un sistema operativo.

1.3.2. Objetivo

El objetivo de este trabajo es el desarrollo de dicha herramienta de simulaciónacompañada de una metodología para poder extender su uso a cualquier no-do que se quiera utilizar.

1.3.3. Alcance

Como resultados a obtener el presente trabajo se tienen los siguientes:

Brindar una herramienta que permita configurar una red WSN y simu-lar un algoritmo de manera rápida y simple sin generar trabajo adicio-nal al usuario.

Proveer modelos de hardware de un nodo para utilizar en el entorno desimulación desarrollado.

Generar las “capas simuladas” para dicho nodo.

Ejecutar un algoritmo elegido tanto en el entorno de simulación desa-rrollado como en una red física, para evaluar y comparar los resultadosobtenidos, y de esta manera validar la propuesta de este trabajo.

Proponer trabajos futuros y/o mejoras.

9

Capítulo 2

Introducción Específica

En este capítulo se introduce el entorno de simulación desarrollado así comotambién el simulador ns-3 que le sirve de base a dicho entorno. Además sedescribe en detalle el nodo NodeMCU que se empleó para generar los mode-los usados en el entorno de simulación y se realiza una breve introducción alestándar Wi-Fi utilizado por este nodo.

2.1. Introducción al entorno desarrollado

La idea general es desarrollar sobre un simulador existente, una plataformacomo se muestra en la figura 2.1. La figura 2.1a muestra una posible red condos nodos (N1 y N2) que ejecutan el mismo código sobre el mismo hardwarey un tercer nodo (N3) que ejecuta otro código sobre un hardware distinto al deN1 y N2. Mientras que en la figura 2.1b se muestra el esquema de la mismared en el entorno de simulación.

(A) Ejemplo deaplicación. (B) Entorno simulado.

FIGURA 2.1: Esquema del entorno de simulación.

10 Capítulo 2. Introducción Específica

Capas reales y capas simuladasBasándose en el concepto de capas de abstracción planteado en la sección 1.1del capítulo 1, se buscó generar una división entre capas que mantienen elmismo código al ser ejecutadas en el nodo real y en el simulador (las “capasreales”) y las capas que requieren ser reemplazadas para adaptarse al simu-lador (o “capas simuladas”). El nivel al que se hace la división no es absolutosino que puede variar. Por lo tanto, si se quiere, por ejemplo, mantener elmismo código hasta la HAL de alto nivel puede hacerse y se utilizaran lasfunciones de interfaz (o APIs, del inglés Application Programming Interface) deesa capa. Por otro lado, si se quiere usar un sistema operativo y este interac-túa con la HAL de bajo nivel, puede hacerse la división a esa altura y simularsolo la capa de bajo nivel. Estas “capas simuladas” están asociadas a plata-formas de “hardware simulado” pues son las que brindan una abstracción delhardware. Con lo cual, cuando se quiera agregar un nuevo nodo al entorno, sedeberá proveer o desarrollar las “capas simuladas” necesarias.De esta manera, se obtiene una herramienta que permite utilizar el mismocódigo en el nodo real y en el entorno de simulación y a la vez no dependede un hardware en particular.

Hardware simuladoLos bloques de “hardware simulado” son bloques compuestos de módulosque modelan los distintos componentes del nodo que se quiere utilizar. En elcaso de ejemplo de la figura 2.1, se podría decir que, por ejemplo, el “HW SimA” es un bloque compuesto por un módulo de radio WiFi, un módulo UART,y un módulo de timer. Mientras que el “HW Sim B” esta compuesto por unmódulo de radio WiFi, un módulo de radio LR-WPAN, un módulo SPI, y unmódulo de timer. Se explicaran en detalle estos módulos en el capítulo 3.

El canalEste bloque modela el medio físico mediante el cual se comunican los nodos.Es el encargado de calcular el tiempo de propagación de una señal de un no-do a otro, así como también la pérdida de señal por propagación.Existe gran variedad de estudios y modelos de propagación [24-29] que pue-den utilizados para representar el canal en distintas circunstancias como serentornos al aire libre, en zonas urbanas, dentro de edificios, etc . Ademásexisten simuladores, como el ns-3, que ya poseen modelos de canal imple-mentados. En el capítulo 3 se presentarán estos modelos y se explicará comofueron usados.

Motor del simuladorEs el simulador sobre el cual funciona este entorno. En el presente trabajo seopto por el simulador ns-3 debido a su diseño modular y alta variedad demodelos disponibles.

Soporte y configuraciónEste bloque agrupa archivos de configuración, datos de entrada/salida de lasimulación y scripts (herramientas) que utiliza el entorno.

2.2. El simulador Ns-3 11

Los archivos de configuración son los que utiliza el usuario para especificarparámetros de la red, como por ejemplo la cantidad de nodos a simular, laposición y modelo de movilidad de cada nodo, parámetros del canal, comopor ejemplo que modelo de propagación utilizar, y parámetros de los nodos,como por ejemplo que plataforma de hardware utiliza cada uno, hasta que ni-vel de capas de abstracción del firmware se simula, o que programa ejecutacada nodo.Los archivos de datos de entrada/salida son archivos que el simulador utilizao genera durante tiempo de ejecución. Los datos de entrada pueden ser porejemplo un número de identificación para cada nodo (simulando un númerode serie en un nodo real) o archivos en formato “vcd” que indiquen instantesde tiempo en los que se debe simular un cambio de estado en alguno de lospines de entrada del nodo. Por otro lado, los archivos de datos de salida sonlos archivos en los que se registra cierto tipo de actividad en los nodos, porejemplo un archivo en formato “vcd” con el estado de cada uno de los pinesGPIO del nodo, el log de la UART, o un reporte detallado de la energía con-sumida por cada nodo.Los scripts son las herramientas que brindan soporte al entorno. Se encar-gan por ejemplo de presentarle al usuario una interfaz de ejecución sencilla,“leer” los archivos de configuración y generar los archivos de simulación ba-sándose en plantillas de estos archivos, iniciar el simulador, o procesar archi-vos de salida para facilitarle al usuario la interpretación de los mismos.

En el capítulo 3 se detalla la implementación de este diseño y se utiliza elnodo NodeMCU como ejemplo para generar los módulos de hardware y las“capas simuladas”.

2.2. El simulador Ns-3

El simulador ns-3 [17] es un proyecto que inicio en el 2006. Se distribuye demanera gratuita bajo la licencia GNU GPLv2.

Es un simulador de eventos discretos que cae dentro de la categoría de "Simu-ladores de propósito general". Está orientado a realizar pruebas sobre redesy protocolos de internet pero no se limita a eso. Tanto el motor de simulacióncomo los modelos están escritos en C++.

A diferencia de otros simuladores que proveen una herramienta para redes ohardware específicos, ns-3 tiene un diseño modular con distintos módulos quese combinan entre si para modelizar componentes de la red o de los nodos.Además de los módulos que ns-3 incorpora por defecto, el usuario puedeagregar módulos nuevos, o modificar los ya existentes para realizar mejoraso cambiar el comportamiento de manera que se adapte mejor al entorno quese quiere simular.

Con respecto al funcionamiento, ns-3 tiene un archivo principal, el main, don-de se define la topología de la red, se generan y configuran los componentes


a simular mediante los módulos mencionados anteriormente y se le da inicioa la simulación.

2.2.1. Componentes básicos

Para poder entender la estructura y funcionamiento del simulador, es nece-sario describir algunos componentes que se utilizan en ns-3.

NodoEl nodo esta representado por un objeto de la clase Node que provee metodospara configurarlo y agregarle otros componentes. El nodo se debe pensar co-mo un contenedor al cual se le agregan otros módulos como dispositivos dered, aplicaciones, módulo de movilidad, protocolos de red, etc.

Dispositivo de redEl dispositivo de red es un componente que se agrega al nodo permitiéndoleconectarse a un canal de comunicación para comunicarse con otros nodos. Esun objeto de las clases específicas del tipo de dispositivo de red que se quierausar. Por ejemplo si se quiere un dispositivo de red WiFi, este sera un objetode la clase WifiNetDevice. Existen también otros clases de dispositivos de redcomo CsmaNetDevice o PointToPointNetDevice. A su vez estas clases heredande una clase común para todos los dispositivos de red llamada NetDevice.Un nodo puede tener más de un dispositivo de red agregado.

CanalEl canal modela el medio por el cual se comunican los dispositivos de red. Asícomo existen distintos tipos de dispositivos de red, también existen distintostipos de canales a los cuales se conectan. Los canales son objetos de la claseespecífica la cual modelan, pero a su vez, todos heredan de la clase comúnChannel. Los usuarios pueden elegir utilizar los modelos de canal que proveeel simulador tal cual vienen por defecto, modificarlos o hasta crear modelosnuevo.

AplicaciónUna aplicación es, un programa que se ejecuta en el nodo y genera eventosen la simulación. El simulador ns-3 viene con varias aplicaciones típicas deredes (como por ejemplo ping) pero se espera que el usuario desarrolle laspropias. Para ello, ns-3 provee la clase Application de la cual deben heredartodas las aplicaciones para que el simulador pueda interactuar con estas.

2.2.2. Estructura

Los módulos del simulador ns-3 se organizan en grupos o categorías segúnsu función como se muestra en la figura 2.2. A continuación se describe elcontenido y propósito de cada una de las categorías.

2.2. El simulador Ns-3 13

FIGURA 2.2: Organización del simulador ns-3.Imagen tomada del manual de ns-3 [30].

Core

En esta categoría se encuentran las librerías que hacen el núcleo del simula-dor. Se declaran e implementan las clases y funciones que son comunes paratodas simulaciones sin importar la topología de la red, el hardware, los proto-colos que se utilicen, etc.

Network

En esta categoría se encuentran las librerías relacionadas a los componentesde la red que se va a simular.Consiste en las clases base de las cuales heredan las clases que implementanlos distintos dispositivos de red, paquetes, aplicaciones y protocolos de red.También en esta categoría se encuentran las librerías y funciones que definenal nodo de ns-3.

Internet y mobility

En esta categoría se encuentran las implementaciones de los modelos relacio-nados a los protocolos de red:

ipv4.

ipv6.

Protocolos TCP.

Protocolos UDP.

Algoritmos de ruteo para redes IP.

También se encuentran incluidas las librerías que modelan la movilidad delos nodos.


Modelos específicos

En esta categoría se encuentran las implementaciones específicas de los mo-delos de la categoría del Nivel 2. Es decir, aquí están las librerías para, porejemplo, los distintos dispositivos de red: dispositivos WiFi, dispositivos Cs-ma, o punto-a-punto. O los distintos canales a los que se conectan los dispo-sitivos de red: ethernet channel, wifi channel, etc.Las clases de esta categoría, heredan de las clases del Nivel 2.

Helpers

En esta categoría se encuentran las clases y funciones que le simplifican algu-nas tareas al usuario a la hora de crear y configurar módulos. A estas clasesse las denomina helpers. Si bien su uso no es estrictamente necesario, es el mé-todo recomendado por ns-3 para crear los componentes de la simulación.El helper se puede pensar como una especie de “molde” al que el usuario leconfigura atributos y le asigna otros objetos, y luego este helper se encarga deagrupar y configurar los módulos y sub-módulos necesarios para crear uncierto componente.En el apéndice B se muestra un ejemplo de su uso.

Test

En esta categoría se encuentran las pruebas para verificar el correcto funcio-namiento de los modelos. Cada módulo posee rutinas de verificación.También forman parte de esta categoría los ejemplos existentes.

2.3. Wi-Fi - El estándar 802.11

La mayoría de los protocolos de red se basan en el modelo de Interconexiónde Sistemas Abiertos (OSI, del inglés, Open System Interconnection). El mode-lo OSI es un modelo de referencia para los protocolos de red creado por laOrganización Internacional de Normalización (ISO, del inglés, InternationalOrganization for Standardization) con el fin de lograr la compatibilidad de dis-tintos sistemas de comunicación con protocolos de comunicación estándar.Para ello establece siete capas de abstracción por las que deben pasar los da-tos para viajar de un dispositivo a otro (figura 2.3). Cada capa debe cumpliruna función específica para lo cual define un conjunto de normas para losdistintos protocolos así como también una interfaz para interactuar con lascapas inmediatamente superior e inferior. De esta manera se logra compa-tibilidad de un protocolo a otro siempre y cuando se respeten las interfacesdefinidas.

El estándar IEEE 802.11 [32], comúnmente llamado Wi-Fi, define la capa físi-ca (PHY) y la capa de enlace de datos (DLL) del modelo OSI. Existen variasrevisiones de la norma que definen distintas bandas de frecuencia de ope-ración, tipo de modulación, ancho de canal y tasa de transmisión de datos

2.3. Wi-Fi - El estándar 802.11 15

FIGURA 2.3: Capas de abstracción del modelo OSI. Imagentomada de Geeks for Geeks [31]

.

entre otras cosas. La tabla 2.1 resume las principales características para lasrevisiones más utilizadas del estándar.

TABLA 2.1: Principales caracteristicas de las revisiones másusadas del estandar 802.11

Revisión Frecuencia Modulación Max. tasa detransmisión

802.11a 5 GHz OFDM 54 Mbps

802.11b 2.4 GHz DSSS 11 Mbps

802.11g 2.4 GHz OFDM 54 Mbps

802.11n 2.4 GHz MIMO-OFDM 288 Mbps5 GHz MIMO-OFDM 600 Mbps

Además de definir las capas PHY y DLL, el estándar 802.11 describe los mo-dos de operación que una red puede adoptar: infraestructura o ad-hoc.En una red que opera en modo infraestructura como la de la figura 2.4a, exis-ten dos tipos de dispositivos: Station (STA) y Access Point (AP). Los STA sontodos los dispositivos que tienen la capacidad de conectarse físicamente a unared Wi-Fi. Los AP son aquellos que, además de poder conectarse físicamentea una red Wi-Fi, actúan como puerta de acceso a otras redes (generalmentecableadas) para otros dispositivos STA. Cuando el AP no posee una conexióncableada a otra red se le denomina Soft-AP.El conjunto de dispositivos STA y AP (o Soft-AP) se denomina Basic Service


Set (BSS). Solo puede existir un AP por cada BSS. Cada BSS tiene un identifi-cador llamado BSSID que corresponde a la MAC address del AP. Luego, si doso mas AP se conectan entre sí se forma un Extended Service Set (ESS) que estacompuesto por los BSS asociados a cada AP. Cada ESS tiene un identificadorllamado SSID que es un string alfanumérico de 32 caracteres como máximo.Por otro lado, en una red que opera en modo ad-hoc (figura 2.4b) todos losdispositivos son STA y no existe un AP. Los dispositivos se transmiten direc-tamente entre sí (comunicación que se conoce como peer-to-peer). Al conjuntode dispositivos conectados entre si en una red ad-hoc se les denomina Inde-pendent Basic Service Set (IBSS).

(A) Red en modo infraestructura. (B) Red en modo ad-hoc.

FIGURA 2.4: Modos de operación de una red Wi-Fi.

El nodo NodeMCU que se utilizó en este trabajo puede ser configurado paraque actué como STA, Soft-AP o ambas al mismo tiempo.

2.4. El nodo NodeMCU

NodeMCU [33] es un kit de desarrollo que esta compuesto por el móduloESP-12E, que a su vez esta compuesto por el Sistema en un Chip (SoC, delinglés, System on a Chip) ESP8266 de Espressif como se ve en la figura 2.5.

FIGURA 2.5: El nodo NodeMCU y sus principales componen-tes.

2.4. El nodo NodeMCU 17

El microcontrolador es un Tensilica L106 de 32 bits y esta integrado dentrodel SoC ESP8266. En las secciones 2.4.1, 2.4.2 y 2.4.3 se describe cada uno delos componentes de la figura 2.5.

2.4.1. El SoC ESP8266

Es el componente principal del nodo. Consiste en una solución completa deWi-Fi integrada junto con otros componentes (como un microcontrolador,memoria, PLL, conversor analógico-digital, etc) que le permiten ejecutar apli-caciones de manera autónoma. La figura 2.6 muestra un diagrama de bloquesdel SoC ESP8266.

FIGURA 2.6: Diagrama de bloques del ESP8266.Imagen tomada de la hoja de datos del ESP8266 [34].

Las principales características de este chip son:

Microcontrolador y memoria

Incorpora un microcontrolador Tensilica L106 de 32 bits de bajo consu-mo capaz de funcionar a una velocidad de clock de hasta 160 MHz.

Memoria SRAM integrada con una capacidad de 50 kB disponibles parael usuario.

No posee memoria Flash integrada. Por lo tanto, se debe utilizar unamemoria Flash externa conectada a través de SPI para almacenar el có-digo que se quiera ejecutar. Soporta hasta 16 MB de memoria Flash.

Clock

Utiliza un cristal externo que puede variar de 24 MHz a 52 MHz.

Internamente genera señales de clock para las transmisiones y recep-ciones de módulo de Wi-Fi.


Radio y Wi-Fi

Posee un transmisor y receptor de 2.4 GHz.

Soporta los canales según el estándar IEEE 802.11b/g/n.

Potencia de transmisión variable con una potencia máxima de 20.5 dBm.

Posee dos interfaces Wi-Fi virtuales que funcionan en modo Access Point,Station o modo Promiscuo.

Periféricos

Posee 17 pines de entrada y salida de propósito general (GPIO, del in-glés, General Purpose Input and Output) a los que se les pueden asignarfunciones alternativas a través de registros de configuración.

Integra un conversor analógico-digital de 10 bits.

Una interfaz I2C.

Dos interfaces UART.

Tres interfaces SPI.

Cuatro interfaces de salida PWM.

2.4.2. El módulo ESP-12E

El módulo ESP-12E agrega una memoria Flash de hasta 16 MB (la utilizadapuede variar según la version del nodo NodeMCU que se esté usando) y laantena (dibujada como parte del PCB).

Además de esto, facilita el acceso a los pines del ESP8266 gracias a un conve-niente diseño del PCB.

2.4.3. La placa NodeMCU

El nodo en sí, es un kit de desarrollo para el módulo Wi-Fi ESP-12E. Existendiferentes versiones de la placa que varían según el fabricante, el pinout, yhasta el módulo WiFi que usan. A este nivel, se le agrega al módulo de Es-pressif componentes para ayudar al usuario a prototipar su implementacióny cualquier conexión que el módulo requiera para funcionar.

Los principales agregados son:

Conversor serie-USB para poder conectar el nodo a una PC usando elpuerto USB tradicional y poder grabar el programa al nodo.

LEDs y pulsadores conectados a los GPIO del nodo.

Pulsador de Reset.

2.4. El nodo NodeMCU 19

Circuitos de alimentación.

Pines para poder acceder a los puertos del módulo de manera sencilla.

De los 17 pines GPIO que posee el SoC ESP8266, internamente se utilizan6 para conectar una memoria flash, 2 para conectar la UART0 y los otros 9quedan disponibles para utilizar como GPIO digitales.

2.4.4. El firmware para el NodeMCU

El fabricante Espressif provee librerías de firmware para comunicarse con elhardware del módulo ESP8266 a través de dos “Kits de Desarrollo de Software”(SDK, del inglés Software Development Kit). Un SDK basado en el popular sis-tema operativo FreeRTOS[35] y el otro basado en APIs (funciones) y callbacks.En este trabajo se utilizó el SDK basado en APIs y callbacks ya que, como sevio en 1.2.1 ya existen simuladores para aplicaciones que utilizan sistemasoperativos.El SDK elegido se llama ESP8266_NONOS_SDK y puede descargarse de ma-nera gratuita desde la plataforma Github de Espressif [36]. Las APIs que com-ponen a esta librería de firmware se encuentran en el manual provisto porEspressif [37] y se pueden agrupar en las siguientes categorías:

Timers por software.

Timers por hardware.

APIs del sistema.

APIs relacionadas a la comunicación con la memoria Flash a través deSPI.

APIs relacionadas a Wi-Fi.

APIs relacionadas a protocolos de comunicación propietarios de Es-pressif.

APIs relacionadas al protocolo SNTP.

APIs relacionadas a los protocolos TCP y UDP.

En este trabajo se utilizó un grupo reducido de estas APIs para generar lacapa de firmware de la “HAL simulada”.

21

Capítulo 3

Diseño e Implementación

En este capítulo se detallan la estructura del entorno de simulación y los mó-dulos que lo componen. También se presentan las herramientas auxiliaresque se desarrollaron.

3.1. Estructura del entorno de simulación

El simulador ns-3 posee una estructura de archivos como se muestra en lafigura 3.1a. Lo importante de observar es que el directorio scratch contie-ne los archivos que definen las simulaciones, y el directorio src contiene losmódulos de ns-3, tanto los que vienen por defecto, como cualquier otro mó-dulo que haya sido agregado por un usuario. Cada módulo, a su vez, tiene laestructura de la figura 3.1c donde:

doc: contiene la documentación pertinente al módulo.

examples: contiene ejemplos de como utilizar el módulo.

helper: contiene los archivos con el código de los helpers si existiesenpara este módulo.

model: contiene los archivos con el código del módulo en sí.

test: contiene las rutinas de verificación para el módulo.

wscript: en este archivo se le indica a ns-3 que archivos dentro delmódulo deben ser compilados, y que headers deben ser incluidos.

Para poder ser integrado como un módulo más de ns-3, es necesario queel entorno de simulación adopte la estructura de archivos de los módulosdefinida por ns-3. En la figura 3.1b se observa la estructura del entorno desimulación. Se puede ver que por un lado contiene un directorio scratchcon un archivo WSN_sim.cc. Este archivo contiene las funciones e instruc-ciones para generar y configurar la red, los nodos, el canal, y darle inicio ala simulación. Por otro lado, existe el directorio src donde se encuentra elmódulo myWsn. Este módulo contiene la estructura de los módulos definidapor ns-3. A su vez, los modelos y archivos fuentes de interés están dentrode myWSN/model. Aquí se separa en NODE, que es donde se encuentran losmodelos para cada plataforma de hardware implementada, y USER donde seencuentran los archivos de configuración para que el usuario personalice la

22 Capítulo 3. Diseño e Implementación

simulación, el código que se debe cargar en los nodos y los archivos de sa-lida de la simulación. El directorio RUN almacena archivos temporarios paracorrer una simulación y no es de importancia para este análisis.

(A) Estructura de archivosdel simulador ns-3.

(B) Estructura de archivosdel entorno.

(C) Estructura de archivosde un módulo.

FIGURA 3.1: Estructuras de archivos de interés.

3.2. Componentes de la simulación

Los componentes de la simulación se dividen en tres grupos: la parte física,el firmware de los nodos y las herramientas de soporte y archivos de configu-ración para el entorno de simulación. Los componentes de la parte física sontodos aquello que en una red real tendría una característica física. Por ejem-plo la plataforma de hardware de los nodos, la posición de cada uno de ellos,el canal de comunicación, etc. Por otro lado, el grupo de los componentesde los nodos se refiere principalmente al firmware. Las secciones 3.2.1, 3.2.2 y3.2.3 describen como se genera cada componente en detalle.

3.2.1. Simulación de la parte física

La generación de los componentes “físicos” de la red se realiza mediante elcódigo en el archivo scratch/WSN_sim.cc. Al iniciar la simulación, se eje-cuta este archivo y se van generando los componentes de manera secuencial

3.2. Componentes de la simulación 23

en las etapas que se pueden observar en la figura 3.2. A continuación se ex-plica en detalle cada una de las etapas.

FIGURA 3.2: Diagrama de flujo - scratch/WSN_sim.cc.

Etapa 1 - Creación de los nodosSe crea la cantidad de nodos definida por el usuario mediante un archivo deconfiguración. Los nodos creados son elementos vacíos que no están confi-gurados aún. Se les agrega unicamente una fuente de energía con un valorde carga inicial y una tensión de alimentación establecidos en el mismo ar-chivo mediante directivas #define. En la etapa 3 se configuran los nodos deacuerdo a la plataforma de hardware seleccionada.

Etapa 2 - Creación del canal Wi-FiEl código 3.1 genera el canal mediante el cual se van a conectar los nodos.El canal en sí es un objeto de la clase YansWifiChannel1 de ns-3. Funcionaen tándem con las interfaces de la clase YansWifiPhy que se instalan en elnodo durante la etapa 3.

1El nombre proviene de un simulador del cual fue sacado el modelo “Yans Simulator” [38]que significa Yet Another Network Simulator


1 // =================================================================2 // Configurar e l canal WiFi3 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−4 YansWifiChannelHelper wifiChannelHelp ;5 wifiChannelHelp . SetPropagationDelay (6 " ns3 : : ConstantSpeedPropagationDelayModel " ,7 " Speed " , DoubleValue ( 2 . 9 9 7 9 2 e +08) ) ;8 wifiChannelHelp . AddPropagationLoss (9 " ns3 : : LogDistancePropagationLossModel " ,

10 " ReferenceDistance " , DoubleValue ( 1 ) ,11 " ReferenceLoss " , DoubleValue ( 4 0 . 0 4 6 ) ,12 " Exponent " , DoubleValue ( 3 ) ) ;13 Ptr <YansWifiChannel > wifiChannel = wifiChannelHelp . Create ( ) ;14 // =================================================================

CÓDIGO 3.1: Creación del canal Wi-Fi.

El canal generado es el encargado de replicar los paquetes que se introducenen él, a través de una de las interfaces, a todas las otras interfaces conectadas.A su vez, se encarga también de calcular el retardo de la señal y la pérdidade potencia por propagación. El simulador ns-3 posee un módulo de propa-gación que contiene distintos modelos disponibles tanto para el cálculo deretardo como para el de pérdida de potencia. Se debe establecer qué modelose quiere usar para cada cálculo.

Los modelos disponibles para el cálculo de retardo por propagación son:

ConstantSpeedPropagationDelayModel: es un modelo de retardo por ve-locidad de propagación constante. En este modelo la señal viaja convelocidad constante y el retardo es calculado de acuerdo a la distanciaentre transmisor y receptor unicamente.

RandomPropagationDelayModel: en este modelo el retardo entre transmi-sor y receptor es completamente aleatorio y cambia cada vez que seenvía un paquete.

Los modelos disponibles para el cálculo de pérdida de potencia de señal porpropagación son:

Cost231PropagationLossModel.

FixedRssLossModel.

FriisPropagationLossModel.

ItuR1411LosPropagationLossModel.

ItuR1411NlosOverRooftopPropagationLossModel.

JakesPropagationLossModel.

Kun2600MhzPropagationLossModel.

LogDistancePropagationLossModel.

MatrixPropagationLossModel.

NakagamiPropagationLossModel.


OkumuraHataPropagationLossModel.

RandomPropagationLossModel.

RangePropagationLossModel.

ThreeLogDistancePropagationLossModel.

TwoRayGroundPropagationLossModel.

El detalle para cada uno de ellos puede encontrarse en el manual de ns-3 [30].

Como se puede ver en el extracto de codigo 3.1, en este trabajo se usaronlos modelos de velocidad de propagación constante para el retardo (con laconstante de velocidad igual a la velocidad de la luz en el vacío) y el modeloLogDistancePropagationLossModel para la pérdida de señal por propagación.El modelo de retardo es un modelo sencillo que responde a la ecuación 3.1.

Ret =d

v(3.1)

donde

Ret es el retardo.

d es la distancia entre transmisor y receptor.

v es la velocidad de propagacion de la señal que, para este trabajo, seutilizó la velocidad de propagación de la luz en el vacío.

Por otro lado el modelo de pérdida por propagación responde a la ecuación:

L = L0 + 10n log10

(d

d0

)(3.2)

donde

L es la pérdida por propagación (en dB) entre transmisor y receptor.

L0 es la pérdida por propagación (en dB) a una distancia de referenciad0.

n es un exponente que depende del medio.

d es la distancia (en metros) entre transmisor y receptor.

d0 es la distancia de referencia (en metros) utilizada para calcular L0.

Este modelo requiere que se definan n, d0 y L0. Por defecto estos valores sonn = 3, d0 = 1m y L0 = 46.6777dB 2.En este trabajo se mantuvo el valor por defecto de n = 3 ya que es un va-lor intermedio entre espacios abiertos (donde corresponde n = 2) y espacioscon muchas obstrucciones (donde corresponde n = 4) [26-28]. De todas ma-neras, no se busca brindar un modelo de canal especifico para un entornosino más bien brindar una herramienta que se pueda configurar. El usuario

2El valor se obtiene utilizando el modelo Friis con una frecuencia de 5.15 GHz y una dis-tancia de referencia de 1 metro.


puede cambiar los valores de estos parámetros fácilmente e incluso cambiarel modelo utilizado para adaptarse mejor a otro entorno.Con respecto a la perdida por propagación de referencia, en el apéndice Ase realizaron los cálculos para obtener L0 en base al modelo de Friis con d0 =1m y una frecuencia de 2.4 GHz ya que en este trabajo se utilizó el estándar802.11b.Queda así, definido el modelo de propagación para este canal.

Etapa 3 - Configuración de los nodos según la plataforma de hardware se-leccionadaHasta aquí sólo se han creado los nodos “vacíos” por un lado y el canal consus modelos de propagación por otro, pero no se han conectado entre sí. Elpróximo paso es configurar el hardware de los nodos y conectarlos al canal.

La configuración del nodo va a depender de la plataforma de hardware que elusuario haya especificado para cada uno mediante los archivos de configura-ción. Dado que en este trabajo se implementó la plataforma de hardware parael nodo NodeMCU que se describió en 2.4, todos los nodos se configurarancon dicha plataforma.

La función create_NodeMCU (extracto de código 3.2), invocada en este pa-so, se encarga de agregar los módulos necesarios para simular la plataformade hardware del NodeMCU.

1 // =================================================================2 void create_NodeMCU ( NodeContainer containerNodeMCU ,3 Applicat ionContainer ∗nodeApps ,4 Ptr <YansWifiChannel > wifiChannel ,5 NetDeviceContainer ∗ staWif iDevices ,6 NetDeviceContainer ∗apWifiDevices )7 {8 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−9 // −−−−−−− Configuracion general de WiFi

10 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−11 WifiHelper w i f i ;12 w i f i . SetStandard (WIFI_PHY_STANDARD_80211b) ;13 w i f i . SetRemoteStationManager (14 " ns3 : : ConstantRateWifiManager " ,15 " DataMode " , Str ingValue ( " DsssRate11Mbps " ) ,16 " ControlMode " , Str ingValue ( " DsssRate11Mbps " ) ) ;17 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−18

19

20 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−21 // −−−−−−− D i s p o s i t i v o s f i s i c o s − Capa PHY22 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−23 YansWifiPhyHelper wifiPhy = YansWifiPhyHelper : : Defaul t ( ) ;24 wifiPhy . SetChannel ( wifiChannel ) ;25 wifiPhy . Set ( " EnergyDetectionThreshold " , DoubleValue (−91) ) ;26 wifiPhy . SetPcapDataLinkType ( WifiPhyHelper : : DLT_IEEE802_11_RADIO ) ;27 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−28

29

30 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−31 // −−−−−−− Configuracion de capa MAC e i n s t a l a c i o n de i n t e r f a c e s


32 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−33 // Una i n t e r f a z por cada t i p o de funcion (ACCESS POINT o STATION)34 //35 WifiMacHelper wifiMac ;36 //37 // I n t e r f a z para funcion STATION38 wifiMac . SetType ( " ns3 : : StaWifiMac " ) ;39 ∗ s taWif iDevices = w i f i . I n s t a l l ( wifiPhy , wifiMac , containerNodeMCU ) ;40 wifiPhy . EnablePcap (PCAP_OUT_PATH" wif i−myWSN−STA" ,∗ s taWif iDevices ) ;41 f o r ( u i n t 3 2 _ t i =0 ; i <staWif iDevices−>GetN ( ) ; i ++) {42 DynamicCast<WifiNetDevice >( staWif iDevices−>Get ( i ) )−>GetPhy ( )−>

SetOffMode ( ) ;43 }44

45 // I n t e r f a z para funcion ACCESS POINT46 wifiMac . SetType ( " ns3 : : ApWifiMac " ) ;47 ∗apWifiDevices = w i f i . I n s t a l l ( wifiPhy , wifiMac , containerNodeMCU )

;48 wifiPhy . EnablePcap (PCAP_OUT_PATH" wif i−myWSN−AP" , ∗apWifiDevices ) ;49 f o r ( u i n t 3 2 _ t i =0 ; i <apWifiDevices−>GetN ( ) ; i ++) {50 DynamicCast<WifiNetDevice >( apWifiDevices−>Get ( i ) )−>GetPhy ( )−>

SetOffMode ( ) ;51 }52 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−53

54

55 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−56 // −−−−−−− I n s t a l a r Stack i n t e r n e t57 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−58 In terne tS tackHelper i n t e r n e t ;59 i n t e r n e t . I n s t a l l ( containerNodeMCU ) ;60

61 Ipv4AddressHelper ipv4 ;62 ipv4 . SetBase ( " 1 0 . 1 . 1 . 0 " , " 2 5 5 . 2 5 5 . 2 5 5 . 0 " ) ;63 I p v 4 I n t e r f a c e C o n t a i n e r s t a _ i p _ c t r = ipv4 . Assign (∗ s taWif iDevices ) ;64 I p v 4 I n t e r f a c e C o n t a i n e r ap_ ip_c t r = ipv4 . Assign (∗ apWifiDevices ) ;65 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−66

67

68 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−69 NS_LOG_INFO ( " Ins ta lando firmware en nodos NodeMCU. " ) ;70 node_NodeMCUHelper nodeMcuHelper ;71 ∗nodeApps = nodeMcuHelper . I n s t a l l ( containerNodeMCU ) ;72 // −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−73 }74 // =================================================================

CÓDIGO 3.2: Función de configuración de los nodos.

El primer paso de la función para simular la plataforma de hardware del No-deMCU es crear las interfaces de red Wi-Fi. Para ello, se utiliza un helper de laclase wifiHelper. Como primer medida se establecen parámetros genera-les de Wi-Fi. Con el método WifiHelper::SetStandard() se configuranvarios parámetros de las capas PHY y MAC a valores propios del estándarelegido. Por ejemplo si se elige el estándar 802.11b, como es el caso que se ob-serva en el código 3.2, automáticamente se configura la banda de frecuenciaa 2.4 GHz, el ancho de cada canal a 22 MHz, la velocidad de transmisión sólopodrá tomar valores de 1, 2, 5.5 u 11 Mbps, etc.


Una vez establecido el estándar, se configura un algoritmo para controlar lavelocidad de transmisión. Existen distintos algoritmos disponibles en ns-3 loscuales se encuentran detallados en la documentación [39]. Por ejemplo:

ArfWifiManager: implementa el algoritmo ARF descripto en [40].

ConstantRateWifiManager: utiliza una velocidad de transmisión constan-te.

MinstrelWifiManager: implementa el algoritmo de control de velocidadde transmisión llamado Minstrel. Algoritmo que se utiliza en los driversWi-Fi de Linux.

IdealWifiManager: implementa un algoritmo de velocidad de transmi-sión ideal similar al algoritmo RBAR [41].

El transceiver ESP8266, componente del nodo NodeMCU, soporta los están-dares 802.11 b/g/n como se puede observar en la hoja de datos [34]. En estetrabajo se implemento el estándar 802.11b con el algoritmo de velocidad detransmisión constante ConstantRateWifiManager a una velocidad de 11 Mpbs.

El segundo paso es configurar los objetos que representan la capa PHY delas interfaces. Para esto se utilizó un helper de la clase YansWifiPhyHelper.Se vincula el helper con el canal creado previamente así cuando se creen losobjetos de la capa PHY, ya estarán conectados al canal.Seguidamente, se establece el “umbral de energía mínima de detección” (osensibilidad) para las interfaces. Según la hoja de datos del ESP8266, la sensi-bilidad es -91 dBm.Por último, se configura mediante el método SetPcapDataLinkType quetodos los paquetes que se transmiten, tengan los headers establecidos en el es-tándar IEEE 802.11 Wireless LAN. Esto permite que se puedan generar archi-vos de salida con formato “.pcap” para luego ser analizados por herramientascomo Wireshark o TCPDump.

Una vez configurados los objetos de la capa PHY, se procede con los de lacapa MAC.La capa MAC es la que define si la interfaz opera como STA o AP. En ns-3 sepermite vincular sólo un objeto de la capa MAC a cada interfaz y, dado queexisten distintas clases para cada modo de operación (StaWifiMac para ope-rar en STA, ApWifiMac para operar en AP y AdhocWifiMac para operar enAd-hoc), se debe crear una interfaz distinta para cada modo de operación quese quiera simular en el nodo. El nodo NodeMCU puede operar como STA, APo ambas a la vez, por lo tanto, para simular este comportamiento se crearondos interfaces y se le asigno a cada una un objeto de la capa MAC correspon-diente. Para lograr esto se utilizo un helper de la clase WifiMacHelper y selo configuró para que cree objetos de la clase StaWifiMac en una primerainstancia y luego de la clase ApWifiMac.

Seguidamente, se crean las interfaces y se las “instala” en cada nodo. De estamanera, cada nodo termina teniendo dos interfaces de red Wi-Fi (una quefunciona como AP y otra como STA) ambas conectadas al mismo canal quese había creado en la etapa 2.


El siguiente conjunto de instrucciones en la función de configuración de losnodos crea un helper de la clase InternetStackHelper que sirve para darlea los nodos funcionalidades de las capas de Red y de Transporte del modeloOSI. Esto permite, entre otras cosas, asignarle direcciones IP a las interfaces,utilizar protocolos UDP y TCP y crear sockets de internet. Luego se le asignauna dirección IP a cada una de las interfaces sólo a modo de inicializacion.Una vez iniciada la simulación, la dirección IP se puede modificar mediantelas APIs correspondientes.

El último paso de la configuración de los nodos es agregarles un objeto basa-do en la clase Application de ns-3. Este objeto es esencial ya que es el que cargatodas las capas de abstracción del firmware, establece el instante de inicio delnodo y modela su comportamiento. Podría pensarse en este objeto como elmodelo del microprocesador del nodo. Por lo tanto, cada nodo o plataformade hardware implementada en este entorno deberá tener su clase particularbasada en la clase Application.

Con esto queda el nodo configurado con la plataforma de hardware elegida.

Etapa 4 - Ubicar los nodos en el espacioYa con los nodos configurados, se procede a asignarles una posición inicial enun espacio tridimensional según la configuración establecida por el usuarioen el archivo de posición de los nodos WSN_position.conf. Además dela posición inicial, se le asigna a cada nodo un módulo de “movilidad” quemodela movimientos que puede tener cada nodo a lo largo del tiempo quedure la simulación. Existen diversos modelos de movilidad para seleccionaren ns-3:

ConstantPosition

ConstantVelocity

ConstantAcceleration

GaussMarkov

Hierarchical

RandomDirection2D

RandomWalk2D

RandomWaypoint

SteadyStateRandomWaypoint

Waypoint

Cada uno de estos modelos se encuentra detallado en la documentación dens-3 [39]. En este trabajo se utilizó el modelo ConstantPosition en el que cadanodo mantiene su posición fija y no se mueve.La importancia de ubicar los nodos en el espacio radica principalmente en


que el modelo del canal utiliza la distancia relativa entre los nodos para cal-cular el tiempo de propagacion de la señal y la pérdida de potencia por pro-pagación.

Etapa 5 - Establecer instante de inicio aleatorio para cada nodoCon el fin de generar una simulación más realista, a cada nodo se le asignaun instante de tiempo aleatorio dentro del primer 10 % del tiempo total de si-mulación. Es decir, si el tiempo de simulación total es de 50 segundos, todoslos nodos se “encenderán” aleatoriamente dentro de los primeros 5 segundosde simulación.Para lograr esto se utilizó un módulo de ns-3 que genera variables con dis-tribución uniforme entre los valores min y max que se le configuren. En estecaso, se utilizo min = 0 y max = 10 % SIM_STOP (siendo SIM_STOP el tiempototal de simulación).

Etapa 6 - Asignar los punteros del hardware al firmware de cada nodoCada nodo posee su propio conjunto de capas de abstracción por encima delhardware y es independiente al de otro nodo. En esta etapa, se le “asigna” alas funciones de la capa 1, la HAL, de cada nodo los punteros a los objetoscon los que deben interactuar.

Etapa 7 - Habilitar módulo NetAnim En esta etapa se habilita el móduloNetAnim que genera un archivo XML el cual es utilizado para obtener unaanimación gráfica de la simulación.

Etapa 8 - SimularPor último, una vez que están todos los componentes generados y los pará-metros de la simulación configurados, se procede a iniciar la simulación ensí.

3.2.2. Simulación del firmware de los nodos

El firmware de los nodos consiste en librerías que proveen funciones (o APIs)que le permiten al usuario interactuar con el hardware o realizar acciones a ba-jo nivel como por ejemplo establecer callbacks para cuando se dispara un timero recibe un paquete de red, o indicar el modo de funcionamiento de un pinGPIO. Estas librerías se agrupan según su funcionalidad y cada plataformade hardware implementada en el entorno de simulación tendrá sus libreríasde firmware. A su vez, cada grupo funcional se divide en capas de abstraccióncomo se mencionó en la sección 2.1.Dado que el presente trabajo está utilizando el nodo NodeMCU como ejem-plo de plataforma de hardware, en lo que respecta al firmware también se im-plementaron las APIs que provee el fabricante Espressif. De esta manera, unaaplicación desarrollada para ser compatible con el nodo NodeMCU, tambiénlo será con el entorno de simulación utilizando la plataforma de hardware dedicho nodo.


En la figura 3.3 se ve representado el esquema de organización del firmwareimplementado en este trabajo. Un listado completo de las APIs implemen-tadas en este trabajo puede encontrarse en el apéndice C. A continuación sedetallan cada uno de los grupos funcionales del firmware.

FIGURA 3.3: Estructura de archivos del firmware del nodo No-deMCU.

Funciones de GPIO

El nodo NodeMCU posee 9 pines para ser utilizados como entrada/salidadigital. En este caso, además de implementar las APIs para interactuar conlos pines, se modeló el comportamiento del hardware dado que el simuladorns-3 no provee ningún módulo que modele pines.Cada pin puede funcionar como entrada o como salida. El estado de cada pinse registra en un archivo de salida con formato VCD (del inglés Value ChangeDump). Cuando el pin funciona como salida, puede tomar sólo dos estadosvalidos: ’0’ o ’1’. En los momentos en los que el pin este funcionando comoentrada, se representa con un estado ’X’ en el archivo VCD de salida. Por elcontrario, cuando el pin funciona como entrada, se simula la señal externacon una variable que el pin lee cada vez que se le requiere. A esta variablese le asigna un valor de ’0’ o ’1’ según un archivo VCD de entrada que elusuario debe proveer antes de iniciar la simulación. Este archivo es leído poruna función de configuración del módulo antes de iniciar la simulación y creaeventos en instantes de tiempo indicados en el archivo VCD de entrada paraasignarle el valor requerido a esta variable.

Por el lado de las APIs, se implementaron dos capas de abstracción:


Capa 1: son las APIs que brinda Espressif en el manual de referencia deAPIs [42] relacionadas con los GPIO.

Capa 2: son APIs similares a las utilizadas en las funciones E/S (entra-da/salida) de Arduino [43]. Esta capa de abstracción permitiría even-tualmente cambiar de plataforma de hardware sin cambiar el código delas capas superiores ya que la interfaz que brinda no depende de lasAPIs de Espressif.

Las APIs de esta categoría configuran el modo de operación (entrada o sali-da) de cada pin, así como también establecen el valor de salida o configuraninterrupciones y asignan callbacks en los casos que los pines funcionen comoentrada.

Funciones relacionadas a la energía y consumo

En esta categoría se implementaron funciones para registrar el consumo deenergía de los nodos para luego generar un reporte de salida con la cantidadde energía consumida en transmisiones, recepciones o en estado de reposopara cada nodo. Además, se implementó una API para que el usuario puedacambiar la potencia de transmisión de la radio del nodo tal como ocurre en elNodeMCU utilizando la API provista por Espressif.

Funciones de Timers

El nodo NodeMCU posee un timer de hardware y, tomando este como refe-rencia, implementa timers por software. Al igual que ocurre con los GPIOs, enesta categoría además de implementar las APIs para interactuar con el timer,se modeló el comportamiento del timer de hardware.El timer de hardware del NodeMCU funciona como una cuenta regresiva. Secarga un registro CUENTA con un valor inicial a partir del cual comenzar acontar. Cuando la cuenta llega a cero, se ejecuta la funcion de callback que sehaya asignado. Además este timer puede configurarse en dos modos: auto-feed-mode y non-auto-feed-mode:

auto-feed-mode: al llegar la cuenta a cero, el registro CUENTA vuelve atomar el valor de carga inicial y comienza la cuenta regresiva una vezmás.

non-auto-feed-mode: al llegar la cuenta a cero, el registro CUENTA toma elmáximo valor posible (0x7fffff) y comienza la cuenta regresiva unavez más.

El modelo del timer implementado posee el mismo comportamiento que eldel NodeMCU y soporta los mismos modos de operación.

Por el lado de las APIs, se implementaron dos capas de abstracción:

Capa 1: son las APIs que brinda Espressif en [42] relacionadas con lostimers.

Capa 2: son APIs similares a las utilizadas en las funciones de tiem-po de Arduino [43]. Esta capa de abstracción permitiría eventualmente


cambiar de plataforma de hardware sin cambiar el código de las capassuperiores ya que la interfaz que brinda no depende de las APIs de Es-pressif.

Las APIs de esta categoría se encargan de inicializar y cancelar tanto el timersde hardware como los desoftware, así como también establecer las funcionesde callbacks que se deben ejecutar al “dispararse” estos timers y establecer elmodo de operación.

Funciones de interfaces UART

El nodo NodeMCU posee dos interfaces periféricas UART. Por defecto, sólola UART0 está activa y funcionando como interfaz de salida para debugging.En el caso que el nodo se configure para trabajar con doble UART, la UART0funcionaria como transmisión/recepción y UART1 como interfaz de salidapara debugging.En este caso también se modelo el comportamiento de la UART mediante có-digo, pero sólo el caso por defecto. Es decir que sólo se modeló la UART0 ensu función de reporte de salida para debugging. En este modo de operación, elmodelo de la UART muestra, por pantalla lo que transmite también lo regis-tra en un archivo de salida. Se hablará en detalle sobre este archivo de salidade la UART en la sección 3.2.3.

Con respecto a las APIs, se implementaron las provistas por Espressif quefuncionen con el modo de operación modelado. También se implementó elmacro os_printf que facilita la escritura de datos en la UART.

Funciones de Wi-Fi

Para los modelos de hardware de las interfaces Wi-Fi se utilizan los módulosque brinda ns-3, los cuales fueron agregados al nodo durante la etapa 3 de lageneración de los componentes “físicos”. Por lo tanto en este caso sólo hacefalta implementar las APIs para que interactúen con estos modelos.Las APIs implementadas son un conjunto reducido de las provistas por Es-pressif pero son suficientes para realizar las siguientes acciones:

Establecer y consultar el modo de operacion (Soft-AP, Station, o Station-AP (ambas).

Asociarse y desasociarse a un Access Point (AP) en modo Station.

Escanear todos los AP disponibles.

Obtener el indicador de fuerza de señal recibida (RSSI, del inglés Recei-ved Signal Strength Indicator) de todos los AP presentes.

Generar un BSS con un SSID cuando esta en modo Soft-AP.

Establecer una dirección IP para cada interfaz.

Establecer una dirección MAC para cada interfaz.

Establecer el canal en el que operan las interfaces.


Funciones del protocolo UDP

Las APIs en este grupo se encargan de modelar la capa de transporte delmodelo OSI. Si bien las APIs provistas por Espressif para el nodo NodeM-CU cubren ambos protocolos UDP y TCP, en este trabajo se implementaronlas relacionadas con UDP pero que aun asi son suficientes para realizar lassiguientes acciones:

Abrir puertos y enviar paquetes.

Escuchar en puertos en espera de paquetes recibidos.

Cerrar puertos.

Establecer y ejecutar funciones cuando se envían paquetes de maneraexitosa (sent callbacks).

Establecer y ejecutar funciones cuando se reciben paquetes de maneraexitosa (received callbacks).

Las APIs en este grupo le permiten a los nodos comunicarse entre sí.

3.2.3. Estructura de soporte y archivos de configuración

Como se mencionó en la sección 2.1 del capítulo 2, el entorno de simulacióncontiene una estructura de configuración y soporte que se detalla en esta sec-ción. En primer lugar se explican los archivos de configuración, luego losscripts y herramientas auxiliares, y por último los archivos de salida. En elapéndice D se encuentra un manual de usuario que explica como debe utili-zarse el entorno de simulación.

Archivos de configuración de la simulación

Se encuentran en src/myWSN/model/USER como se ve en la figura 3.4. Setrata de tres archivos de configuración: WSN_user.conf, WSN_nodes.confy WSN_position.conf, y el directorio ALGORITHMS.

Directorio ALGORITHMSEn este directorio se encuentran los algoritmos disponibles para simular. Ca-da algoritmo es un directorio en sí mismo que puede contener archivos fuentey headers. El usuario debe crear un nuevo directorio y copiar en este todos losarchivos fuente y headers del algoritmo a simular.

Archivo WSN_user.confEste archivo contiene la siguiente información:

NS3_DIR: el path al directorio raíz de ns-3.

NUM_NODES: es la cantidad de nodos que se van a simular.


FIGURA 3.4: Archivos de configuración de la simulación.

NODE_CFG_FILE: el archivo que se debe utilizar para configurar losnodos de la simulación.

NODE_POS_FILE: el archivo que se debe utilizar para configurar la po-sición de los nodos en la simulación.

Archivo configuración de nodosEs el archivo que se indicó como <NODE_CFG_FILE>. Este archivo posee unalinea por cada nodo donde cada linea está formada por campos separadospor el caracter “∼”. La información que provee cada campo es la siguiente:

1. Es el número de nodo.

2. Es la plataforma de hardware seleccionada. Debe existir con el mismonombre dentro de src/myWSN/model/NODE.

3. Es la capa de abstracción hasta la cual se simulará. Siempre debe llamar-se LAYX, donde X es el nivel de la capa hasta donde se quiere simular.

4. El algoritmo que se cargara en el nodo. Debe existir con el mismo nom-bre dentro de src/myWSN/model/USER/ALGORITHMS.


5. La función de main que se ejecutará cuando el nodo haya terminado elproceso de inicialización.

6. La función de setup que se ejecutará apenas inicie el nodo.

Por ejemplo, la linea0∼NodeMCU∼LAY1∼Sync_interrupt∼main_loop∼user_setup∼indica los siguientes campos:

Nodo: 0.

Plataforma de HW: NodeMCU.

Nivel de capas de abstraccion: Nivel 1.

Algoritmo a cargar: Sync_interrupt.

Función a ejecutar cuando finalice la inicalización: main_loop.

Función a ejecutar durante la etapa de inicialización: user_setup.

Archivo configuración de la posición de los nodosEs el archivo que se indicó como <NODE_POS_FILE>. Este archivo posee unalinea por cada nodo donde cada linea está formada por campos cuatro cam-pos separados por el caracter “∼”. La información que provee cada campo esla siguiente:


2. Posición inicial del nodo en X.

3. Posición inicial del nodo en Y.

4. Posición inicial del nodo en Z.

Herramientas auxiliares / scripts

Los scripts son las herramientas que brindan soporte al entorno. La tabla 3.1presenta un breve resumen de cada uno y en el resto de la sección se losexplica en detalle.

TABLA 3.1: Listado de los scripts de soporte al entorno.

Nombre Función resumida

add_to_ns3.sh Agrega el entorno al simulador ns-3 como unmódulo nuevo.

sim_run.sh Lee los archivos de configuración y correla simulación.

merge_vcd.sh Une los archivos de salida “vcd” de cadanodo en uno solo.


Script add_to_ns3.shEste script se ejecuta sólo una vez cuando se instala el entorno. Al ejecutarlo,genera un módulo nuevo en ns-3 utilizando la herramienta waf que brindael propio simulador y luego relaciona ese nuevo módulo con el entorno desimulación soft link. Por último, se encarga de ejecutar la instrucción ./wafconfigure del ns-3 para que el simulador reconozca el nuevo módulo.

Script sim_run.shEste script se ejecuta para correr una simulación. Al hacerlo, internamen-te ocurren varios pasos: primero se borra todo el contenido del directoriosrc/myWSN/model/RUN. Este directorio se usa para generar todos los ar-chivos necesarios para la simulación sin necesidad de modificar algunos ar-chivos que funcionan como plantillas como veremos a continuación. Luego,para cada nodo, el script se encarga de copiar todos los archivos de las ca-pas de abstracción necesarias, al directorio RUN agregándole un prefijo conel número de cada nodo para que no se superpongan los archivos. Ademásde agregarle un prefijo al archivo, también se le configura un namespace atodas las funciones y variables de cada archivo para poder relacionar cadafunción de manera unívoca con el nodo. Al realizar estos dos pasos, se lograsimular un stack de memoria independiente para cada nodo ya que cada no-do estará ejecutando funciones que corresponden a distintos namespace y,por lo tanto, son funciones distintas.A continuación, se prosigue haciendo los mismos pasos pero con los archivosdel algoritmo que el usuario desea ejecutar.Seguidamente, se borra todo el contenido de archivos de salida del directorioUSER/output de simulaciones anteriores y así dejar lista la estructura paragenerar nuevos archivos de salida.En este momento es que el entorno esta listo para iniciar la simulación. Elscript da inicio a la simulación mediante la instrucción ./waf -run WSN_simque le indica al ns-3 que debe correr la simulación de nombre WSN_sim.

Una vez finalizada la simulacion, el último paso de este script es procesar losarchivos de salida de los pines de GPIO. Como se mencionó en 3.2.2, el firm-ware de los GPIOs genera un archivo en formato “VCD” para cada nodo. Sibien estos archivos son útiles por sí solos, puede existir la necesidad de com-parar el estado de los pines entre dos o más nodos a la vez. Por lo tanto, esprovechoso generar un único archivo que contemple toda la red y que cadanodo sea un módulo con sus propios pines. De esta manera se puede obser-var el estado de los pines de todos los nodos en la misma sesión de GtkWave,por ejemplo. Este último paso se logra ejecutando el script merge_vcd.shque se detalla a continuación.

Script merge_vcd.shEl formato VCD [44, 45] fue definido junto con el lenguaje descriptor de hard-ware Verilog por la IEEE. Es un formato muy utilizado para representar seña-les digitales y por eso se decidió utilizarlo como formato de salida para lospines GPIO.Como se mencionó anteriormente, cada nodo genera su propio archivo VCD.


Este script toma todos los archivos VCD que se le pasen y los unifica en unsolo archivo con el nombre del primer parámetro que se le pase como argu-mento. El resultado es un archivo que cumple con el formato VCD y poseeuna estructura modular jerárquica siendo el nivel superior un objeto que re-presenta la red llamado WSN y los sub-módulos representan los nodos comose ve en la figura 3.5.

FIGURA 3.5: Estructura modular jerárquica en el VCD.

Archivos de salida

Cuando finaliza la simulación, la información que provee estará disponibledentro del directorio src/myWSN/model/USER/output como se ve en lafigura 3.6.

FIGURA 3.6: Salida de la simulación.

Información de la energía consumidaDentro de del directorio output/energy se encuentra un archivo por cadanodo cuyo contenido reporta la cantidad de energía consumida en cada nodoy como se repartió dicho consumo entre transmisiones, recepciones y estadode reposo. En la figura 3.7 se observa un ejemplo de estos reportes.

Información de los pines GPIODentro del directorio output/GPIO se encuentran los archivos en formatoVCD para cada nodo, y para la red en conjunto. Estos archivos contienen elestado de todos los pines GPIO de cada nodo durante toda la simulación ypueden visualizarse utilizando cualquier herramienta que interprete este for-mato como por ejemplo GTKWave (figura 3.8).

Animación gráfica de la simulación - NetAnim

NetAnim [46] es una herramienta provista por ns-3 que brinda una interfazgráfica para analizar una simulación. Dentro del directorio output/netAnim


FIGURA 3.7: Reportes de energía consumida.

FIGURA 3.8: Visualización del estado de los pines GPIO utili-zando GTKWave.

se encuentra el archivo XML necesario para visualizar la simulación con Ne-tAnim. Para abrir la herramienta, hay que ejecutar el archivo NetAnim queesta dentro de ns-allinone-3.28.1/netanim-3.108. Una vez cargadoel XML se obtendrá una visualización gráfica de la simulación como se ve enla figura 3.9.

Información de la actividad de la red - PCAPEl entorno de simulación también proporciona un reporte detallado sobrela actividad de la red. En el directorio output/pcap se genera un archivopor cada interfaz de red presente en la simulación. Estos archivos de formato.pcap contienen información del trafico de la red durante toda la simulación ypueden ser leídos utilizando herramientas de análisis de redes como WireS-hark o TCPDump. La figura D.7 muestra una captura de pantalla del softwareWireshark visualizando uno de los archivos de salida del entorno de simula-ción.

Registros de salida de la UARTEn el directorio output/UART se encuentra un archivo de texto por cada no-do. Este archivo es un log de todo lo que se “escribió” en la UART durante la


FIGURA 3.9: Visualización de la simulación utilizando NetA-nim.

FIGURA 3.10: Archivo de salida .pcap abierto con Wireshark.

simulación. Es lo mismo que se observaría si se tuviera el nodo real conectadoa una PC. La figura 3.11 muestra una ejemplo de estos archivos.


FIGURA 3.11: Archivo de salida de reporte de una UART.

43

Capítulo 4

Ensayos y Resultados

En este capítulo se describen los ensayos realizados para comprobar el fun-cionamiento del entorno de simulación y se discuten los resultados obteni-dos.

4.1. Introducción a los ensayos

En primer lugar es importante destacar que los ensayos realizados no buscanevaluar los algoritmos utilizados sino que se busca, por un lado, compararel comportamiento de los nodos en la red real con el comportamiento en lared simulada, y por otro demostrar como el entorno de simulación permiteextrapolar ese comportamiento a ensayos con redes de mayor cantidad denodos que serian poco prácticos de realizar en redes reales.

En el primer ensayo se busca comparar, contra una red real, el funcionamien-to del entorno, en particular la posibilidad de tener nodos ejecutando algo-ritmos distintos, y las APIs relacionadas con la implementación del estándar802.11 y el protocolo de comunicación UDP. Luego, en el segundo ensayo secompara el desempeño mediante la ejecución de un algoritmo de sincroniza-ción muy utilizado en redes WSN. En este caso se busca poner a prueba a losnodos ejecutando un algoritmo distribuido y evaluar el funcionamiento delas APIs relacionadas a los pines GPIO. Por ultimo, en el ensayo 3 se realizala misma simulación que en el ensayo 2 pero utilizando 30 nodos en lugarde 4. En este último ensayo ya no se realiza una comparación con una redreal, ya que esta última resulta muy difícil de implementar debido a la grancantidad de nodos que serian necesarios, sino que se busca demostrar cómoel entorno resulta ser sumamente práctico para estos casos.

4.2. Ensayo 1 - Hola mundo!

Se trata de una implementación simple con dos nodos a 1 metro de distanciauno del otro como se muestra en la figura 4.1.

Cada nodo ejecuta un codigo distinto que se representa mediante los diagra-mas de flujo de la figura 4.2

44 Capítulo 4. Ensayos y Resultados

FIGURA 4.1: Esquema de la red del Ensayo 1.

(A) Diagrama de flujo del nodo AP. (B) Diagrama de flujo del nodo STA.

FIGURA 4.2: Diagramas de flujo de los nodos de el Ensayo 1.

El ensayo consiste en un nodo, el nodo 0, que al iniciar es configurado comoAccess Point (AP) y el otro, nodo 1, configurado como Station (STA). El AP creaun Basic Service Set (BSS) con SSID “NS3_L1” en el canal 8. Luego, el nodo STAescanea los SSID disponibles en busca del SSID “NS3_L1”, al encontrarlo enel canal 8 selecciona este canal y se asocia al BSS. Por último, el STA le envíaun mensaje con el contenido ’Hola’ al AP quien, al recibirlo contesta ’Holamundo!’. El STA muestra este mensaje por la UART en cuanto lo recibe.

Para implementar la red real se utilizaron dos nodos de la plataforma No-deMCU dispuestos a aproximadamente 1 metro, como se ve en la figura 4.3.

Por otro lado, los archivos de configuración del entorno de simulación conte-nían la siguiente información:

4.2. Ensayo 1 - Hola mundo! 45

FIGURA 4.3: Red implementada para el Ensayo 1.

WSN_user.conf:

1 NS3_DIR="~/facu/ t e s i s /NS3/ns−a l l inone −3.28.1/ ns −3 .28 .1 "2 NUM_NODES=23 NODE_CFG_FILE=" ./WSN_nodes . conf "4 NODE_POS_FILE=" ./ WSN_position . conf "

CÓDIGO 4.1: Archivo de configuraciónWSN_user.conf utilizado en el Ensayo 1.

WSN_nodes.conf:

1 # Use the fol lowing format to i n d i c a t e which Main and Setupfunct ion should each node run :

2 # [ Node_ID ] ~ [MAIN_FUNCTION] ~ [SETUP_FUNCTION] ~ [ comment ]3 # Anything a f t e r the l a s t separa tor ( ~ ) w i l l be considered a

comment4 # For example : 0~main_node~setup_as_root~This i s a comment5 0~NodeMCU~LAY1~Func_Test_AP~main_loop~user_setup~6 1~NodeMCU~LAY1~Func_Test_STA~main_loop~user_setup~

CÓDIGO 4.2: Archivo de configuraciónWSN_nodes.conf utilizado en el Ensayo 1.

WSN_position.conf:

1 0~00~00~02 1~01~00~0

CÓDIGO 4.3: Archivo de configuraciónWSN_position.conf utilizado en el Ensayo 1.

Como se puede observar en el archivo WSN_nodes.conf, ambos nodos usanla plataforma NodeMCU con sólo la primer capa de abstracción simulada,pero el nodo 0 utiliza el algoritmo “Func_Test_AP” mientras que el nodo 1“Func_Test_STA”.


Resultados

Se realizó el ensayo en la red real de la figura 4.3 teniendo los nodos conecta-dos a una PC y registrando todos los datos que transmitían por la UART. Porotro lado se corrió la simulación y se compararon los archivos de salida de laUART simulada con los que se registraron de los nodos reales. El comporta-miento de los nodos fue el mismo tanto en la red real como en la simulada. Enla figura 4.4a se pueden ver los registros del setup y el estado una vez creadoel BSS provenientes del nodo AP real, mientras que la figura 4.4b muestra losmismos registros pero del nodo simulado.

(A) Registro de la UART del nodo AP“real”.

(B) Registro de la UART del nodo AP “si-mulado”.

FIGURA 4.4: Salidas de la UART de los nodos AP (A) real y(B) simulado.

Con respecto al nodo STA, la figura 4.5a muestra la salida de la UART delnodo real mientras que la figura 4.5b muestra su contraparte simulada.

Este ensayo sirvió para poder comprobar que el entorno es capaz de simularuna red basándose en los archivos de configuración y lograr el mismo com-portamiento que la red real de manera exitosa.

4.2. Ensayo 1 - Hola mundo! 47

(A) Registro de la UART del nodo STA“real”.

(B) Registro de la UART del nodo STA“simulado”.

FIGURA 4.5: Salidas de la UART de los nodos STA (A) real y(B) simulado.


4.3. Ensayo 2 - Algoritmo de sincronización con 4 nodos

Siguiendo con los ensayos en los que se compara una red real con una si-mulada, en este ensayo se implementó un algoritmo basado en el algoritmode sincronización TPSN [47-49]. Se utilizaron cuatro nodos los cuales en unaprimera etapa se organizan automáticamente en una red con una topologíacomo la de la figura 4.6 y luego cada nodo se sincroniza con el nodo inmedia-tamente superior.

FIGURA 4.6: Esquema de red del Ensayo 2.

Si bien el algoritmo TPSN en sí no es de interés en este trabajo, se explicarábrevemente sus principios para comprender lo que sucede durante el ensayo.Como se detalla en [47], la sincronización se lleva a cabo basándose en elintercambio de paquetes entre dos nodos que se esquematiza en la figura 4.7.Los instantes de tiempo T1 y T4 representan instantes de tiempo relativos alclock del nodo A mientras que T2 y T3 son relativos al clock del nodo B.

FIGURA 4.7: Esquema de intercambio de mensajes para sin-cronización.

El intercambio comienza en el instante T1 cuando el nodo A le envía un pa-quete al nodo B. Este paquete contiene el valor de T1. El nodo B recibe elpaquete en el instante T2, siendo T2 = T1 + ∆ + d donde ∆ representa eldesfasaje entre los clocks del nodo A y nodo B, y d representa el tiempo depropagación del paquete. Luego, en el instante T3 el nodo B responde con

4.3. Ensayo 2 - Algoritmo de sincronización con 4 nodos 49

otro paquete de acknowledge. Este paquete contiene los valores de T1, T2 y T3.El nodo A recibe este paquete en el instante T4. Ahora el nodo A conoce elvalor de los cuatro instantes de tiempo y por lo tanto puede calcular ∆ y d dela siguiente manera:

∆ =(T2 − T1) − (T4 − T3)

2; d =

(T2 − T1) + (T4 − T3)

2(4.1)

Una vez que el nodo A calcula el valor de ∆, puede utilizar este desfasajepara ajustar su clock y sincronizarlo al clock del nodo B.

Este es el principio de sincronización sobre el cual se basa el algoritmo delensayo 2. Además, para poder tener una manera visual de comprobar dichasincronización, se agregó una rutina que genera una onda cuadrada con unperiodo de 5 segundos y un duty cycle de 50 % en uno de los pines GPIO delnodo. En particular esta señal se genera en el pin 2 del módulo ESP8266, quese corresponde con el pin D4 del NodeMCU, el cual está conectado a un LED.

Para implementar la red real, se utilizaron cuatro nodos NodeMCU y se lesconecto el pin D4 a un osciloscopio de cuatro canales para poder visualizarla señal cuadrada como se ve en la figura 4.8.

FIGURA 4.8: Implementación de la red real para el Ensayo 2.


Para poder visualizar como quedo conformada la topología de la red, es decir,ver que se cumpla que haya sólo un nodo en nivel el nivel 0, dos en el nivel 1 yel restante en el nivel 2, se programó en el algoritmo que los nodos imprimanpor la UART que rol tomaron durante la etapa de generación de la topologíade red. La figura 4.9 muestra los extractos de la UART de cada nodo dondefigura la identificación del nodo y el nivel de topología en el que se sitúa.

FIGURA 4.9: Extracto de la UART de cada nodo mostrando elnivel de topología de red.

Luego, se observa en el osciloscopio el momento en el que se sincronizan lasseñales en la figura 4.10.

FIGURA 4.10: Sincronización de las señales en el osciloscopio.

Seguidamente, se procedio a realizar la misma prueba en el entorno de simu-lacion.

Primero, se especificó que la simulación constaría de cuatro nodos ejecutandoel algoritmo Sync_interrupt en los archivos de configuración como se muestraa continuación:

WSN_user.conf:

1 NS3_DIR="~/facu/ t e s i s /NS3/ns−a l l inone −3.28.1/ ns −3 .28 .1 "2 NUM_NODES=43 NODE_CFG_FILE=" ./WSN_nodes . conf "4 NODE_POS_FILE=" ./ WSN_position . conf "

4.3. Ensayo 2 - Algoritmo de sincronización con 4 nodos 51

WSN_nodes.conf:

1 # Use the fol lowing format to i n d i c a t e which Main and Setupfunct ion should each node run :

2 # [ Node_ID ] ~ [MAIN_FUNCTION] ~ [SETUP_FUNCTION] ~ [ comment ]3 0~NodeMCU~LAY1~Sync_ interrupt~main_loop~user_setup~4 1~NodeMCU~LAY1~Sync_ interrupt~main_loop~user_setup~5 2~NodeMCU~LAY1~Sync_ interrupt~main_loop~user_setup~6 3~NodeMCU~LAY1~Sync_ interrupt~main_loop~user_setup~

Una vez configurada, se corrió la simulación.

Al igual que con la red real, en la figura 4.11 se evalúan los archivos de salidade la UART para verificar que la topología de la red que se generó sea lamisma que en la red real.

FIGURA 4.11: Extracto de la UART de cada nodo simuladomostrando el nivel de topología de red.

Se puede observar que la red simulada asumió la misma topología que la realcon un nodo en el nivel 0, dos nodos en el nivel 1 y el restante en el nivel 2.

Luego, para visualizar la sincronización a través de la señal del pin 2, se uti-liza el archivo de salida que contiene el estado de todos los pines GPIO decada nodo simulado en un formato VCD. La figura 4.12 muestra el estado delpin 2 de cada nodo a lo largo del tiempo.

FIGURA 4.12: Sincronización en nodos simulados visualizadocon GtkWave.

Se puede observar que los nodos simulados se sincronizan de la misma ma-nera que los nodos reales lo hacen en la red real.


4.4. Ensayo 3 - Algoritmo de sincronización con 30 no-dos

En este ensayo se utiliza el mismo algoritmo que en el ensayo 2 pero imple-menta una red de 30 nodos. Si se quisiera implementar una red real con estacantidad de nodos, demandaría mucho tiempo y esfuerzo y no seria viablepara una etapa de depuración del algoritmo. Sin embargo implementarla eneste entorno de simulación requiere unicamente configurar adecuadamentelos archivos de configuración.

La figura 4.13 muestra la distribución geográfica de los nodos utilizando laherramienta NetAnim. Esta ubicación se condice con lo configurado en elarchivo WSN_position.conf.

FIGURA 4.13: Distribución de los nodos del Ensayo 3. Imagentomada utilizando NetAnim.

Luego, utilizando el software GtkWave se puede observar la señal en los pines2 de cada nodo y ver como se sincronizan (figura 4.14).

Con respecto a la topología, si se analizan los archivos de la salida UART decada nodo, se puede ver que el nodo 11 se sitúa en el nivel 0, los nodos 9 y 17en el nivel 1 y el resto en el nivel 2.

4.5. Resultados 53

FIGURA 4.14: Sincronización en nodos simulados del Ensayo3 visualizado con GtkWave.

En este ensayo no existe una red real contra la cual comparar los resultados,pero se puede apreciar lo útil que resulta este entorno para etapas tempranasde depuración de algoritmos implementando redes de considerable cantidadde nodos.

4.5. Resultados

De los ensayos realizados se puede concluir que el entorno de simulacióndesarrollado se comporta de la misma manera que una red real y por eso re-sulta ser una herramienta muy útil para depurar algoritmos distribuidos enuna etapa temprana del diseño. Además, al tener disponible toda la informa-ción de los nodos junta, se pueden obtener métricas que de otra manera resul-tarían imposibles de obtener. Como por ejemplo métricas donde se compareninstantes de tiempo en los que se ejecutan ciertos eventos en nodos distintos.

55

Capítulo 5

Conclusiones

En este capítulo se describen los principales aportes del trabajo realizado y semencionan posibles maneras de continuarlo.

5.1. Conclusiones generales

Como resultados de la realización del presente trabajo, se obtuvieron los si-guientes:

Un entorno que permite simular una red WSN, utilizando el mismocódigo que se usa para los nodos de una red WSN real.

El modelo de la plataforma de hardware NodeMCU para utilizar en di-cho entorno de simulación.

Un conjunto de capas de abstracción, en particular la HAL, compatiblecon las APIs provistas por Espressif para utilizar con los modelos dehardware del NodeMCU.

Una metodología para agregar distintas plataformas de hardware y otras“capas simuladas” al entorno de simulación.

Teniendo en cuenta los objetivos y el alcance propuestos para el presente tra-bajo en la sección 1.3 y en base a los ensayos y a los resultados obtenidos, sepuede afirmar que se cumplió con el objetivo propuesto referido a implemen-tar un entorno de simulación de algoritmos para WSN en base al diseño demodelos de hardware y firmware.

5.2. Próximos pasos

Como trabajos a futuro se proponen las siguientes tareas:

Ampliar las plataformas de hardware soportadas. En particular imple-mentar un nodo con el estándar 802.15.4.

Modelar sensores y generar modelos de procesos físicos que proveandatos a los sensores.

56 Capítulo 5. Conclusiones

Mejorar la forma en la que se configura la simulación. En particular sepodría hacer con un solo archivo en formato XML o algun otro formatoestándar y permitir una mayor variedad de componentes a configurar.

Permitir configurar modelos de movilidad en los nodos.

57

Apéndice A

Calculo de pérdida porpropagación con modelo Friis

El modelo de pérdida por propagación de Friis [24] se describe mediante laecuación A.1:

Pr

Pt=ArAt

d2λ2(A.1)

donde Para una antena isotrópica se cumple A.2.

Aisotr. =λ2

4π(A.2)

Y la ecuación A.1 se convierte en A.3.

Pr

Pt=

λ2

(4πd)2(A.3)

donde

Pr es la potencia recibida (mW).

Pt es la potencia de transmisión (mW).

Ar es el área efectiva de la antena receptora.

At es el área efectiva de la antena transmisora.

λ es la longitud de onda (m).

d es la distancia entre transmisor y receptor (m).

Calculando para una distancia de d0 = 1 metro y una frecuencia de 2.4 GHzse obtiene (en dB):

λ2,4GHz =c

2,4 GHz≈ 0,125 m (A.4)

L0 = 20 logλ

4πd0= −40,046 dB (A.5)

58 Apéndice A. Calculo de pérdida por propagación con modelo Friis

Por lo tanto, la perdida de señal por propagación a 1 metro para una frecuen-cia de 2.4 GHz mediante el modelo de Friis es: 40.046 dB

59

Apéndice B

Ejemplo de uso de un helper

En este apéndice se analiza paso a paso el código para crear una conexiónpunto a punto entre dos nodos que se encuentra en el tutorial de ns-3. Seutilizan helpers con el fin de explicar el uso de estos.

Las primeras dos lineas de código se encargan de crear los objetos Node dens-3 que representan nuestros nodos en la simulación.

NodeContainer myNodes;myNodes.Create (2);

El objeto myNodes es un “contenedor” que almacena los punteros a los nodoscreados. En este caso se crearon dos nodos, por lo tanto myNodes almacenaráun puntero a cada nodo.

El siguiente paso es asignarle a cada uno de estos nodos una interfaz de redpunto a punto y conectarlas entre ellas. En ns-3, esto significa instalar en cadanodo un objeto de la clase PointToPointNetDevice para la interfaz de redy luego conectarlas entre si con un objeto de la clase PointToPointChannelque representa el cable que conecta ambos nodos. El simulador ns-3 proveeun helper particular para este tipo de conexiones que corresponde a la clasePointToPointHelper.

En las siguientes lineas se crea el helper y se le configuran ciertos atributos.

PointToPointHelper pointToPoint;pointToPoint.Set DeviceAttribute (

"DataRate", StringValue ("5Mbps"));pointToPoint.SetChannelAttribute (

"Delay", StringValue ("2ms"));

En la primera linea se instancia un objeto de la clase PointToPointHelpery se lo llama pointToPoint. Este es helper en sí y es el encargado de creary configurar las interfaces PointToPointNetDevice, crear y configurar elcanal PointToPointChannel, y conectar ambas interfaces al canal.Luego, en la segunda linea, mediante el método SetDeviceAttribute sele indica al helper que le asigne al atributo “DataRate” un valor de “5Mbps”

60 Apéndice B. Ejemplo de uso de un helper

cuando cree un objeto de la clase PointToPointNetDevice.Finalmente, en la tercer linea, mediante el método SetChannelAttributese le indica al helper que le asigne al atributo “Delay” un valor de “2ms” cuan-do cree un objeto de la clase PointToPointChannel.

Hasta acá se tiene el helper configurado pero aun no se han creado las inter-faces ni el canal en los nodos. Las siguientes lineas de codigo realizan estospasos.

NetDeviceContainer devices;devices = pointToPoint.Install (myNodes);

La primera linea genera un “contenedor” para almacenar punteros a dispo-sitivos de red.En la segunda linea, mediante el método pointToPoint.Install (myNodes),el helper instanció objetos PointToPointNetDevice y los asoció a cada no-do que esté almacenado dentro del “contenedor” myNodes. Ambos objetosPointToPointNetDevice fueron creados con el atributo “DataRate” esta-blecido en “5Mbps”.Por otro lado, también se instanció un objeto de la clase PointToPointChannelal cual se le asignó un valor de “2ms” al atributo “Delay”.

En este ejemplo puede verse como con solo cuatro lineas de código (consi-derando solo las lineas que hacen referencia al helper) se logró instanciar yconfigurar un canal por un lado, e instanciar, configurar, asociar al nodo yconectar al canal a dos interfaces de red. De haberlo hecho mediante instruc-ciones del core de ns-3, hubiera llevado mas de 20 lineas de código.

Es importante notar como se le “pasan” atributos al helper para que este con-figure el objeto en el momento que lo tenga que crear.

Existen otros helpers más complejos, como por ejemplo el helper que crea lasinterfaces de red Wi-Fi, WifiHelper, que requiere no solo que se le “pasen”atributos, sino que además requiere que se le “pasen” otros helpers de las cla-ses YansWifiPhyHelper y WifiMacHelper para poder asignarle objetosque representan las capas PHY y MAC, respectivamente, a la interfaz Wi-Ficuando esta sea instanciada.

61

Apéndice C

APIs implementadas

C.1. GPIO APIs

1 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗2 ∗ FunctionName : g p i o _ d i g i t a l W r i t e ( u i n t 8 _ t pin , bool value )3 ∗ Descr ipt ion : Writes e i t h e r t rue or f a l s e to the i n d i c a t e d pin .4 ∗ Parameters : u i n t 8 _ t pin : pin number to wri te a t5 ∗ bool value : the boolean value to wri te6 ∗ Returns : none7 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/8 void g p i o _ d i g i t a l W r i t e ( u i n t 8 _ t pin , u i n t 8 _ t value ) ;9

10 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗11 ∗ FunctionName : gpio_dig i ta lRead ( u i n t 8 _ t pin )12 ∗ Descr ipt ion : Reads value of the i n d i c a t e d pin . Pin mode must be

"INPUT"13 ∗ Parameters : u i n t 8 _ t pin : pin to read from14 ∗ Returns : bool : The value of the pin ( t rue f o r High or

f a l s e f o r Low)15 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/16 u i n t 8 _ t gpio_digi ta lRead ( u i n t 8 _ t pin ) ;17

18 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗19 ∗ FunctionName : gpio_pinMode ( u i n t 8 _ t pin , u i n t 8 _ t mode)20 ∗ Descr ipt ion : S e t s the pin on e i t h e r OUTPUT or INPUT .21 ∗ Parameters : u i n t 8 _ t pin : pin number to s e t mode22 ∗ u i n t 8 _ t mode : 0 ( output ) or 1 ( input )23 ∗ Returns : None24 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/25 void gpio_pinMode ( u i n t 8 _ t pin , u i n t 8 _ t mode) ;26

27

28 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗29 ∗ FunctionName : gpio_output_set30 ∗ Descr ipt ion : Set GPIO property .31 ∗ Parameters : uint32 set_mask : s e t high output ; 1 : high output ;

0 : no s t a t u s change ;32 ∗ uint32 clear_mask : s e t low output ; 1 : low output ;

0 : no s t a t u s change ;33 ∗ uint32 enable_mask : enable output b i t ;34 ∗ uint32 disable_mask : enable input b i t .35 ∗ Returns : None36 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/37 void gpio_output_set ( uint32 set_mask , uint32 clear_mask , uint32

enable_mask , uint32 disable_mask ) ;

62 Apéndice C. APIs implementadas

C.2. Timer APIs

1 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗2 ∗ FunctionName : hw_timer_ini t3 ∗ Descr ipt ion : i n i t i l i z e the hardware i s r t imer4 ∗ Parameters :5 ∗ FRC1_TIMER_SOURCE_TYPE source_type :6 ∗ FRC1_SOURCE, t imer use f r c 1 i s r as

i s r source .7 ∗ NMI_SOURCE, t imer use nmi i s r as i s r

source .8 ∗ u8 req :9 ∗ 0 , not autoload ,

10 ∗ 1 , autoload mode ,11 ∗ Returns : NONE12 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/13 void hw_timer_ini t (FRC1_TIMER_SOURCE_TYPE source_type , u i n t 8 _ t req )

;14

15 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗16 ∗ FunctionName : hw_timer_arm17 ∗ Descr ipt ion : s e t a t r i g g e r t imer delay f o r t h i s t imer .18 ∗ Parameters : uint32 val ( in uSeconds )19 ∗ Returns : NONE20 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/21 void hw_timer_arm ( u i n t 3 2 _ t val ) ;22

23 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗24 ∗ FunctionName : hw_timer_set_func25 ∗ Descr ipt ion : s e t the func , when t r i g g e r t imer i s up .26 ∗ Parameters : void (∗ user_hw_timer_cb_set ) ( void ) :27 ∗ t imer c a l l b a c k funct ion ,28 ∗ Returns : NONE29 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/30 void hw_timer_set_func ( void (∗ user_hw_timer_cb_set ) ( void ) ) ;31

32 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗33 ∗ FunctionName : os_timer_arm34 ∗ Descr ipt ion : Enable a mi l l i second timer .35 ∗ Parameters : os_ t imer_t ∗ptimer : t imer s t r u c t u r e .36 ∗ u i n t 3 2 _ t m i l l i s e c o n d s : timing ; uni t : mi l l i second .37 ∗ bool r e p e a t _ f l a g : whether the timer w i l l be

invoked repeatedly or not .38 ∗ Returns : NONE39 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/40 void os_timer_arm ( os_t imer_t ∗ptimer , u i n t 3 2 _ t mi l l i seconds , bool

r e p e a t _ f l a g ) ;41

42 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗43 ∗ FunctionName : os_timer_arm_us44 ∗ Descr ipt ion : Enable a microsecond timer .45 ∗ Parameters : os_ t imer_t ∗ptimer : t imer s t r u c t u r e .46 ∗ u i n t 3 2 _ t microseconds : timing ; uni t : microsecond .

C.3. UART APIs 63

47 ∗ bool r e p e a t _ f l a g : whether the timer w i l l beinvoked repeatedly or not .

48 ∗ Returns : NONE49 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/50 void os_timer_arm_us ( os_ t imer_t ∗ptimer , u i n t 3 2 _ t microseconds ,

bool r e p e a t _ f l a g ) ;51

52 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗53 ∗ FunctionName : os_timer_disarm54 ∗ Descr ipt ion : Disarm the timer .55 ∗ Parameters : os_ t imer_t ∗ptimer : t imer s t r u c t u r e .56 ∗ Returns : NONE57 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/58 void os_timer_disarm ( os_t imer_t ∗ptimer ) ;59

60 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗61 ∗ FunctionName : o s _ t i m e r _ s e t f n62 ∗ Descr ipt ion : Set t imer c a l l b a c k funct ion . The timer c a l l b a c k

funct ion must63 ∗ be s e t before arming a timer .64 ∗ Parameters : os_ t imer_t ∗ptimer : t imer s t r u c t u r e .65 ∗ os_t imer_func_t ∗pfunct ion : t imer c a l l b a c k

funct ion ; use66 ∗ t y p e c a s t i n g to pass funct ion as your

funct ion .67 ∗ void ∗parg : c a l l b a c k funct ion parameter .68 ∗ Returns : NONE69 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/70 void o s _ t i m e r _ s e t f n ( os_ t imer_t ∗ptimer , os_t imer_func_t ∗pfunction ,

void ∗parg ) ;

C.3. UART APIs

1 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗2 ∗ FunctionName : u a r t _ i n i t3 ∗ Descr ipt ion : I n i t i a l i z e baud r a t e s of the two UARTs .4 ∗ Parameters : UartBautRate uart0_br : UART0 baud r a t e ;5 ∗ UartBautRate uart1_br : UART1 baud r a t e ;6 ∗ Returns : none7 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/8 void u a r t _ i n i t ( UartBautRate uart0_br , UartBautRate uart1_br ) ;9

10 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗11 ∗ FunctionName : u a r t 0 _ t x _ b u f f e r12 ∗ Descr ipt ion : Send user−defined data through UART0.13 ∗ Parameters : u int8 ∗buf : data to be sent ;14 ∗ uint16 len : the length of data to be sent .15 ∗ Returns : None16 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/17 void u a r t 0 _ t x _ b u f f e r ( uint8 ∗buf , uint16 len ) ;18

19 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗20 ∗ FunctionName : u a r t 0 _ r x _ i n t r _ h a n d l e r21 ∗ Descr ipt ion : UART0 i n t e r r u p t process ing funct ion . Users can

process the


22 ∗ rece ived data in t h i s funct ion .23 ∗ Parameters : void ∗para : the pointer point ing to RcvMsgBuff

s t r u c t u r e .24 ∗ Returns : None25 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/26 void u a r t 0 _ r x _ i n t r _ h a n d l e r ( void ∗para ) ;27

28 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗29 ∗ FunctionName : uart_div_modify30 ∗ Descr ipt ion : Set baud r a t e of UART.31 ∗ Parameters : u int8 uart_no : UART number , UART0 or UART1.32 ∗ uint32 DivLatchValue : Clock d i v i s i o n parameter .33 ∗ Returns : None34 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/35 void u a r t 0 _ r x _ i n t r _ h a n d l e r ( uint8 uart_no , uint32 DivLatchValue ) ;

C.4. UDP APIs

1 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗2 ∗ FunctionName : espconn_delete3 ∗ Descr ipt ion : disconnect with host4 ∗ Parameters : espconn −− the espconn used to disconnect the

connect ion5 ∗ Returns : none //TODO//6 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/7 s i n t 8 espconn_delete ( s t r u c t espconn ∗espconn ) ;8

9 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗10 ∗ FunctionName : espconn_create11 ∗ Descr ipt ion : UDP − Binds the conect ion to l o c a l IP : Port and

s t a r t s l i s t e n i n g .12 ∗ I t a l s o r e g i s t e r s c a l l b a c k s i f defined .13 ∗ Parameters : espconn −− espconn to the data transmiss ion14 ∗ Returns : Resul t :15 ∗ ESPCONN_OK ( 0 ) −> Success16 ∗ ESPCONN_ARG (−12) −> I n v a l i d argument17 ∗ ESPCONN_ISCONN (−15) −> Already connected18 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/19 s i n t 8 espconn_create ( s t r u c t espconn ∗espconn ) ;20

21 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗22 ∗ FunctionName : espconn_get_connect ion_info23 ∗ Descr ipt ion : Get information about a TCP connect ion ( not

implemented ) or24 ∗ UDP transmiss ion . Usually used in the

espconn_recv_cal lback .25 ∗ Parameters : ∗ ∗espconn : corresponding connected c o n t r o l

block s t r u c t u r e ;26 ∗ ∗ remot_info ∗∗pcon_info : connect to c l i e n t i n f o

;27 ∗ ∗ uint8 t y p e f l a g s :28 ∗ − 0 , regular server29 ∗ − 1 , s s l server ( Not implemented )30 ∗ Returns : 0 Success31 ∗ −1 F a i l

C.4. UDP APIs 65

32 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/33 s i n t 8 espconn_get_connect ion_info ( s t r u c t espconn ∗pespconn ,

remot_info ∗∗pcon_info , uint8 t y p e f l a g s ) ;34

35 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗36 ∗ FunctionName : espconn_reg is t_sentcb37 ∗ Descr ipt ion : Used to s p e c i f y the funct ion t h a t should be

c a l l e d when data38 ∗ has been s u c c e s s f u l l y sent .39 ∗ Parameters : s t r u c t espconn ∗espconn −− espconn to s e t the

sent c a l l b a c k40 ∗ espconn_sent_ca l lback sent_cb −− sent c a l l b a c k

funct ion to41 ∗ c a l l f o r t h i s espconn when data i s s u c c e s s f u l l y

sent42 ∗ Returns : ESPCONN_OK on success43 ∗ ESPCONN_ARG i f f a i l s44 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/45 s i n t 8 espconn_reg is t_sentcb ( s t r u c t espconn ∗espconn ,

espconn_sent_ca l lback sent_cb ) ;46

47 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗48 ∗ FunctionName : espconn_send49 ∗ Descr ipt ion : sent data f o r c l i e n t or server50 ∗ Parameters : espconn −− espconn to s e t f o r c l i e n t or server51 ∗ psent −− data to send52 ∗ length −− length of data to send53 ∗ Returns : none //TODO//54 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/55 s i n t 8 espconn_send ( s t r u c t espconn ∗espconn , uint8 ∗psent , uint16

length ) ;56

57 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗58 ∗ FunctionName : espconn_sent ( Deprecated . Use espconn_send

ins tead )59 ∗ Descr ipt ion : sent data f o r c l i e n t or server60 ∗ Parameters : espconn −− espconn to s e t f o r c l i e n t or server61 ∗ psent −− data to send62 ∗ length −− length of data to send63 ∗ Returns : none //TODO//64 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/65 s i n t 8 espconn_sent ( s t r u c t espconn ∗espconn , uint8 ∗psent , uint16

length ) ;66

67 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗68 ∗ FunctionName : espconn_regis t_recvcb69 ∗ Descr ipt ion : used to s p e c i f y the funct ion t h a t should be

c a l l e d when recv70 ∗ data .71 ∗ Parameters : espconn −− espconn to s e t the recv c a l l b a c k72 ∗ recv_cb −− recv c a l l b a c k funct ion to c a l l when

recv data73 ∗ Returns : ESPCONN_OK on success74 ∗ ESPCONN_ARG i f f a i l s75 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/76 s i n t 8 espconn_regis t_recvcb ( s t r u c t espconn ∗espconn ,

espconn_recv_cal lback recv_cb ) ;


C.5. UDP APIs

1 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗2 ∗ FunctionName : wifi_powerOn_iface / wif i_powerOff_ i face3 ∗ Descr ipt ion : Powers on or o f f a s e l e c t e d i n t e r f a c e4 ∗ Parameters : S e l e c t e d i n t e r f a c e5 ∗ Returns : NONE6 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/7 void wifi_powerOn_iface ( uint8 ) ;8 void wif i_powerOff_ i face ( uint8 ) ;9

10 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗11 ∗ FunctionName : wifi_get_opmode12 ∗ Descr ipt ion : Get the current operat ing mode of Wi−Fi13 ∗ Parameters : NONE14 ∗ Returns : Wi−Fi working modes :15 ∗ ∗ 0x01 : S t a t i o n mode16 ∗ ∗ 0x02 : SoftAP mode17 ∗ ∗ 0x03 : S t a t i o n + SoftAP18 ∗ Note : wifi_get_opmode_default re turns the op mode saved

in Flash19 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/20 uint8 wifi_get_opmode ( void ) ;21 uint8 wifi_get_opmode_default ( void ) ;22

23 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗24 ∗ FunctionName : wifi_set_opmode_current25 ∗ Descr ipt ion : Set Wi−Fi working mode to S t a t i o n mode , SoftAP or

S t a t i o n +26 ∗ SoftAP , and do not update f l a s h .27 ∗ Parameters :28 ∗ ∗ u i n t 8 _ t opmode : WiFi working modes :29 ∗ ∗ 0x01 : S t a t i o n mode30 ∗ ∗ 0x02 : SoftAP mode31 ∗ ∗ 0x03 : S t a t i o n + SoftAP32 ∗ Returns : boolean33 ∗ ∗ t rue : Success34 ∗ ∗ f a l s e : F a i l u r e35 ∗36 ∗ Note : wifi_set_opmode a l s o saves op mode in Flash37 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/38 //bool wifi_set_opmode_current (OP_MODE opmode) ;39 bool wifi_set_opmode_current ( uint8 opmode) ;40 bool wifi_set_opmode ( uint8 opmode) ;41

42 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗43 ∗ FunctionName : w i f i _ s t a t i o n _ g e t _ c o n f i g44 ∗ Descr ipt ion : Get Wi−Fi S t a t i o n ’ s current c o n f i g u r a t i o n .45 ∗ Parameters : s t r u c t s t a t i o n _ c o n f i g ∗ conf ig : WiFi STA conf ig

pointer46 ∗ Returns : boolean47 ∗ ∗ t rue : Success48 ∗ ∗ f a l s e : F a i l u r e49 ∗ Note : w i f i _ s t a t i o n _ g e t _ c o n f i g _ d e f a u l t re turns the op mode saved

in Flash50 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/51 bool w i f i _ s t a t i o n _ g e t _ c o n f i g ( s t r u c t s t a t i o n _ c o n f i g ∗ conf ig ) ;52 bool w i f i _ s t a t i o n _ g e t _ c o n f i g _ d e f a u l t ( s t r u c t s t a t i o n _ c o n f i g ∗ conf ig )

;

C.5. UDP APIs 67

53

54 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗55 ∗ FunctionName : w i f i _ s t a t i o n _ s e t _ c o n f i g _ c u r r e n t56 ∗ Descr ipt ion : Set Wi−Fi S t a t i o n ’ s c o n f i g u r a t i o n and do not

update Flash57 ∗ Parameters : s t r u c t s t a t i o n _ c o n f i g ∗ conf ig : WiFi STA conf ig

pointer58 ∗ Returns : boolean59 ∗ ∗ t rue : Success60 ∗ ∗ f a l s e : F a i l u r e61 ∗ Note : w i f i _ s t a t i o n _ s e t _ c o n f i g a l s o saves conf ig in Flash62 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/63 bool w i f i _ s t a t i o n _ s e t _ c o n f i g _ c u r r e n t ( s t r u c t s t a t i o n _ c o n f i g ∗ conf ig )

;64 bool w i f i _ s t a t i o n _ s e t _ c o n f i g ( s t r u c t s t a t i o n _ c o n f i g ∗ conf ig ) ;65

66 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗67 ∗ FunctionName : w i f i _ s t a t i o n _ c o n n e c t68 ∗ Descr ipt ion : Connect Wi−Fi S t a t i o n to AP.69 ∗ Parameters : None70 ∗ Returns : boolean71 ∗ ∗ t rue : Success72 ∗ ∗ f a l s e : F a i l u r e73 ∗ Note : S t a t i o n must be disconnected f i r s t . S t a t i o n mode must be

enabled .74 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/75 bool w i f i _ s t a t i o n _ c o n n e c t ( void ) ;76

77 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗78 ∗ FunctionName : w i f i _ s t a t i o n _ d i s c o n n e c t79 ∗ Descr ipt ion : Disconnect Wi−Fi S t a t i o n from AP.80 ∗ Parameters : None81 ∗ Returns : boolean82 ∗ ∗ t rue : Success83 ∗ ∗ f a l s e : F a i l u r e84 ∗ Note : S t a t i o n mode must be enabled .85 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/86 bool w i f i _ s t a t i o n _ d i s c o n n e c t ( void ) ;87

88 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗89 ∗ FunctionName : w i f i _ s t a t i o n _ g e t _ c o n n e c t _ s t a t u s90 ∗ Descr ipt ion : Get w i f i connect ion s t a t u s of STA to AP.91 ∗ Parameters : None92 ∗ Returns : enum{93 ∗ STATION_IDLE = 0 ,94 ∗ STATION_CONNECTING,95 ∗ STATION_WRONG_PASSWORD,96 ∗ STATION_NO_AP_FOUND,97 ∗ STATION_CONNECT_FAIL,98 ∗ STATION_GOT_IP99 ∗ } ;

100 ∗101 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/102 uint8 w i f i _ s t a t i o n _ g e t _ c o n n e c t _ s t a t u s ( void ) ;103

104 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗105 ∗ FunctionName : w i f i _ s t a t i o n _ s c a n106 ∗ Descr ipt ion : Scan a l l a v a i l a b l e APs .107 ∗ Parameters : ∗ s t r u c t scan_conf ig ∗ conf ig : AP conf ig f o r scan .108 ∗ − I f conf ig==null , scan a l l APs .


109 ∗ − I f conf ig . s s i d ==n u l l && conf ig . bss id==n u l l &&conf ig . channel != null ,

110 ∗ S t a t i o n i n t e r f a c e w i l l scan the APs in as p e c i f i c channel .

111 ∗ − I f conf ig . s s i d != n u l l && conf ig . bss id==n u l l &&conf ig . channel==null ,

112 ∗ S t a t i o n w i l l scan the APs with a s p e c i f i c SSIDin a l l channels .

113 ∗ ∗ scan_done_cb_t cb : c a l l b a c k funct ion a f t e rscanning .

114 ∗ Returns : t rue : Success115 ∗ f a l s e : F a i l u r e116 ∗ NOTE: S t a t i o n mode must be enabled117 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/118 bool w i f i _ s t a t i o n _ s c a n ( s t r u c t scan_conf ig ∗ config , scan_done_cb_t

cb ) ;119 void v o i d _ w i f i _ s t a t i o n _ s c a n ( s t r u c t scan_conf ig ∗ config ,

scan_done_cb_t cb ) ;120 void w i f i_ s ta t i on _ sc an _e v a l _b ea c on ( const WifiMacHeader hdr , const

MgtBeaconHeader beacon , const SignalNoiseDbm signalNoise ) ;121

122 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗123 ∗ FunctionName : wif i_s tat ion_ap_number_set124 ∗ Descr ipt ion : S e t s the number of APs t h a t w i l l be cached f o r

Node S t a t i o n mode . Whenever Node S t a t i o n125 ∗ connects to an AP, i t caches a record of t h i s AP ’

s SSID and password . The cached ID126 ∗ index s t a r t s from 0 .127 ∗ Parameters : u int8 ap_number : the number of APs t h a t can be

recorded (MAX: 5)128 ∗ Returns : True : Success129 ∗ Fa lse : F a i l u r e130 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/131 bool wif i_stat ion_ap_number_set ( uint8 ap_number ) ;132

133 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗134 ∗ FunctionName : w i f i _ s t a t i o n _ g e t _ a p _ i n f o135 ∗ Descr ipt ion : Get information of APs recorded by ESP8266

S t a t i o n .136 ∗ Parameters : s t r u c t s t a t i o n _ c o n f i g conf ig [ ] : information of

APs ; array s i z e has to be 5 .137 ∗ Returns : The number of APs recorded .138 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/139 uint8 w i f i _ s t a t i o n _ g e t _ a p _ i n f o ( s t r u c t s t a t i o n _ c o n f i g conf ig [ 5 ] ) ;140

141 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗142 ∗ FunctionName : wif i_s ta t ion_ap_change143 ∗ Descr ipt ion : Switch Node S t a t i o n connect ion to AP as s p e c i f i e d

.144 ∗ Parameters : u int8 new_ap_id : AP ’ s record ID ; s t a r t counting

from 0 .145 ∗ Returns : boolean146 ∗ ∗ t rue : Success147 ∗ ∗ f a l s e : F a i l u r e148 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/149 bool wif i_s ta t ion_ap_change ( uint8 new_ap_id ) ;150

151 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗152 ∗ FunctionName : w i f i _ s t a t i o n _ g e t _ c u r r e n t _ a p _ i d

C.5. UDP APIs 69

153 ∗ Descr ipt ion : Get the current cached ID of AP. Node records theID of each

154 ∗ AP i t connects with . The ID number s t a r t s from 0 .155 ∗ Parameters : None156 ∗ Returns : The ID of the AP to which t h i s Node i s c u r r e n t l y

connected ,157 ∗ in the cached AP l i s t . Returns 5 ( out of range ) i f AP

was not found .158 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/159 uint8 w i f i _ s t a t i o n _ g e t _ c u r r e n t _ a p _ i d ( void ) ;160

161 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗162 ∗ FunctionName : wif i_record_AP_to_cache163 ∗ Descr ipt ion : Records the information of the AP to the cache164 ∗ Parameters : s t r u c t s t a t i o n _ c o n f i g conf ig : The information of the

AP to record165 ∗ Returns : The ID recorded with which was recorded or 5 i f i t

a l r ea y e x i s t e d166 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/167 uint8 wif i_record_AP_to_cache ( s t r u c t s t a t i o n _ c o n f i g conf ig ) ;168

169 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗170 ∗ FunctionName : wifi_set_phy_mode171 ∗ Descr ipt ion : Set phy mode ( 8 0 2 . 1 1 b/g/n ) . Currently only 802 .11

b supported172 ∗ Parameters : u int8 phys_mode173 ∗ ∗ PHY_MODE_11B = 1174 ∗ ∗ PHY_MODE_11G Not implemented175 ∗ ∗ PHY_MODE_11N Not implemented176 ∗ Returns : boolean177 ∗ ∗ t rue : Success178 ∗ ∗ f a l s e : F a i l u r e179 ∗180 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/181 bool wifi_set_phy_mode ( uint8 mode) ;182 uint8 wifi_get_phy_mode ( void ) ;183

184 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗185 ∗ FunctionName : w i f i _ s o f t a p _ g e t _ c o n f i g186 ∗ Descr ipt ion : Get the current c o n f i g u r a t i o n of Wi−Fi SoftAP .187 ∗ Parameters : s t r u c t s o f t a p _ c o n f i g ∗ conf ig : SoftAP

c o n f i g u r a t i o n information .188 ∗ Returns : boolean189 ∗ ∗ t rue : Success190 ∗ ∗ f a l s e : F a i l u r e191 ∗192 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/193 bool w i f i _ s o f t a p _ g e t _ c o n f i g ( s t r u c t s o f t a p _ c o n f i g ∗ conf ig ) ;194 bool w i f i _ s o f t a p _ g e t _ c o n f i g _ d e f a u l t ( s t r u c t s o f t a p _ c o n f i g ∗ conf ig ) ;195

196 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗197 ∗ FunctionName : w i f i _ s o f t a p _ s e t _ c o n f i g _ c u r r e n t198 ∗ Descr ipt ion : Set Wi−Fi SoftAP c o n f i g u r a t i o n199 ∗ Parameters : u int8 phys_mode200 ∗ ∗ PHY_MODE_11B = 1201 ∗ ∗ PHY_MODE_11G Not implemented202 ∗ ∗ PHY_MODE_11N Not implemented203 ∗ Returns : boolean204 ∗ ∗ t rue : Success205 ∗ ∗ f a l s e : F a i l u r e


206 ∗207 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/208 bool w i f i _ s o f t a p _ s e t _ c o n f i g _ c u r r e n t ( s t r u c t s o f t a p _ c o n f i g ∗ conf ig ) ;209 bool w i f i _ s o f t a p _ s e t _ c o n f i g ( s t r u c t s o f t a p _ c o n f i g ∗ conf ig ) ;210

211 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗212 ∗ FunctionName : w i f i _ s e t _ c h a n n e l213 ∗ Descr ipt ion : Set Wi−Fi Channel214 ∗ Parameters : u int8 channel / [ uint8 i n t e r f a c e {ADHOC | STA |

AP} ]215 ∗ Returns : boolean216 ∗ ∗ t rue : Success217 ∗ ∗ f a l s e : F a i l u r e218 ∗ NOTE: Valid channels f o r 802 .11 b : 1 ~ 11219 ∗ NOTE: All i n t e r f a c e s w i l l be s e t to the same channel f o r

w i f i _ s e t _ c h a n n e l220 ∗ NOTE: Using w i f i _ s e t _ c h a n n e l _ i f a c e al lows a per i n t e r f a c e

channel s e t .221 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/222 bool w i f i _ s e t _ c h a n n e l ( uint8 channel ) ;223 void w i f i _ s e t _ c h a n n e l _ i f a c e ( uint8 channel , u int8 i n t e r f a c e ) ;224

225 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗226 ∗ FunctionName : wi f i_get_channel227 ∗ Descr ipt ion : Get Wi−Fi Channel f o r a l l i n t e r f a c e s .228 ∗ Parameters : None / [ uint8 i n t e r f a c e {ADHOC | STA | AP} ]229 ∗ Returns : u int8 channel230 ∗231 ∗ NOTE: I f i n t e r f a c e s have d i f f e r e n t channel numbers ,

wi f i_get_channel w i l l232 ∗ re turn a value 0233 ∗ NOTE: Using w i f i _ g e t _ c h a n n e l _ i f a c e al lows a per i n t e r f a c e

channel get .234 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/235 uint8 wif i_get_channel ( ) ;236 uint8 w i f i _ g e t _ c h a n n e l _ i f a c e ( uint8 ) ;237

238 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗239 ∗ FunctionName : w i f i _ g e t _ i p _ i n f o240 ∗ Descr ipt ion : Get IP i n f o of the s p e c i f i e d i n t e r f a c e241 ∗ Parameters : − uint8 i f _ i n d e x : The i n t e r f a c e to get the IP from

.242 ∗ − i p _ i n f o _ t ∗ i n f o : Po inter to hold the IP i n f o .243 ∗ Returns : boolean244 ∗ ∗ t rue : Success245 ∗ ∗ f a l s e : F a i l u r e246 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/247 bool w i f i _ g e t _ i p _ i n f o ( uint8 , s t r u c t i p _ i n f o ∗ ) ;248

249 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗250 ∗ FunctionName : w i f i _ s e t _ i p _ i n f o251 ∗ Descr ipt ion : Set IP address of the s p e c i f i e d i n t e r f a c e252 ∗ Parameters : − uint8 i f _ i n d e x : The i n t e r f a c e to get the IP from

.253 ∗ − i p _ i n f o _ t ∗ i n f o : Po inter to hold the IP i n f o .254 ∗ Returns : boolean255 ∗ ∗ t rue : Success256 ∗ ∗ f a l s e : F a i l u r e257 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/258 bool w i f i _ s e t _ i p _ i n f o ( uint8 , s t r u c t i p _ i n f o ∗ ) ;

C.5. UDP APIs 71

259

260 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗261 ∗ FunctionName : w i f i _ s t a t i o n _ g e t _ r s s i262 ∗ Descr ipt ion : Get RSSI of the AP to which the node i s connected .263 ∗ Parameters : None264 ∗ Returns : 3 1 : F a i l u r e . I n v a l i d value265 ∗ other : Success , value of RSSI , in general , RSSI value

< 10266 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/267 s i n t 8 w i f i _ s t a t i o n _ g e t _ r s s i ( void ) ;268

269 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗270 ∗ FunctionName : system_phy_set_max_tpw271 ∗ Descr ipt ion : Set maximum value of RF Tx Power ; uni t : 0 . 2 5 dBm.272 ∗ Parameters : ∗ uint8 max_tpw : maximum value of RF Tx Power ,273 ∗ uni t : 0 . 2 5 dBm, range [ 0 , 8 2 ] .274 ∗ Returns : None275 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/276 void system_phy_set_max_tpw ( uint8 max_tpw ) ;277

278 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗279 ∗ FunctionName : wi f i_se t_event_handler_cb280 ∗ Descr ipt ion : R e g i s t e r WiFi event handler .281 ∗ Parameters : wi f i_event_handler_cb_t cb : c a l l b a c k282 ∗ Returns : None283 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/284 void wif i_se t_event_handler_cb ( wi f i_event_handler_cb_t cb ) ;285

286 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗287 ∗ FunctionName : wifi_get_macaddr288 ∗ Descr ipt ion : Get MAC address .289 ∗ Parameters : u int8 i f _ i n d e x : get S t a t i o n MAC or SoftAP MAC.290 ∗ # def ine STATION_IF 0x00291 ∗ # def ine SOFTAP_IF 0x01292 ∗ uint8 ∗macaddr : MAC address293 ∗ Returns : t rue Success294 ∗ f a l s e : F a i l u r e295 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/296 bool wifi_get_macaddr ( uint8 i f_ index , uint8 ∗macaddr ) ;297

298 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗299 ∗ FunctionName : wifi_set_macaddr300 ∗ Descr ipt ion : Set MAC address .301 ∗ Parameters : u int8 i f _ i n d e x : Set S t a t i o n MAC or SoftAP MAC.302 ∗ # def ine STATION_IF 0x00303 ∗ # def ine SOFTAP_IF 0x01304 ∗ uint8 ∗macaddr : MAC address305 ∗ Returns : t rue Success306 ∗ f a l s e : F a i l u r e307 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/308 bool wifi_set_macaddr ( uint8 i f_ index , uint8 ∗macaddr ) ;309

310 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗311 ∗ FunctionName : w i f i _ g e t _ b r o a d c a s t _ i f312 ∗ Descr ipt ion : Get i n t e r f a c e which Node sends UDP broadcast from .

This i s313 ∗ usual ly used when you have S t a t i o n + SoftAP mode to avoid

ambiguity .314 ∗ Parameters : None315 ∗ Returns : 1 : S t a t i o n


316 ∗ 2 : SoftAp317 ∗ 3 : Both S t a t i o n and SoftAp318 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/319 uint8 w i f i _ g e t _ b r o a d c a s t _ i f ( void ) ;320

321 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗322 ∗ FunctionName : w i f i _ g e t _ b r o a d c a s t _ i f323 ∗ Descr ipt ion : Set Node to send UDP broadcast from S t a t i o n

i n t e r f a c e or324 ∗ SoftAP i n t e r f a c e , or both S t a t i o n and SoftAP i n t e r f a c e s .325 ∗ Parameters : u int8 i n t e r f a c e : 1 S t a t i o n326 ∗ 2 SoftAP327 ∗ 3 Both328 ∗ Returns : t rue : Success329 ∗ f a l s e : F a i l u r e330 ∗ Note : Implemented only f o r c o m p a t i b i l i t y . The only accepted

value by NS3331 ∗ i s Both . WifiNetDevice NS3 model i s always broadcast

capable .332 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/333 bool w i f i _ s e t _ b r o a d c a s t _ i f ( u int8 i n t e r f a c e ) ;334

335 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗336 ∗ FunctionName : w i f i _ s o f t a p _ d h c p s _ s t a r t / wif i_sof tap_dhcps_stop337 ∗ Descr ipt ion : S t a r t /Stop the DHCP server f u n c t i o n s .338 ∗ Parameters : None339 ∗ Returns : t rue : Success340 ∗ f a l s e : F a i l u r e341 ∗ Note : Implemented only f o r c o m p a t i b i l i t y . PLACEHOLDER FUNCTIONS342 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/343 bool w i f i _ s o f t a p _ d h c p s _ s t a r t ( void ) ;344 bool wif i_sof tap_dhcps_stop ( void ) ;345

346 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗347 ∗ FunctionName : w i f i _ s t a t i o n _ d h c p c _ s t a r t / wi f i_s ta t ion_dhcpc_s top348 ∗ Descr ipt ion : S t a r t /Stop the DHCP c l i e n t f u n c t i o n s .349 ∗ Parameters : None350 ∗ Returns : t rue : Success351 ∗ f a l s e : F a i l u r e352 ∗ Note : Implemented only f o r c o m p a t i b i l i t y . PLACEHOLDER FUNCTIONS353 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/354 bool w i f i _ s t a t i o n _ d h c p c _ s t a r t ( void ) ;355 bool wi f i_s ta t ion_dhcpc_s top ( void ) ;356

357 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗358 ∗ FunctionName : w i f i _ s t a t i o n _ s e t _ a u t o _ c o n n e c t359 ∗ Descr ipt ion : Set the S t a t i o n to connect to the AP ( whose ID i s

cached )360 ∗ automat i ca l ly or not when powered on . Auto−

connect ion i s361 ∗ enabled by d e f a u l t .362 ∗ Parameters : u int8 s e t : Automatical ly connect ( 1 ) or not ( 0 ) :363 ∗ Returns : t rue : Success364 ∗ f a l s e : F a i l u r e365 ∗ Note : Implemented only f o r c o m p a t i b i l i t y . PLACEHOLDER FUNCTIONS366 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/367 bool w i f i _ s t a t i o n _ s e t _ a u t o _ c o n n e c t ( uint8 s e t ) ;368

369 /∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗370 ∗ FunctionName : w i f i _ s t a t i o n _ s e t _ r e c o n n e c t _ p o l i c y

C.5. UDP APIs 73

371 ∗ Descr ipt ion : Set whether the Node w i l l attempt to reconnect toan AP i f

372 ∗ disconnected or f a i l e d to connect .373 ∗ Parameters : bool s e t : true , enable reconnect ion ; f a l s e , d i s a b l e

reconnect ion .374 ∗ Returns : t rue : Success375 ∗ f a l s e : F a i l u r e376 ∗ Note : Implemented only f o r c o m p a t i b i l i t y . PLACEHOLDER FUNCTIONS377 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/378 bool w i f i _ s t a t i o n _ s e t _ r e c o n n e c t _ p o l i c y ( bool s e t ) ;

75

Apéndice D

Manual de usuario

D.1. Antes de empezar

Asegúrese de tener correctamente instalado y funcionando el simula-dor ns-3 en su version 3.28. Puede descargarla desde https://www.nsnam.org/releases/ns-3-28/ y seguir los pasos en la documentaciónde la pagina para su instalación.

Descargue el entorno de simulación desde el siguiente link: https://gitlab.com/leo_giaccone/wsn_framework.git.

D.2. Preparar el entorno

Dentro del directorio donde instaló el ns-3 debería existir un directorio lla-mado ns-allinone-3.28.1 y dentro de este uno de nombre ns-3.28.1.Durante el resto del documento, nos referiremos a este último directorio co-mo <RAIZ-NS3>.Por otro lado diremos que <WSN-FRWK> es el directorio wsn_frameworkque existe donde usted descargo el entorno de simulación.

Una vez instalado el ns-3 y descargado el entorno de simulación, siga lossiguientes pasos:

1. Diríjase a <WSN-FRWK>. Edite el archivo WSN_framework.conf comose muestra a continuación (reemplazando el texto <RAIZ-NS3> por laruta que corresponda a su instalación):NS3_DIR=<RAIZ-NS3>

2. Guarde el archivo y ejecute:$ ./add_to_ns3.sh

Ahora el entorno esta listo para ser utilizado. El siguiente paso es configurarla simulación como se indica en D.3.

https://www.nsnam.org/releases/ns-3-28/

https://www.nsnam.org/releases/ns-3-28/

https://gitlab.com/leo_giaccone/wsn_framework.git

https://gitlab.com/leo_giaccone/wsn_framework.git

76 Apéndice D. Manual de usuario

D.3. Configurar la simulación

La simulación se configura desde <WSN-FRWK>/src/myWSN/model/USER.En ese directorio deberían encontrarse los archivos y directorios que se venen la figura D.1.

FIGURA D.1: Archivos de configuración de la simulación.

A continuación se describe el contenido de los archivos y directorios de con-figuración:

Directorio ALGORITHMSEn este directorio se encuentran los algoritmos disponibles para simular. Ca-da algoritmo es un directorio en sí mismo que puede contener archivos fuentey headers. El usuario debe crear un nuevo directorio y copiar en este todos losarchivos fuente y headers del algoritmo a simular.

Archivo WSN_user.confEste archivo contiene la siguiente información:

NUM_NODES: es la cantidad de nodos que se van a simular.

NODE_CFG_FILE: el archivo que se debe utilizar para configurar losnodos de la simulación.

NODE_POS_FILE: el archivo que se debe utilizar para configurar la po-sición de los nodos en la simulación.

Archivo configuración de nodosEs el archivo que se indicó como <NODE_CFG_FILE>. Este archivo posee unalinea por cada nodo donde cada linea está formada por campos separadospor el carácter “∼”. La información que provee cada campo es la siguiente:


2. Es la plataforma de hardware seleccionada. Debe existir con el mismonombre dentro de <WSN-FRWK>/src/myWSN/model/NODE.

3. Es la capa de abstracción hasta la cual se simulará. Siempre debe llamar-se LAYX, donde X es el nivel de la capa hasta donde se quiere simular.

D.4. Iniciar la simulación 77

4. El algoritmo que se cargara en el nodo. Debe existir con el mismo nom-bre dentro de <WSN-FRWK>/src/myWSN/model/USER/ALGORITHMS.

5. La función de main que se ejecutará cuando el nodo haya terminado elproceso de inicialización.

6. La función de setup que se ejecutará apenas inicie el nodo.

Archivo configuración de la posición de los nodosEs el archivo que se indicó como <NODE_POS_FILE>. Este archivo posee unalinea por cada nodo donde cada linea está formada por campos cuatro cam-pos separados por el carácter “∼”. La información que provee cada campo esla siguiente:


2. Posición inicial del nodo en X.

3. Posición inicial del nodo en Y.

4. Posición inicial del nodo en Z.

D.4. Iniciar la simulación

Una vez configurada la simulación, se procede a ejecutarla. Con ese fin ejecu-te la siguiente instrucción:$ ./sim_run.sh

Inmediatamente debería observar algo como la figura D.2. Se puede ver queel entorno comienza a compilar archivos, luego enlazarlos y finalmente co-mienza a correr la simulación.

FIGURA D.2: Inicio de la simulación.


D.5. Archivos de salida

Cuando finalice, toda la información acerca de la simulación estará disponi-ble dentro del directorio <WSN-FRWK>/src/myWSN/model/USER/outputcomo se ve en la figura D.3.

FIGURA D.3: Salida de la simulación.

Salida - EnergyDentro de del directorio output/energy se encuentra un archivo por cadanodo cuyo contenido reporta la cantidad de energía consumida en cada nodoy como se repartió dicho consumo entre transmisiones, recepciones y estadode reposo. En la figura D.4 se observa un ejemplo de estos reportes.

FIGURA D.4: Reportes de energía consumida.

Salida - GPIODentro del directorio output/GPIO se encuentran los archivos en formatoVCD para cada nodo, y para la red en conjunto. Estos archivos contienen elestado de todos los pines GPIO de cada nodo durante toda la simulación.Pueden visualizarse con cualquier herramienta que interprete este tipo de ar-chivos como por ejemplo GTKWave (figura D.5).

Salida - netAnim

D.5. Archivos de salida 79

FIGURA D.5: Visualización del estado de los pines GPIO uti-lizando GTKWave.

NetAnim [46] es una herramienta que brinda una interfaz gráfica para ana-lizar una simulación. Dentro del directorio output/netAnim se encuentrael archivo XML necesario para visualizar la simulación con NetAnim. Paraabrir la herramienta, hay que ejecutar el archivo NetAnim que esta dentro dens-allinone-3.28.1/netanim-3.108. Una vez cargado el XML se ob-tendrá una visualización gráfica de la simulación como se ve en la figura D.6.

FIGURA D.6: Visualización de la simulación utilizando NetA-nim.

Salida - PCAPEl entorno de simulación también proporciona un reporte detallado sobrela actividad de la red. En el directorio output/pcap se genera un archivopor cada interfaz de red presente en la simulación. Estos archivos de formato.pcap contienen información del trafico de la red durante toda la simulación.Puede ser leído con herramientas de análisis de redes como WireShark o TCP-Dump. La figura D.7 muestra una captura de pantalla del software Wiresharkvisualizando uno de los archivos de salida del entorno de simulación.

Salida - UARTEn el directorio output/UART se encuentra un archivo de texto por cadanodo. Este archivo es un log de todo lo que se “escribió” en la UART durante


FIGURA D.7: Archivo de salida .pcap abierto con Wireshark.

la simulación. Es lo mismo que se observaría si se tiene el nodo real conectadoa una PC. La figura D.8 muestra una ejemplo de estos archivos.

FIGURA D.8: Archivo de salida de reporte de una UART.

81

Bibliografía

[1] Mukhdeep Singh Manshahia. «Wireless sensor networks: a survey».En: International Journal of Scientific & Engineering Research 7.4 (2016),págs. 710-716.

[2] Liu Yong-Min, Wu Shu-Ci y Nian Xiao-Hong. «The architecture andcharacteristics of wireless sensor network». En: 2009 InternationalConference on Computer Technology and Development. Vol. 1. IEEE. 2009,págs. 561-565.

[3] Kazem Sohraby, Daniel Minoli y Taieb Znati. Wireless sensor networks:technology, protocols, and applications. John Wiley & Sons, 2007.

[4] Wikipedia. Wireless sensor network - Wikipedia.https://en.wikipedia.org/wiki/Wireless_sensor_network.

[5] Ashraf Darwish y Aboul Ella Hassanien. «Wearable and implantablewireless sensor network solutions for healthcare monitoring». En:Sensors 11.6 (2011), págs. 5561-5595.

[6] Wikipedia. Embedded system - Wikipedia.https://en.wikipedia.org/wiki/Embedded_system.

[7] Fatma Karray y col. «A review on wireless sensor node architectures».En: 2014 9th International Symposium on Reconfigurable andCommunication-Centric Systems-on-Chip (ReCoSoC). IEEE. 2014,págs. 1-8.

[8] Azrina Abd Aziz y col. «A survey on distributed topology controltechniques for extending the lifetime of battery powered wirelesssensor networks». En: IEEE communications surveys & tutorials 15.1(2012), págs. 121-144.

[9] Anand Nayyar y Rajeshwar Singh. «A comprehensive review ofsimulation tools for wireless sensor networks (WSNs)». En: Journal ofWireless Networking and Communications 5.1 (2015), págs. 19-47.

[10] Ivan Minakov y col. «A comparative study of recent wireless sensornetwork simulators». En: ACM Transactions on Sensor Networks (TOSN)12.3 (2016), pág. 20.

[11] Esteban Egea-Lopez y col. «Simulation tools for wireless sensornetworks». En: proceedings of the international symposium on performanceevaluation of computer and telecommunication systems (SPECTS05). 2005,pág. 24.

[12] Miloš Jevtic, Nikola Zogovic y Goran Dimic. «Evaluation of wirelesssensor network simulators». En: Proceedings of the 17thtelecommunications forum (TELFOR 2009), Belgrade, Serbia. Citeseer.2009, págs. 1303-1306.

[13] Harsh Sundani y col. «Wireless sensor network simulators a surveyand comparisons». En: International Journal of Computer Networks 2.5(2011), págs. 249-265.

https://en.wikipedia.org/wiki/Wireless_sensor_network

https://en.wikipedia.org/wiki/Embedded_system

82 Bibliografía

[14] Bartosz Musznicki y Piotr Zwierzykowski. «Survey of simulators forwireless sensor networks». En: International Journal of Grid andDistributed Computing 5.3 (2012), págs. 23-50.

[15] Cristina Lopez-Pavon, Sandra Sendra y Juan F Valenzuela-Valdés.«Evaluation of CupCarbon Network Simulator for Wireless SensorNetworks.» En: Network Protocols & Algorithms 10.2 (2018), págs. 1-27.

[16] Omnet. Omnet++ Network simulator. https://omnetpp.org/.[17] NS3. ns3 | a discrete-event network simulator for internet systems.

https://www.nsnam.org/.[18] Github. An Introduction to Cooja. https://github.com/contiki-

os/contiki/wiki/An-Introduction-to-Cooja.[19] Contiki-NG. Contiki-NG: The OS for Next Generation IoT Devices.

https://www.contiki-ng.org/.[20] Github. Contiki fork of the MSPSim.

https://github.com/contiki-ng/mspsim.[21] TinyOS. TOSSIM - TinyOS Wiki.

http://tinyos.stanford.edu/tinyos-wiki/index.php/TOSSIM.[22] TinyOS. TinyOS Home Page. http://www.tinyos.net/.[23] Castalia. An OMNeT-based simulator for low-power wireless networks such

as Wireless Sensor Networks and Body Area Networks.https://github.com/boulis/Castalia.

[24] Harald T Friis. «A note on a simple transmission formula». En:Proceedings of the IRE 34.5 (1946), págs. 254-256.

[25] Tapan K Sarkar y col. «A survey of various propagation models formobile communication». En: IEEE Antennas and propagation Magazine45.3 (2003), págs. 51-82.

[26] Robert Akl, Dinesh Tummala y Xinrong Li. «Indoor PropagationModeling at 2.4 GHz for IEEE 802.11 Networks.» En: Wireless andOptical Communications. 2006.

[27] Wikipedia. Path Loss - Wikipedia.https://en.wikipedia.org/wiki/Path_loss.

[28] Atreyi Bose y Chuan Heng Foh. «A practical path loss model forindoor WiFi positioning enhancement». En: 2007 6th InternationalConference on Information, Communications & Signal Processing. IEEE.2007, págs. 1-5.

[29] Masaharu Hata. «Empirical formula for propagation loss in landmobile radio services». En: IEEE transactions on Vehicular Technology29.3 (1980), págs. 317-325.

[30] ns-3 NETWORK SIMULATOR. Releasae ns-3.28. ns-3 project. 2018.[31] Geeks for Geeks. Layers of OSI model.

https://www.geeksforgeeks.org/layers-of-osi-model.[32] IEEE Computer Society LAN/MAN Standards Committee y col.

«IEEE Standard for Information technology-Telecommunications andinformation exchange between systems-Local and metropolitan areanetworks-Specific requirements Part 11: Wireless LAN MediumAccess Control (MAC) and Physical Layer (PHY) Specifications». En:IEEE Std 802.11ˆ (2007).

[33] NodeMCU Team. NodeMCU – An open-source firmware based onESP8266 wifi-soc. https://www.nodemcu.com/index_en.html.

https://omnetpp.org/

https://www.nsnam.org/

https://github.com/contiki-os/contiki/wiki/An-Introduction-to-Cooja

https://github.com/contiki-os/contiki/wiki/An-Introduction-to-Cooja

https://www.contiki-ng.org/

https://github.com/contiki-ng/mspsim

http://tinyos.stanford.edu/tinyos-wiki/index.php/TOSSIM

http://www.tinyos.net/

https://github.com/boulis/Castalia

https://en.wikipedia.org/wiki/Path_loss

https://www.geeksforgeeks.org/layers-of-osi-model

https://www.nodemcu.com/index_en.html

Bibliografía 83

[34] Espressif. ESP8266 Datasheet.https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf.

[35] FreeRTOS. FreeRTOS - Real time operating system for microcontrollers.https://www.freertos.org/.

[36] Github. ESP8266 nonOS SDK.https://github.com/espressif/ESP8266_NONOS_SDK.

[37] Espressif. ESP8266 NonOS SDK API reference.https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf.

[38] Mathieu Lacage y Thomas R Henderson. «Yet another networksimulator». En: Proceeding from the 2006 workshop on ns-2: the IP networksimulator. ACM. 2006, pág. 12.

[39] nsnam. ns3 Doxygen Documentation.https://www.nsnam.org/docs/release/3.28/doxygen/.

[40] Ad Kamerman y Leo Monteban. «WaveLAN R©-II: a high-performancewireless LAN for the unlicensed band». En: Bell Labs technical journal2.3 (1997), págs. 118-133.

[41] Gavin Holland, Nitin Vaidya y Paramvir Bahl. «A rate-adaptive MACprotocol for multi-hop wireless networks». En: Proceedings of the 7thannual international conference on Mobile computing and networking.ACM. 2001, págs. 236-251.

[42] ESP8266 Non-OS SDK - API reference. Version. 3.0.1. Espressif Systems.2019.

[43] Arduino project. Arduino language reference.https://www.arduino.cc/reference/en/.

[44] Gisselquist Technology LLC. Writing your own VCD file.https://zipcpu.com/blog/2017/07/31/vcd.html.

[45] Wikipedia. Value change dump - Wikipedia.https://en.wikipedia.org/wiki/Value_change_dump.

[46] Nsnam. NetAnim 3.108 - Nsnam.https://www.nsnam.org/wiki/NetAnim_3.108.

[47] Saurabh Ganeriwal, Ram Kumar y Mani B Srivastava. «Timing-syncprotocol for sensor networks». En: Proceedings of the 1st internationalconference on Embedded networked sensor systems. ACM. 2003,págs. 138-149.

[48] Sami M Lasassmeh y James M Conrad. «Time synchronization inwireless sensor networks: A survey». En: Proceedings of the IEEESoutheastCon 2010 (SoutheastCon). IEEE. 2010, págs. 242-245.

[49] Michael Roche. Time Synchronization in Wireless Networks. https://www.cse.wustl.edu/~jain/cse574-06/ftp/time_sync/index.html.

https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf

https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf

https://www.freertos.org/

https://github.com/espressif/ESP8266_NONOS_SDK

https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf

https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf

https://www.nsnam.org/docs/release/3.28/doxygen/

https://www.arduino.cc/reference/en/

https://zipcpu.com/blog/2017/07/31/vcd.html

https://en.wikipedia.org/wiki/Value_change_dump

https://www.nsnam.org/wiki/NetAnim_3.108

https://www.cse.wustl.edu/~jain/cse574-06/ftp/time_sync/index.html

https://www.cse.wustl.edu/~jain/cse574-06/ftp/time_sync/index.html

Documents

Diseño de modelos de hardware y firmware para implementar un entorno de …laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Tesis-Grado... · 2020. 1. 23. · Este capitulo hace una introducción