Plataforma software de un nodo sensor basado en el System on Chip CC2530. Corti R., Belmonte J., Giandoménico E., Martínez R. Departamento de Sistemas e Informática – Facultad de Ciencias Exactas, Ingeniería y Agrimensura Universidad Nacional de Rosario Rosario, Argentina e-mail: { rcorti, belmonte, giandome, romamar }@fceia.unr.edu.ar Resumen—Las particularidades de las redes de sensores motivan el desarrollo de plataformas de implementación específicamente diseñadas para ellas. En este trabajo, se expone la implementación de Cluditem, capa de red del protocolo de comunicaciones, integrado con los niveles inferiores del estándar 802.15.4, en un nodo basado en CC2530. Asimismo, se reportan los ensayos de laboratorio realizados con la red de 20 nodos y se comprueba que los resultados obtenidos cumplen con las métricas de evaluación definidas. Palabras clave—redes de sensores; plataforma software; System on Chip I. encaminamiento; INTRODUCCIÓN Las redes inalámbricas de sensores inteligentes (RISI) son una herramienta muy promisoria para tareas de supervisión de ambientes, tanto exteriores como interiores. Permiten abarcar áreas extensas, simplifican la instalación de los dispositivos al eliminar el cableado, y pueden alimentarse con baterías funcionando en forma autónoma en locaciones alejadas o de difícil acceso [1] [2]. Los nodos que constituyen una RISI son capaces de procesar los datos colectados y colaborar con sus vecinos para transmitirlos hacia la/las estación/es base (sink). Estas redes se auto-organizan para adaptarse a distintas configuraciones, y deben trabajar bajo fuertes restricciones de energía, tratando de maximizar su tiempo de vida útil [1]. Las particularidades de las RISI motivan el desarrollo de técnicas y herramientas que si bien pueden aplicarse a otras redes ad-hoc, suelen estar específicamente diseñadas para ellas [3]. En este sentido, el diseño e implementación de una red de sensores, implica el desarrollo, adaptación y/o utilización de componentes de Software, y también de la plataforma Hardware asociada. En particular, los algoritmos de encaminamiento para RISI, han recibido mucha atención en los últimos años como se reporta en [4] [5]. Cluditem es un algoritmo de encaminamiento jerárquico para redes de sensores desarrollado para aplicaciones de supervisión ambiental [6]. En [7] se reporta el desarrollo de una plataforma HW basada en los módulos CC2530 para una red de 12 dispositivos que soportan el algoritmo mencionado. En este trabajo, se expone la implementación de Cluditem, capa de red del protocolo, integrado con los niveles inferiores del estándar 802.15.4. Asimismo, se reportan los ensayos de laboratorio realizados con la red de 20 nodos y se analizan los resultados. II. GENERALIDADES DEL ALGORITMO Cluditem es un algoritmo de encaminamiento jerárquico basado en clusters que realiza adquisición de datos en forma periódica, enviando información útil a la estación base en cada período de medición (T). Los nodos de la red son idénticos, respecto a recursos y energía inicial, se distribuyen manualmente una única vez, son fijos y están identificados por un ID. La estación base es única y se encuentra fuera del área a supervisar que se divide en una cuadrícula virtual con el objetivo de lograr una distribución uniforme de las cabeceras de clusters. Cluditem incorpora para la capa MAC el estándar IEEE 802.15.4 en modo beaconless, recomendado para redes multisalto como se reporta en [6]. La estructura de encaminamiento de la red es responsabilidad de Cluditem, y en este sentido se consideró la importancia que tienen las interferencias intra e intercluster, en lo que a pérdida de información se refiere, para los algoritmos jerárquicos basados en clusters [5]. Por estos motivos, Cluditem incluye esquemas TDMA para prevenir la pérdida de mensajes [6]. Una red de sensores que trabaja con el algoritmo referido queda constituida por nodos que cumplen roles distintos, nodos cabeceras de cluster (CH) y nodos comunes (NC), que se comunican por radiofrecuencia. Los nodos que asumen la tarea de CH, están más exigidos en cuanto al consumo de energía, por lo que se agregó al algoritmo de encaminamiento básico, una técnica de rotación periódica del rol de CH para balancear la carga de trabajo en la red y prolongar la vida útil del sistema. Por lo tanto, una red Cluditem reconfigura su estructura de encaminamiento cada X rondas de medición, que constituyen lo que denominamos una tanda de funcionamiento del sistema. El valor más conveniente para X se obtiene analíticamente como se detalla en [6]. El funcionamiento de Cluditem se divide en tres fases bien diferenciadas. La primera se ocupa del establecimiento del árbol de encaminamiento, la segunda se encarga del envío de datos al sink y durante la tercera los dispositivos permanecen en estado de bajo consumo (sleep). Es importante destacar que al ser Cluditem un algoritmo jerárquico distribuido, el apagado de los transceptores lo define cada nodo utilizando su propio reloj. Por lo tanto, se requiere sincronizar los relojes de los miembros de la red, con el fin de que el intercambio de mensajes sea efectivo. En [8] se describe el mecanismo de sincronización de relojes adoptado para Cluditem. Se trata de una técnica liviana, que introduce una sobrecarga acotada de consumo en los dispositivos y que resulta efectiva debido a que las aplicaciones seleccionadas admiten un desfasaje de relojes del orden de los milisegundos. En este sentido, la sincronización de los dispositivos se logra al inicio de cada ronda de medición, con el envío de dos mensajes específicos por parte del nodo sink. A. Fase de establecimiento del árbol de encaminamiento Esta fase se realiza cada X rondas de medición, luego del período establecido para la sincronización de relojes en los nodos. El encaminamiento se define en dos niveles. El primer nivel establece la estructura de cada cluster, definiendo los dispositivos que actuarán como coordinadores. Los nodos que aspiran a desempeñar el rol de cabecera se postulan respetando un esquema de tipo TDMA mediante un mensaje de estructura de cluster (EC), cuyo formato se muestra en la Fig. 1. Los nodos comunes adhieren a una cabecera, en base a los criterios definidos en el algoritmo, y eligen su nodo de enlace en el cluster (NDE). Dentro del cluster la comunicación es multisalto, y los nodos comunes poseen un nivel, definido por la cantidad de saltos que los separan de su CH. Para definir la estructura del cluster cada NC, que adhiere a un CH, reenvía el mensaje EC con la información necesaria para que otros nodos puedan adoptarlo como NDE. El segundo nivel del encaminamiento se ocupa de la definición del árbol de CH, que se encarga de enviar los datos agregados hasta la estación base. La fase se inicia con un mensaje de armado del árbol de cabeceras (ACH) que envía el sink, cuya estructura se presenta en la Fig. 2. Los nodos CH que lo escuchan asumen el nivel 1 en el árbol y reenvían el mensaje, colocando su ID y su nivel, de forma que otras cabeceras los adopten como enlace para envío de los mensajes agregados [6]. B. Fase de envío de datos El envío de datos hacia la estación base se realiza en dos etapas: en la primera los nodos comunes envían sus datos hacia su cabecera de cluster, y en la segunda los CH utilizan el árbol de cabeceras para hacer llegar hasta el sink el mensaje agregado, que resume la información recolectada por el cluster que coordinan. Esta fase se desarrolla a continuación de la definición del árbol de encaminamiento, si se trata de una ronda de reconfiguración, o al inicio del período T de recolección de información en una ronda de transmisión exclusiva de mediciones. En este último caso está precedida por el mecanismo de sincronización de relojes. En cada período de recolección de datos T, los nodos comunes envían las mediciones realizadas a su CH utilizando un mensaje de datos como se muestra en Fig. 3. El envío de los valores medidos por cada NC se realiza en base a un esquema de tipo TDMA. Se adopta este criterio para reducir las eventuales colisiones que podrían producirse si varios nodos Tipo de Mensaje CH elegido Fig. 1. Formato del mensaje EC Emisor Nivel del Emisor Tipo de Mensaje Fig. 2 Formato del mensaje de ACH Tipo de Mensaje Fig. 3 Nivel del Emisor Emisor Origen de los datos Nodo de Enlace Datos Formato del mensaje de datos enviaran su información al mismo tiempo. La comunicación intracluster es multisalto, por este motivo cada nodo común que recibe un mensaje enviado por un vecino, verifica si su ID coincide con el campo nodo de enlace del mensaje de datos, coloca en dicho campo su propio NDE y reenvía el mensaje en forma inmediata. El origen de los datos es importante para que el sink conozca cuantos nodos reportan a cada CH y éste lo utilice para definir el mensaje agregado. En la fase de envío de datos agregados cada CH procesa los mensajes enviados por los miembros de su cluster, concatenando las mediciones recibidas. La función de concatenación de mediciones se eligió a partir de los requerimientos de las aplicaciones de interés, que necesitan contar con todos los valores obtenidos. La información agregada de cada CH se envía a su enlace en el árbol de cabeceras, utilizando la estructura de mensaje mostrada en Fig. 4, con el fin de hacerla llegar a la estación base. Los nodos comunes no participan de las actividades y duermen hasta el siguiente período T. Las cabeceras que escuchan el mensaje que circula comparan su ID con el valor del campo nodo de enlace. Si coincide lo reenvían a su propio enlace, en caso contrario lo descartan. Si algún CH está desconectado del árbol de cabeceras, envía su mensaje agregado con un código de ayuda en el campo nodo de enlace. Todas las cabeceras que escuchan un mensaje agregado que contiene el código de ayuda, lo reenvían a sus NDE. De esta forma los agregados de los CH sin enlace llegan a la estación base, que es la responsable de filtrar eventuales repeticiones. Los nodos que participan en esta etapa son aquellos que cumplen el rol de CH, que según se espera serán aproximadamente uno por cuadro de la grilla. La potencia de transmisión es mayor a la correspondiente a la fase de envío de datos intracluster, por lo tanto, pese a la disminución de nodos participantes, pueden producirse colisiones que degradan la cantidad de mensajes que llegan al sink. Por este motivo, se implementó un esquema TDMA para el envío de los mensajes agregados. C. Fase de bajo consumo de los dispositivos Una vez finalizada la etapa de envío de datos agregados todos los CH entran en estado de bajo consumo, de la misma forma que hicieron los NC al finalizar la etapa de envío de datos, esperando el cumplimiento del período de adquisición de datos T. Cuando esto ocurre, si se han cumplido las X rondas Tipo de Mensaje Fig. 4 Origen de los datos Nodo de Enlace Formato del mensaje de datos agregados Datos Agregados necesarias para realizar la rotación de cabeceras, se aborda una nueva definición del árbol de encaminamiento, en caso contrario se inicia una nueva fase de envío de datos. III. IMPLEMENTACIÓN DE LOS NODOS A. Plataforma Hardware En [7] se describieron los requerimientos base para la elección de la plataforma de hardware a utilizar. Sintéticamente aquí, para la implementación efectiva, ensayos y pruebas de laboratorio de Cluditem fue elegido el integrado CC2530 de Texas Instruments que constituye una verdadera solución System-on-Chip (SoC) para el IEEE 802.15.4, utilizado en las capas inferiores por Cluditem. El CC2530 incluye características relevantes para la implementación [9]: • 256 KB Flash y 8 KB de RAM, suficientes para la implementación de los protocolos y las rutinas que se fueren necesarias en aplicaciones de supervisión ambiental, incluidas la que requieran implementar complejas funciones de agregación. • Transmisor/receptor de RF IEEE 802.15.4 en 2.4 GHz de alta sensibilidad (102 dBm) y excelente rechazo de canales adyacentes (49 dB). • Cuatro modos de funcionamiento en cuanto al ahorro de energía, incluyendo uno por temporización de 1uA de consumo. • 21 pines de propósito general, que cubren sobradamente las necesidades en cuanto a conexión de sensores. Para la implementación de los nodos se adquirieron módulos CC2530 EM que incluyen cristales, conectores de antena y otros mínimos componentes, y se desarrolló una placa base que incluye pulsadores, leds de diagnóstico (activos sólo para las pruebas), regulador de tensión, puerto de depuración (opcional), conectores para los sensores y portapilas (contramontado)[10]. La Fig. 5 muestra el módulo CC2530 montado sobre la placa desarrollada y con un par de sensores conectados. Todos los nodos de campo son exactamente iguales. En cambio, el sink fue implementado directamente utilizando un módulo CC2531, provisto en este caso por Texas en un montaje en forma de “dongle”. El CC2531 es idéntico al CC2530 pero cuenta con interfase física USB, por lo que puede ser conectado directamente a una PC a los efectos de la recolección de las mediciones en los ensayos. B. Plataforma software y aplicación Texas Instruments provee un conjunto de librerías con funciones que constituyen un stack completo con API de IEEE 802.15.4 para el desarrollo rápido de aplicaciones sobre el CC2530. En nuestro caso, la aplicación desarrollada es Cluditem con algún agregado referido a la realización de las mediciones. Los componentes provistos por Texas Instruments son [7]: • TI_MAC: brinda al usuario todas las funciones requeridas para manejar el envío y recepción de datos de forma inalámbrica, es decir, el manejo e implementación de la capa MAC del protocolo IEEE 802.15.4. Se relaciona con la aplicación mediante envíos de mensajes implementados en la OSAL. • OSAL (Operating System Abstraction Layer): permite aislar los componentes del stack TI del ambiente de procesamiento. En particular provee, entre otras, facilidades para la creación de tareas y su sincronización, manejo de temporizadores e interrupciones y asignación de memoria. • HAL (Hardware Abstraction Layer): permite el acceso a las UART, los dispositivos de entrada y salida de propósito general, el ADC y los temporizadores. Provee funciones de inicialización, de acceso directo al hardware mediante servicios y funciones de callback para manejar los eventos generados por el mismo. C. Aplicación CLUDITEM Se desarrollaron dos aplicaciones diferentes que hacen uso intensivo del stack de TI y sus funciones, una para todos los nodos de la red y otra para la estación base o nodo sink, atendiendo a su comportamiento diferenciado. En ambos casos, Cluditem define en cada una de sus fases de funcionamiento un esquema de tiempos, que rige el inicio y finalización de las tareas de la red, que debe ser respetado por el sink y por los nodos sensores para que el intercambio de mensajes sea efectivo. En este sentido, las aplicaciones desarrolladas incorporan un conjunto de temporizadores que, al cumplir el período que se les asigna, lanzan eventos asociados con procesos que abordan tareas específicas. 1) Aplicación Nodo SINK En función de las diferentes etapas del protocolo, el nodo sink cumple con los ciclos de trabajo que se esquematizan en la Fig. 6 según se trate de una ronda con reconfiguración (del árbol de cabeceras) o sin reconfiguración. Esta aplicación entonces se estructura y opera de la manera que se describe a continuación. A partir de su main(): 1º. Inicializa los componentes de hardware, servicios y variables. Fig. 5 Placa desarrollada para el nodo sensor 2º. Requiere del operador los parámetros de la red para la constitución y posterior ensayo: cantidad de rondas de Fig. 6 Ciclo de trabajo del nodo Sink. a) Ronda con reconfiguración de la red. b) Ronda sin reconfiguración de la red medición para reconfiguración (X), cantidad de nodos por celda de la grilla virtual, cantidad de celdas y cantidad de nodos que se postulan para CH en cada rearmado del árbol de encaminamiento. 3º. Lanza un temporizador de 3 segundos asociado con el evento Envío_PARAMETROS. 4º. Arranca OSAL. A partir de allí, se dispararán los siguientes eventos y procesos desarrollados: • • Evento Envío_PARAMETROS: envía un mensaje de parámetros con las opciones del usuario y lanza evento Envia_Sinc1 Evento Envia_Sinc1: Envía el mensaje SINC1 (de sincronización de la red), lanza el evento Envia_Sinc2 y ejecuta el procedimiento ProcessRoundTime. • Evento Envia_Sinc2: Envía el mensaje SINC2. • Proceso ProcessRoundTime: Si es una ronda que implica rotación, lanza los eventos Envia_ACH, Envia_Datos_al_PC y Envia_Sinc1 (que da origen a una nueva ronda de mediciones). Si es una ronda sin rotación, lanza los eventos Fig. 7 Envia_Datos_Al_PC y Envia_Sinc1 (que da origen a una nueva ronda de mediciones). 2) Aplicación Nodo de Red Si bien los ciclos de operación de los nodos de la red son iguales para nodos comunes y para CH, las etapas por las que pasan cada uno son diferentes. Para los nodos cabeceras la Fig. 7 muestra las mismas según se trate de rondas con o sin reconfiguración. Análogamente, los nodos comunes pasan por las etapas que se indican en la Fig. 8. La aplicación para los Nodos de Red se estructura y opera de la manera que se describe a continuación. A partir de su main(): 1º. Inicializa de los componentes de hardware, servicios y variables 2º. Arranca OSAL A partir de allí, y en función de los mensajes recibidos, se dispararán los siguientes eventos y procesos desarrollados: • Recibe Mensaje PARAMETROS: toma los valores recibidos fijando las constantes que definen el proceso e inicializa el nodo con ellos. • Recibe Mensaje SINC1: Retransmite una sola vez el mensaje SINC1 y ejecuta el procedimiento ProcessRoundTimeNodo(0). Ciclo de trabajo del nodo CH. a) Ronda con reconfiguración de la red. b) Ronda sin reconfiguración de la red Fig. 8 Ciclo de trabajo del nodo común. a) Ronda con reconfiguración de la red. b) Ronda sin reconfiguración de la red Recibe Mensaje SINC2: Si recibió previamente SINC1, lo retransmite sólo una vez y no hace más nada. Si no recibió previamente SINC1, lo retransmite solo una vez, y ejecuta ProcessRoundTimeNodo(X). • Proceso ProcessRoundTimeNodo: si es ronda que implica rotación, blanquea todos los punteros de la red de nodos comunes y de nodos cabeceras. Si es un nodo al cual le corresponde postularse en esta ronda lanza el evento ES_CANDIDATO_A_POSTULARSE y en caso contrario lanza los siguientes eventos: ENVIA_DATOS, NODO_COMUN_A_DORMIR, TODOS_A_DESPERTAR. Si en cambio se trata de una ronda que no implica rotación, se respetará la función que tiene asignada el nodo (común o cabecera) y se actuará en consecuencia: Cabecera: lanza los siguientes eventos ENVIA_AGR, CH_A_DORMIR, TODOS_A_DESPERTAR. Común: lanza los siguientes eventos ENVIA_DATOS, NODO_COMUN_A_DORMIR, TODOS_A_DESPERTAR. Los eventos mencionados operan como sigue: • Evento ES_CANDIDATO_A_POSTULARSE: si debe efectivamente postularse, lanza los eventos ENVIA_EC, ENVIA_AGR, CH_A_DORMIR y TODOS_A_DESPERTAR, y se establece como cabecera. En caso contrario, lanza los eventos ENVIA_DATO, NODO_COMUN_A_DORMIR, TODOS_A_DESPERTAR, y se establece como nodo común. • Evento TODOS_A_DESPERTAR: Despierta el nodo, lanza el evento PREGUNTA_POR_SINC y suma 1 al número de ronda. Este evento es invocado cuando el nodo vuelve de su estado SLEEP, de bajo consumo. • Evento PREGUNTA_POR_SINC: si no recibió ni SINC1 ni SINC2, se determina que pase al estado de bajo consumo y se lanza el evento TODOS_A_DESPERTAR para el momento correcto según sea ronda de rotación o no. IV. RESULTADOS DE LOS ENSAYOS En este trabajo se pretende evaluar el funcionamiento de la red respecto de la estructura de clusters producida por el algoritmo y la calidad de servicio de la red, respecto de la información recolectada. Las métricas definidas en [6], se adaptaron para el presente estudio que no considera cuestiones relativas al consumo de energía, resultando: • Estructura de clusters: Se evaluó en base a la cantidad de CH por celda de la grilla. La situación ideal corresponde a un único CH por celda, previéndose la posibilidad de que existan a los sumo dos. Esto se debe a que la presencia de mayor cantidad de CH impacta negativamente en el balance energético de la red. • Calidad de servicio: Se evaluó en base a dos métricas. La primera se basa en la cantidad de nodos que reportan en una ronda de medición, considerándose válida aquella ronda en la cual participan al menos el 90 % de los nodos. La segunda refiere al volumen total de mediciones realizadas, considerándose aceptable la recepción en la estación base de al menos el 90 % de las mediciones realizadas. Los ensayos se realizaron utilizando 21 nodos construidos a partir del diseño presentado en [7]. Uno de ellos se configuró como sink y los restantes como nodos de red, programándolos con las aplicaciones descriptas en la sección anterior. Se planificó la realización de 4 ensayos de 5000 mediciones cada uno, equivalentes a 10 días de funcionamiento de la red, con los 20 nodos distribuidos en 4 celdas de 5 dispositivos. Por lo tanto, cada ensayo estuvo constituido por 5 tandas de 50 rondas de medición cada una. En primer lugar se evaluó la estructura de clusters definida por el algoritmo en base a la métrica adoptada. Cluditem utiliza, en el escenario elegido, 4 celdas para definir la estructura de encaminamiento de la red, realizándose 5 reconfiguraciones en cada uno de los 4 ensayos. Por lo tanto, en la definición de los clusters participan 80 celdas en total, y los resultados obtenidos mostraron que el 77,5% tuvieron 1 único CH, y las restantes 2. A continuación se analizó la calidad de servicio de la red en base a los resultados mostrados en la Fig. 9, que contabiliza el porcentaje acumulado de rondas de medición en cada ensayo, respecto de la cantidad de nodos Fig. 9 Calidad de servicio. Primera métrica que reportaron al sink. Puede apreciarse que en todos los ensayos, en más del 90 % de las rondas de medición participaron al menos el 90% de los nodos. En promedio, el 94,3 % de las rondas cumplieron con la primera métrica de la calidad de servicio. Los resultados asociados con la segunda métrica se muestran en la Tabla I, donde se observa que en todos los ensayos el sink recibió al menos el 94,7% de las mediciones realizadas por la red. V. CONCLUSIONES Los resultados obtenidos permitieron confirmar un funcionamiento del protocolo Cluditem acorde a su diseño y por lo tanto validar tanto el desarrollo e implementación del mismo como su implantación sobre el SoC CC2530. Asimismo, pudo comprobarse que la red se mantiene dentro de los parámetros de funcionamiento deseados para la topología de clusters desplegada dinámicamente por el algoritmo en todos los casos ensayados, por un lado, y también en lo que hace a la calidad de servicio pretendida, por otro. Respecto de la estructura de clusters definida por el algoritmo se puede concluir que el 22,5% de las celdas adoptaron 2 CH, lo que incrementa el consumo de energía en los dispositivos. Si comparamos los resultados obtenidos en este trabajo con los realizados en el ambiente de simulación NS2 [11] podemos concluir que si bien existe una concordancia en lo que hace a las configuraciones de clusters a las que se arriban en ambos casos, la simulación arrojaba valores de calidad de servicio (mayores a 99%) muy por encima de los obtenidos en la TABLA I. Ensayo 1 2 3 4 CALIDAD DE SERVICIO. SEGUNDA MÉTRICA Mediciones realizadas (1) 5000 5000 5000 5000 Mediciones recibidas (2) 4819 4790 4766 4734 (1) / (2) x100 96,4% 95,8% 95,3% 94,7% práctica en los presentes ensayos. Esta discrepancia era previsible y se justifica sobre la base de no poder incluir en el escenario simulado, ciertos parámetros específicos del sistema irradiante, o agentes externos aleatorios, como interferencias en la banda de 2,4 GHz utilizada en los ensayos. REFERENCIAS [1] J. Yick, B. Mukherjee and D. Ghosal, “Wireless sensor network survey,” Computer Networks: The International Journal of Computer and Telecommunications Networking (Elsevier), vol. 52 pp. 2292-2330, August, 2008 [2] C.Burattii et al. (2009, August). An Overview on Wireless Sensor Networks Technology and Evolution, Sensors [Online]. 9 (9). Disponible: http://www.mdpi.com.. [3] L.M., Oliveira and J.P. Rodrigues, “Wireless Sensor Networks: a Survey on Environmental Monitoring”, Journal of Communications, Vol 6, (2), pp.143-151, April 2011. [4] D. Goyal and M. R. Tripathy, “Routing Protocols in Wireless Sensor Networks: A Survey”, in Proc. Second International Conference on Advanced Computing & Communication Technologies, Rohtak, India, 2012, pp. 474 – 480 [5] S.K.Gupta, N. Jain and P. Sinha, “Clustering Protocols in Wireless Sensor Networks: A Survey”, International Journal of Applied nformation Systems (IJAIS), Vol 5 (2), pp. 41 – 50, January 2013. [6] R. Corti. (2012, Marzo). Clustering dinámico para tiempo de encendido mínimo en redes de sensores inalámbricas CLUDITEM (1a ed.) [Online] Disponible: http://sedici.unlp.edu.ar/handle/10915/4209 [7] E. Giandoménico, R. Corti, J. Belmonte, R. Martínez, “Implementación de un algoritmo de encaminamiento para redes inalámbricas de sensores”, en Memorias de IV Congreso de Microelectrónica Aplicada, Bahia Blanca, septiembre 2013, pp.1 – 6. [8] E. Giandomenico et al., “Consumo de energía en un algoritmo de sincronización,” en Memorias del II Simposio Científico y Tecnológico en Computación, Caracas, 2012, pp. 83 – 88 [9] Texas Instruments, “A True System-on-Chip Solution for 2.4-GHz IEEE 802.15.4 and ZigBee Applications”. Disponible: http://www.ti.com/lit/ds/symlink/cc2530.pdf [10] C. Rochinotti, I. Pianetti, (2013) “Red inalámbrica de sensores de temperatura en lagunas de estabilización,” FCEIA / UNR , Rosario, Proyecto Final, Disponible: http://pi.eie.fceia.unr.edu.ar/?p=473 [11] The Network Simulator ns-2. Disponible: http://www.isi.edu/nsnam/ns/