How to deploy a Node-Red environment on a GCP instance

Son numerosos los tutoriales en Internet que explican cómo montar un servidor Node-RED sobre GCP haciendo uso de clústers. Sin embargo cuesta encontrar (si es que los hay), tutoriales sobre como desplegar dicho servidor en una instancia, por lo que en este tutorial, nos centraremos en este caso. ¿Te suena a chino todo lo que hemos dicho? ¿Por qué montarlo sobre una instancia y no un clúster? Expliquemos brevemente los conceptos más raros de la frases anteriores para entendernos mejor.

  • Node-RED: es una herramienta de programación, de libre distribución, la cual nos permite de una forma rápida, y sobretodo muy intuitiva, desplegar una web con un estilo moderno y funcional. Node-RED hace uso de la programación “en cajas”, en la cual interconectamos distintos bloques ya pre hechos de las librerías disponibles. Node-RED usa Javascript y permite introducir bloques con nuestro propio código, pero para las tareas más sencillas no será siquiera necesario saber Javascript. Un ejemplo de un desarrollo simple en Node-RED sería el siguiente:

node_red_example

Node-RED permite además añadir librerías creadas por usuarios, siendo la librería “dashboard” una de las más populares, pues incorpora cajas con elementos visuales que permiten la interacción con el usuario así como la visualización de datos. Un ejemplo de ello:

maxresdefault

¿Fácil, verdad? Quien diría viendo esa web que se ha hecho sin necesidad de saber ningún lenguaje, solo juntando las cajas correctas. Existen otras opciones, como thingsboard.io, pero para gustos los colores, además de no ser la mayoría gratuitas (o tener planes gratuitos muy limitados). Nosotros preferimos Node-RED porque integra soporte para comunicaciones por UDP, TCP y el reciente MQTT, lo que permite comunicaciones con cualquier tipo de dispositivo, especialmente con dispositivos IoT. Además, la comunidad de desarrolladores es enorme y podemos encontrar muchos ejemplos ya hechos para su libre distribución, siendo estos ejemplos a veces, justo lo que buscamos.

Tenemos muchas formas de ejecutar Node-RED, en nuestro PC (esto es corriendo en un servidor local), en páginas que ponen a nuestra disposición servidores ya montados y listos para empezar a trabajar (FRED) o en servidores virtuales privados (VPS) de los cuales hay cientos de ofertas en Internet (aunque destacan por su catálogo y precios Microsoft Azure, Amazon Web Services [AWS] y Google Cloud Platform [GCP]). Las ventajas de ejecutar nuestro entorno en un VPS frente a nuestro ordenador o un entorno ya hecho (y cerrado) son inmensas: disponibilidad total, herramientas de protección, escalabilidad, no compromiso de nuestros datos privados, gestión de recursos… y esas son solo alguna de ellas.

  • Google Cloud Platform: es uno de los tantos servicios de gestión de VPS que hay hoy en día. Si bien es cierto que uno de los que más fuerza tiene es AWS, Google ofrece algo que no ofrece el resto: un servidor gratuito al año con 24/7 en ejecución. Vale que es un servidor muy modestito (10 GB de almacenamiento; 0.6 GB de RAM y un único procesador), pero es gratis y para diseños simples puede ser más que suficiente. Es por esto que nos centraremos en este gestor VPS en este tutorial.
  • Instancia vs. cluster: Google denomina a cada uno de los VPS que creamos instancia. Un grupo de instancias trabajando de forma conjunta, compartiendo recursos y distribuyéndose el tráfico de red entre ellas forma un clúster. Claro, a priori parece que el clúster es mejor (y lo es), pero no es gratis. La instancia, sin embargo, sí. Siempre y cuando esa instancia sea de las más simples de Google, como ya hemos comentado antes.

Ahora que ya hemos explicado todo un poco, relee si quieres el primer párrafo del post. Ahora ya parece obvio por qué queremos desplegar Node-RED (y no otro) sobre una instancia (y no un clúster), porque…

free

 

Empecemos…

Lo primero, lógicamente, es tener una cuenta de Google activa. Nos dirigiremos a la consola de Google Cloud y activaremos nuestra cuenta, registrándonos en la versión de prueba gratuita.  Solo por registrarnos Google nos regala 300 $ en servicios GCP. Para nuestros propósitos no nos harán falta, pero nos vendrán genial si queremos cacharrear con todas las opciones que GCP ofrece. Completaremos todos nuestros datos (incluida la tarjeta de crédito, pero no pasa nada: Google nos avisará previamente en caso de que hiciéramos algo que incurriera en un desembolso). Tras registrarnos se nos creará nuestro primer proyecto (que podremos renombrar si queremos pinchando en configuración de proyecto).

