El ambiente de pruebas propuesto para la simulación del desempeño del protocolo se presenta en la Figura 29.
Figura 29. Ambiente de simulación Propuesto. Un post-procesamiento en perl nos brinda información acerca del porcentaje de pérdida de paquetes, latencia, evolución del tiempo de llenado para las compuertas, etc.
La selección de TOS se presentó en la sección anterior. Como ya se dijo, la programación de aplicaciones directamente sobre el sistema operativo se realiza con nesC. La compilación del código en nesC puede realizarse sobre un nodo que soporte TOS (Telosb, mica2 o micaZ, cricket, por mencionar algunos) o sobre un simulador de eventos discretos TOSSIM (TinyOS SIMulator), que se describirá a profundidad más adelante.
Modelo de Propagación
Se planteó un modelo de pérdidas basado en el desvanecimiento log-normal, modelo muy usado para redes inalámbricas de sensores. Su implementación se realizó en Matlab.
Este modelo de pérdidas [30]-[31] establece que las pérdidas medias debidas al trayecto se pueden expresar como:
(23)
Donde d es la distancia al nodo, n es el exponente de pérdidas e indica qué tan rápido crecen las pérdidas en función de la distancia, d0 es una distancia de referencia (a esta
distancia del transmisor, se pueden lograr línea de vista y utilizar la fórmula de espacio libre para calcular las pérdidas a ese punto):
(24)
Gracias a un proceso empírico y a ajustes estadísticos [30]- [31], las pérdidas en función de la distancia de un nodo, se puede expresar como:
(25)
Donde Xσ, es variable aleatoria con distribución log-normal (de ahí el nombre del
desvanecimiento), con valor medio de cero y con desviación estándar σ en decibeles. Esta variable aleatoria indica una deformación en el radio de cubrimiento de un nodo. Ya que la aproximación clásica del alcance de un transmisor es un modelo circular en dónde la energía recibida en un punto depende básicamente de la separación al emisor. Sin embargo, la presencia de obstáculos a lo largo del área de cobertura induce a que no se tenga un cubrimiento circular perfecto, sino un área amorfa y que se trata de modelar con la inclusión de la variable aleatoria [30].
Este modelo se desarrolló en Matlab y se extrajo un archivo de relaciones de potencia recibida para cada nodo (desde los otros) para diversas topologías. Estas topologías, así como un archivo de interferencias fueron cargadas en TOSSIM mediante un código en Python para realizar las simulaciones del código implementado en nesC.
Para conocer las pérdidas de potencia media, el exponente de perdidas y la varianza del desvanecimiento para diversos escenarios reales se recomienda las referencias [32]-[33]. Las simulaciones ejecutadas contemplaron un ambiente outdoor con valores [33]:
, n=4.7 y σ=3.2[dB].
Para detalle en cuanto a la simulación de asimetrías en los enlaces en WSN se recomienda la referencia [33] donde utilizan la matriz de covarianzas de las potencias de salida y piso de ruido por nodo. Nuestra simulación se desarrollo considerando enlaces simétricos.
TOSSIM
Con el modelo de propagación y la aplicación en nesC implementados, se procedió al ensamble de ambos archivos en un simulador. TOSSIM es un simulador de eventos discretos para redes soportando TinyOS. En lugar de compilar una aplicación TinyOS sobre un sensor (como se ve en la parte punteada de la Figura 29), un usuario puede compilarlo en TOSSIM. Esto permite hacer un seguimiento del código, analizar su comportamiento, y verificar su correcto funcionamiento en un ambiente estable, controlable y repetible de pruebas.
Cuando TOSSIM arranca, ningún nodo puede comunicarse con otro hasta que se especifique una topología de la red. El modelo de radio predeterminado de TOSSIM está basado en la intensidad de potencia recibida por un nodo. Se aprovecha entonces el modelo de desvanecimiento lognormal desarrollado en Matlab y expuesto anteriormente para cumplir tal requisito.
Además del modelo de radio propagación, TOSSIM simula también ruido y la interferencia de RF que un nodo recibe desde otros nodos o incluso desde fuentes externas (dado que la frecuencias de operación de los nodos que soportan TOS se ubican en las banda de 2.4GHz es claro que se presenta interferencia con redes inalámbricas convencionales 802.11). En la Figura 30 se puede presenciar la coexistencia de aplicaciones para redes WSN con las típicas redes WiFi.
Figura 30. Bandas usadas para los estándares 802.15.4 y 802.11 (tomada de [34]). Se observa la posibilidad de interferencia de los canales wifi sobre las bandas de 802.15.4, interferencia que se tiene en cuenta en TOSSIM.
Los autores de [34] recogieron trazas de ruido de una variedad de ambientes: interiores (con y sin conectividad 802.11 y a diversas horas del día), áreas exteriores (con y sin conectividad WiFi) y llegaron a la conclusión que una ruta efectiva hacia la simulación precisa de redes inalámbricas de sensores es tomar mediciones de diversos ambientes bajo distintas condiciones y generar modelos estadísticos a partir de dichas mediciones.
Para ello utilizaron el algoritmo Closest Pattern Matching (CPM) [34]. CPM toma una traza de ruido como entrada y genera un modelo estadístico a partir de él. CPM calcula la distribución de la probabilidad condicional del valor del ruido dadas k lecturas de ruido anteriores.
Para medir el ruido, los autores escribieron una aplicación en TinyOS que tomaba muestras de la energía RF leyendo el registro de RSSI (del campo metadata del message_t) a una frecuencia de 1kHz con un nodo con radio CC2420 (utilizaron el nodo micaZ). La aplicación enviaba estas mediciones a la memoria Flash del dispositivo y una aplicación con un PC extraía la información del nodo.
De las mediciones observaron que muchos de los picos de ruido colectados presentaban un comportamiento periódico (debido a que las estaciones base de las redes 802.11 transmiten beacons cada 0.1024 segundos). Además descubrieron que había correlación temporal entre las muestras [34]: periodos de actividad y periodos de receso. Al desarrollar el modelo mediante la utilización de CPM, se dieron cuenta que permitía capturar ráfagas de
interferencia (bursts) y otros fenómenos correlacionados, de manera que la calidad de la simulación RF mejora bastante. De ahí su adopción para las simulaciones en TOSSIM. Para más detalle acerca del procedimiento y beneficios de CPM se recomienda estudiar a la referencia [34].
TOSSIM es una librería de TinyOS, por eso es necesario escribir un programa que configure una simulación y la ejecute. TOSSIM soporta dos interfaces de programación: C++ y Python. Se seleccionó la última por ser la recomendada en la referencia [35].
Post-Procesamiento de la Información
Ya que TOSSIM es un simulador de eventos, para analizar el comportamiento de ALT se colocaron a lo largo del código en TOS mensajes de compilación que imprimían información relacionada con algún evento. De tal manera que en la salida del simulador aparecieran mensajes como:
DEBUG (4): 0:5:5.113281660 APPS: MilliTimer.fired(), Counter Value=1 DEBUG (4): 0:5:5.113281660 ALT: AMSend.send() dest: 1 id: 1 nexthop: 3
DEBUG (4): 0:5:5.113281660 ALT: Envio Mensaje Aplicacion a la compuerta 2 con valor 1 .
. .
DEBUG (1): 0:8:5.146362521 ALT: El valor del contador del Nodo 4 es 1
En donde el número que sale en paréntesis es el nodo donde ocurre el evento. La estampa de tiempo que le sigue hace referencia al tiempo desde que arrancó la simulación en el que ocurre el evento. Después del tabulador viene un clasificador del tipo de evento (por ejemplo si es un evento de la capa de aplicación se identifica como APPS, si es un evento relacionado propio del protocolo lo personalizo como ALT), y después de los dos puntos aparece el nombre del evento.
Para la primera línea del fragmento anterior (que fue extraído de una de nuestras simulaciones), deducimos que el nodo 4 acaba de generar un mensaje en el cual el valor de un contador es 1. La segunda línea muestra que la del sumidero es la dirección 1 y que el siguiente salto es el nodo 3 (que es el padre del nodo 4). La tercera línea indica que la
compuerta que está haciendo la recolección de datos de la agrupación a la que pertenece el nodo 4 es el nodo identificado con la dirección 2. Después de cierto tiempo, el paquete alcanza el sumidero como puede observarse en la última línea.
Para el post-procesamiento de esta salida se implementó un código en Perl y mediante el uso de expresiones regulares se pudo extraer información de los retardos (hallando la diferencia de tiempo entre eventos) y de los paquetes perdidos de cada nodo buscando las relaciones Nodo-Valor (conocidas como Key-Value Pair) en el origen y destino.
Para la simulación del consumo de energía se utilizó una extensión de código conocida como PowerTossimZ (escrita en Python) que basado en unos mensajes de debug extrae el consumo de energía para la plataforma micaZ para aplicaciones escritas en TinyOS 2.x (T2). Para detalle del uso de PowerTossimZ se invita a la referencia [36].