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; encaminamiento;
plataforma software; System on Chip
I. 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 multi-
salto 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 Nivel del
CH elegido Emisor
Mensaje Emisor
Fig. 1. Formato del mensaje EC
Tipo de Nivel del
Emisor
Mensaje Emisor
Fig. 2 Formato del mensaje de ACH
Tipo de Origen de Nodo de
Datos
Mensaje los datos Enlace
Fig. 3 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 Origen de Nodo de Datos
Mensaje los datos Enlace Agregados
Fig. 4 Formato del mensaje de 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
Fig. 5 Placa desarrollada para el nodo sensor
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.
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 Ciclo de trabajo del nodo CH. a) Ronda con reconfiguración de la red. b) Ronda sin reconfiguración de la red
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).
 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 como sink y los restantes como nodos de red, programándolos
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ó
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. CALIDAD DE SERVICIO. SEGUNDA MÉTRICA
Ensayo Mediciones Mediciones (1) / (2) x100
realizadas recibidas
(1) (2)
1 5000 4819 96,4%
2 5000 4790 95,8%
3 5000 4766 95,3%
4 5000 4734 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/