En el buscador escribimos Compute Engine y en la nueva ventana, una vez cargue, creamos una nueva instancia, con la configuración que vemos en la siguiente imagen:

g1
La zona da igual siempre que sea en América (salvo Virginia del Norte). América es la única región con VPS gratuitas. El tipo de máquina ha de ser micro y permitir el tráfico HTTP y HTTPS. Nosotros hemos elegido Ubuntu por familiaridad con los comandos, pero cualquier otra distribución de las gratuitas que ofrece Google es válida. Notad que para saber que estáis siguiendo los pasos correctos, debe apareceros el texto de la derecha donde os informa de que la máquina seleccionada es gratuita. Pulsamos en crear y esperamos.

Una vez creada, hay diferentes cosas que sería interesante hacer antes de empezar a cacharrear (asignarnos una IP estática y abrir algunos puertos).

-Asignando IP estática podremos entrar en nuestro servidor sin necesidad de consultar qué IP nos ha concedido Google esta vez: siempre será la misma. Para ello escribimos Red de VPC en el buscador y entraremos en la sección del menú lateral izquierdo “Direcciones IP externas”. Seleccionaremos nuestra instancia y cambiaremos su tipo a estática. Le ponemos un nombre identificativo a esta IP y aceptamos.

-Abriendo puertos (bien sea TCP o UDP) permitiremos un acceso remoto a nuestro servidor. Hay que notar que esto es un arma de doble filo, pues si bien no podemos hacer mucho sin tener acceso a nuestro servidor remoto también es una puerta abierta a hackers, por lo que recomendamos abrir solamente los puertos que vayamos a necesitar. En nuestro caso será obligatorio abrir el puerto TCP 1880, pues será el que usará Node-RED tanto para la interfaz de diseño (donde colocaremos las cajitas) como para la interfaz web (donde nos mostrará el resultado de colocar y conexionar esas cajitas). Para ellos tecleamos en el buscador “Reglas de cortafuegos” y elegimos la opción que lleve también escrito Red de VPC.

Creamos una regla nueva:allowtcp

 

El nombre es opcional, todo lo demás, recomiendo dejarlo a esos valores. Cuando cojáis más soltura con GCP os recomiendo etiquetar vuestras distintas instancias para poder elegir destinos de reglas del cortafuegos y así que cada máquina tenga abiertos los puertos que necesita. Por ahora, y como solo tenemos una máquina creada, no pasa nada por aplicar en el campo destinos “todas las instancias de la red”. Guardamos y ya estaremos listos para empezar la instalación de Node-RED sobre nuestro VPS.

Volvemos a la vista de Compute Engine, donde estará nuestra instancia. En el campo “Conectar” pulsamos sobre SSH. Se nos abrirá una ventana nueva y cuando cargue ya estaremos dentro de nuestro VPS.

Para poder empezar a trabajar, tecleamos los siguientes comandos:

Nótese que entre los comandos, se instalará nodejs. En nuestro caso hemos instalado la versión 8.x por ser la recomendada en el momento de realizar este tutorial, pero se aconseja mirar en la página de nodejs cual es la última versión recomendada. Escribimos ahora el comando que instalará Node-RED en nuestro VPS.

Es también interesante instalar algunas herramientas de node-red que nos harán más fácil la gestión de nuestro servidor, por lo que teclearemos:

Después de esto ya podemos probar que Node-RED está correctamente instalado. Para ellos tecleamos:

Lo que debería arrojar en el terminal una salida que acaba con:

Esto es indicativo de que todo está correcto. ¡Probémoslo! Escribamos en nuestra barra del navegador la IP estática concedida por Google (sin http ni https delante seguida del puerto de acceso a Node-RED, separado por dos puntos “:”), algo así como 123.123.123.123:1880. Deberíamos ver esto:

node-red1

 

¡Todo funciona! Sin embargo esto presenta un enorme, enorme inconveniente: cualquiera que sepa nuestra IP puede acceder a nuestro servidor Node-RED y borrarnos todo el trabajo o inyectar código malicioso. Por ello, el siguiente paso, de vital importancia, es proteger nuestro servidor. Volviendo a la terminal abierta por SSH, pulsamos ctrl+C para parar la ejecución de Node-RED y escribiremos:

Lo que nos preguntará por la contraseña con la que deseamos proteger el servidor. Tras escribirla y pulsar intro, nos devolverá una secuencia hash con nuestra contraseña encriptada, que deberemos copiar, pues usaremos ahora. Escribiremos sobre el archivo de configuración de Node-RED. En el terminal tecleamos:

y dentro de este archivo buscaremos el siguiente texto:

adminAuth: {
type: “credentials”,
users: [{
username: “USUARIO“,
password: “HASH_GENERADO“,
permissions: “*”
}]
},

// To password protect the node-defined HTTP endpoints (httpNodeRoot), or
// the static content (httpStatic), the following properties can be used.
// The pass field is a bcrypt hash of the password.
// See http://nodered.org/docs/security.html#generating-the-password-hash
httpNodeAuth: {user:”USUARIO“,pass:”HASH_GENERADO“},
httpStaticAuth: {user:”USUARIO“,pass:”HASH_GENERADO“},

En usuario escribiremos el usuario que queramos, y en los campos password y pass, el hash generado anteriormente. La primera parte protegerá la parte de gestión (donde colocamos las cajitas), la segunda, la parte de visualización (la web que crean las cajitas). Es importante descomentar las lineas necesarias (esto es, eliminar los caracteres “//” con los que empiezan algunas lineas), para que el resultado quede tal y como hemos puesto arriba. Guardamos con CTRL+O y salimos con CTRL+X.

Por último, será interesante que nuestro servidor cargue automáticamente Node-RED cuando se reinicie, lo que hará más tolerante a fallos nuestra implementación. Para ello, escribimos:

Que nos indicará nuestro nombre de usuario. A continuación:

donde copiaremos el siguiente texto:

[Unit]
Description=Node-RED
After=syslog.target network.target

[Service]
ExecStart=/usr/bin/node-red
Restart=on-failure
KillSignal=SIGINT

# log output to syslog as ‘node-red’
SyslogIdentifier=node-red
StandardOutput=syslog

# non-root user to run as
WorkingDirectory=/home/TUUSUARIO/
User=TUUSUARIO
Group=TUUSUARIO

[Install]
WantedBy=multi-user.target

Hay que modificar solo los campos en rojo. Nuevamente, guardamos con CTRL+O y salimos con CTRL+X. Activamos el servicio creado escribiendo:

Comprobaremos que todo se haya hecho correctamente. Para ello primero es necesario reiniciar, por lo que escribimos:

Y tras esperar unos dos minutos, cargamos de nuevo la página con la IP del servidor en nuestro navegador. Ahora, al cargar node-RED debería pedirnos login, tanto a la parte de gestión como a la de visualización.

¡Eso es todo por nuestra parte! Ahora, a jugar.

Poster about Methodology for implementation of Synchronization Strategies for Wireless Sensor Networks

On the occasion of the II edition of the Symposium “Tell us your thesis” organized by the Universidad Politécnica de Madrid I created a poster summary of my thesis.

Both the thesis and the poster are entitled “Methodology for implementation of Synchronization Strategies for Wireless Sensor Networks“.

In the poster I intend to explain the process that every researcher and/or developer must carry out to add synchronization tasks to his Wireless Sensor Network.

180216 Methodology for implementation of Synchronizatoin WSN
Methodology for implementation of Synchronizatoin WSN

First of all it is needed to know what is the objective of the user application in which we want to add temporary synchronization.

Based on the application we will have some requirements to fulfill. That is, each application will have different requirements regarding timing, maximum permissible error regarding temporal precision or accuracy, network topology, message distribution method, battery consumption and life time objectives, hardware resources of different nature and different price, etc.

Since there are many options and possible ways, a methodology is needed that helps the researcher and/or developer to obtain a solution, in order to achieve a time synchronization in their wireless sensor networks, which is adapted to the needs of the application.

The development of this methodology is the objective of this doctoral thesis.

Download the poster with full resolution [PDF 18 MB]

LÁZARO: Development of an innovative ICT system for the detection of architectural barriers and monitoring based on augmented reality

 

LÁZARO is a project carried out alongside Valoriza Servicios a la Dependencia S.L.U., with the objective of developing a system to automatically detect architectural barriers making use of computer vision and augmented reality. It will integrate the detection provided by sensors and images and the display of an augmented reality layer, together with a warning and checking system for the barriers.

In addition to the first objective, the project pursues another important goal, the development of a wireless sensor network to monitor the living conditions of people with special needs, such as elderly or disabled people. Therefore, the system will result in an integral solution for assisted living facilities and residences, although it can be applied to several other environments.

_JFF3543

The project details are as follows:

Title: LÁZARO: Development of an innovative ICT system for the detection of architectural barriers and monitoring based on augmented reality
Duration: 2016-2017
Partners: Valoriza Servicios a la Dependencia S.L.U. and Universidad Politécnica de Madrid
Financing entity: Valoriza Servicios a la Dependencia S.L.U. via CDTI.

Logo CDTI-MINECO con Gill Sans

A WSN-Based Intrusion Alarm System to Improve Safety in Road Work Zones

Title: A WSN-Based Intrusion Alarm System to Improve Safety in Road Work Zones
Authors: Jose Martin, Alba Rozas, and Alvaro Araujo
Published in: Journal of Sensors
Date of Publication: Jun 2016
Digital Object Identifier : 10.1155/2016/7048141
Web: https://www.hindawi.com/journals/js/2016/7048141/

Road traffic accidents are one of the main causes of death and disability worldwide. Workers responsible for maintaining and repairing roadways are especially prone to suffer these events, given their exceptional exposure to traffic. Since these actuations usually coexist with regular traffic, an errant driver can easily intrude the work area and provoke a collision. Some authors have proposed mechanisms aimed at detecting breaches in the work zone perimeter and alerting workers, which are collectively called intrusion alarm systems. However, they have several limitations and have not yet fulfilled the necessities of these scenarios. In this paper, we propose a new intrusion alarm system based on a Wireless Sensor Network (WSN). Our system is comprised of two main elements: vehicle detectors that form a virtual barrier and detect perimeter breaches by means of an ultrasonic beam and individual warning devices that transmit alerts to the workers. All these elements have a wireless communication interface and form a network that covers the whole work area. This network is in charge of transmitting and routing the alarms and coordinates the behavior of the system. We have tested our solution under real conditions with satisfactory results.

TFG: Diseño, desarrollo e implementación de un sistema de adquisición, almacenamiento y presentación de los datos obtenidos de una red de sensores inalámbricos

El objetivo de este Trabajo Fin de Grado es el diseño e implementación un sistema que adquiera, procese y almacene los datos obtenidos de la WSN y los presente a través de un servidor Web que permita consultar datos en tiempo real y en un histórico, así como envío de parámetros de control, con los que configurar la WSN.

El proyecto se basará en una red de sensores inalámbricos desarrollada de forma simultanea en otro Trabajo Fin de Grado, compuesta por dos tipos de nodos, Prometheus y Boucherot. Los nodos Prometheus se encargarán de medir valores como presencia y temperatura, además de estado de sus baterías, mientras que los Boucherot monitorizarán el consumo de todo dispositivo conectado a ellos. Asimismo, los nodos Boucherot también implementan una serie de actuadores que permiten el encendido y apagado de los aparatos conectados a los mismos. Esta red presenta además una serie de comandos que permiten configurar ciertos parámetros de medida de la red y del estado de sus nodos.

Para la implementación del sistema se ha recurrido a distintas herramientas:

  • Desarrollo de script en Python para adquisición, procesado y almacenamiento en base de datos. Así como el envío de comandos de control a la red inalámbrica. Se han empleado los módulos serial, sqlite3 y pynotify.
  • Desarrollo del servidor Web en Node.js, que sirve paginas con información de la red, información de las medidas en tiempo real y en un histórico, con módulos: socket.io, sqlite3, http-auth entre otros.
  • Diseño de las paginas web que se muestran en el cliente basadas en distintos frameworks como: Bootstrap 3, graficas de HighCharts, y tablas con Datatables y jQuery.

A continuación se muestra una breve descripción de la interfaz del sistema con el usuario, que se realiza a través de una serie de paginas web:

DOMOLabo B105_TrealPágina que muestra dinámicamente las medidas en Tiempo Real tomadas por la WSN

DOMOLabo B105_Hist

Página que muestra Histórico de las medidas tomadas por la WSN

Ambas páginas, constan de una serie de gráficas que muestran las medidas tomadas por la WSN. Cada gráfica agrupa a todos los sensores de un tipo y permite seleccionar los nodos que se desean visualizar en la leyenda. Además permite hacer zoom en la gráfica, bien seleccionando sobre ella o bien pulsando alguno de los botones de la esquina superior izquierda de la gráfica. También es posible exportar datos en distintos formatos, .pdf, .png, .svg, etc. gracias al botón situado en la esquina superior derecha.

DOMOLabo B105_Sensores

Página que muestra información y permite el control de la WSN

Esta pagina consta de una tabla principal donde se muestra información de todos los nodos de la red (identificadores, tipos de sensores presentes, localización del sensor y estado de la batería y de sus actuadores). En la parte inferior de la tabla se encuentra un formulario que permite añadir nuevos sensores al sistema.

En la parte superior de la tabla se presenta un conjunto de botones que permiten el envío de una serie de comandos de control a la red (Relé, Configurar el tiempo que un nodo permanece dormido y en estado activo, actuar sobre el relé y/o los leds, etc.). Estos comandos se envían al nodo AP de la red que se encarga de enviarlos al nodo que corresponda.

También se ha implementado una autenticación de usuarios, para el control de acceso a funciones de configuración de la red y del sistema. Para los usuarios no administradores el aspecto es ligeramente diferente al presentado, ya que las funciones de control están desactivadas y no se permite la incorporación de nuevos sensores al sistema. Sin embargo la tabla es visible y se permite como en el caso anterior consultar e imprimir el estado de la red.

Se ha tenido especial interés en implementar un sistema modular, en el cual la caída de un modulo no imposibilite el normal funcionamiento del resto. Escalable, donde se puedan gestionar múltiples peticiones simultaneas de usuarios con distintos dispositivos y necesidades de consulta. Primando también la versatilidad del sistema respecto a la red de la que se adquieran los datos.

El sistema se ha dimensionado ampliamente para soportar una red con mas de 100 sensores y almacenar datos durante varias décadas, con tiempos de medida de 1 minuto para los sensores.

 

Thesis Proposal: Methodology for Implementation of Synchronization Strategies for Wireless Sensor Networks

 

Author: Francisco Tirado-Andrés

Advisor: Alvaro Araujo Pinto

Synopsis:
Wireless Sensor Networks (WSN) are networks composed of a large number of small devices that take measurements, process them, and communicate with other devices coordinating their operations. Time synchronization is necessary for that coordination of actions.

Multiple features characterized a WSN. Some of them are Power Consumption, Cost, Network type, Security, Data throughput, Scalability, etc.

WSNs bring us many benefits over traditional wired networks, but they also add difficulties to counteract its limitations.

The functionality of a WSN is very specific to the problem it solves. It is therefore that no single synchronization method is optimal along all axes. Unnecessary synchronization wastes resources; insufficient synchronization leads to poor application performance.

The requirements that are entailed to the various parameters that define the synchronization protocol will come imposed by the specific application to which it is oriented.

Because, it is not the same an application for a distributed humidity control in a natural park where each sample is collected every half hour and synchronization may deviate seconds without affecting the results, that the conditions required for an application of Wireless Surround Sound System where real-time operations and very small deviations are needed for a proper operation of the system.

But today there is no methodology that helps to design or configuration. Neither with the synchronization protocols nor the general system parameters.

There are many difficulties to be resolved because the synchronization protocol must meet not only the requirements of the application for which is designed, but also the intrinsic demands of WSNs.

One application where the results are very dependent on the accuracy of timing synchronization is Structural Health Monitoring (SHM). A configurable protocol which is able to adapt itself to the requirements of the application and the requirements of the system will be more useful and it will be ready for future applications and requirements.

My intention is to contribute, both during, and at the end of this thesis, with a methodology to guide and help implement synchronization protocols in Wireless Sensor Networks. Always keeping in mind that the synchronization protocol must meet requirements of accuracy and precision at the same time should not interfere with the performance of other tasks in the system. In that way the user will be able to adapt the configuration of the system and the parameters to get a productive WSN.

BackToTheFuture-Synchronization
Movie: Back To the Future. 23’17”

Cognitive Wireless Sensor Network Platform for Cooperative Communications

Title: Cognitive Wireless Sensor Network Platform for Cooperative Communications
Authors: Agustín Tena, Guillermo Jara, Juan Domingo, Elena Romero, Alvaro Araujo
Published in: International Journal of Distributed Sensor Networks
Date of Publication: January 2014
Digital Object Identifier : 10.1155/2014/473905
Web: http://www.hindawi.com/journals/ijdsn/2014/473905/

Nowadays, Wireless Ad-Hoc Sensor Networks (WAHSNs), specially limited in energy and resources, are subject to development constraints and difficulties such as the increasing Radio Frequency (RF) spectrum saturation at the unlicensed bands. Cognitive Wireless Sensor Networks (CWSNs), leaning on a cooperative communication model, develop new strategies to mitigate the inefficient use of the spectrum that WAHSNs face. However, few and poorly featured platforms allow their study due to their early research stage.

This paper presents a versatile platform that brings together cognitive properties into WAHSNs. It combines hardware and software modules as an entire instrument to investigate CWSNs. The hardware fits WAHSN requirements in terms of size, cost, features, and energy. It allows communication over three different RF bands, becoming the first cognitive platform for WAHSNs with this capability. In addition, its modular and scalable design is widely adaptable to almost any WAHSN application.

Significant features such as Radio Interface (RI) agility or energy consumption have been proved throughout different performance tests.

 

nodo

PUE Attack Detection in CWSN Using Collaboration and Learning Behavior

Title: PUE Attack Detection in CWSN Using Collaboration and Learning Behavior
Authors: Javier Blesa, Elena Romero, Alba Rozas, Alvaro Araujo and Octavio Nieto-Taladriz
Published in: International Journal of Distributed Sensor Networks
Date of Publication: June 2013
Digital Object Identifier : 10.1155/2013/815959
Web: http://www.hindawi.com/journals/ijdsn/2013/815959/

Cognitive Wireless Sensor Network (CWSN) is a new paradigm which integrates cognitive features in traditional Wireless Sensor Networks (WSNs) to mitigate important problems such as spectrum occupancy. Security in Cognitive Wireless Sensor Networks is an important problem because these kinds of networks manage critical applications and data. Moreover, the specific constraints of WSN make the problem even more critical. However, effective solutions have not been implemented yet. Among the specific attacks derived from new cognitive features, the one most studied is the Primary User Emulation (PUE) attack. This paper discusses a new approach, based on anomaly behavior detection and collaboration, to detect the PUE attack in CWSN scenarios. A nonparametric CUSUM algorithm, suitable for low resource networks like CWSN, has been used in this work. The algorithm has been tested using a cognitive simulator that brings important results in this area. For example, the result shows that the number of collaborative nodes is the most important parameter in order to improve the PUE attack detection rates. If the 20% of the nodes collaborates, the PUE detection reaches the 98% with less than 1% of false positives.

cognitive radio module

 

PUE attack detection in CWSNs using anomaly detection techniques

Title: PUE attack detection in CWSNs using anomaly detection techniques
Authors: Javier Blesa, Elena Romero, Alba Rozas and Alvaro Araujo
Published in: EURASIP Journal on Wireless Communications and Networking 
Date of Publication: September 2013
Digital Object Identifier : 10.1186/1687-1499-2013-215
Web: http://jwcn.eurasipjournals.com/content/2013/1/215

Cognitive wireless sensor network (CWSN) is a new paradigm, integrating cognitive features in traditional wireless sensor networks (WSNs) to mitigate important problems such as spectrum occupancy. Security in cognitive wireless sensor networks is an important problem since these kinds of networks manage critical applications and data. The specific constraints of WSN make the problem even more critical, and effective solutions have not yet been implemented. Primary user emulation (PUE) attack is the most studied specific attack deriving from new cognitive features. This work discusses a new approach, based on anomaly behavior detection and collaboration, to detect the primary user emulation attack in CWSN scenarios. Two non-parametric algorithms, suitable for low-resource networks like CWSNs, have been used in this work: the cumulative sum and data clustering algorithms. The comparison is based on some characteristics such as detection delay, learning time, scalability, resources, and scenario dependency. The algorithms have been tested using a cognitive simulator that provides important results in this area. Both algorithms have shown to be valid in order to detect PUE attacks, reaching a detection rate of 99% and less than 1% of false positives using collaboration.

clusters

 

PFC: Development of a Cognitive Wireless Sensor Network Simulator

network_image-640x250 (1)

The objective of this project is the development of a simulator of Cognitive Wireless Sensor Networks. This simulator must support Cognitive Radio techniques adapted to wireless sensor networks. These techniques are: spectrum sensing, collaboration and learning, among others.

Related Technologies

  • Cognitive Radio
  • Wireless Sensor Networks
  • Linux
  • C++

Task

  • State of the art study in cognitive networks
  • Simulation analysis andrequirements definition
  • Architecture definition
  • Implementation of the modules and functionality
  • Tests and results

Requirements

  • Dedication: 4 hours/day.

Tutor

Javier Blesa <jblesa@die.upm.es>

Elena Romero <elena@die.upm.es>

State

Not assigned