Propuesta de proyectos 2023

A continuación se listan los títulos de las propuestas de proyectos y a continuación su descripción. 

RSI 2023 - Presentación de propuestas

Lista de proyectos

  1. Visualización con LEDs del funcionamiento de una red TSCH/RPL

  2. RADAR distribuido basado en sincronización de nodos con TSCH

  3. Optimización de Redes de Sensores Inalámbricos

  4. NB-IoT

  5. Implementación y caracterización de RPL on/off

  6. Aplicación con plataforma sensortag (CC1350 o CC2650)

  7. Exploración de nueva plataforma: nrf52840 (Nordic)

  8. Contiki-NG en Arduino Nano 33 BLE Sense

  9. IPv6 over Bluetooth low energy (BLE)... with contiki-ng!

  10. Exploración de nueva plataforma: Gecko (Silicon Labs)

  11. Seguridad en Contiki-NG

Propuesta de proyectos

1. Visualización con LEDs del funcionamiento de una red TSCH/RPL

El objetivo del proyecto es evidenciar mediante el uso de LEDs de nodos de una red de sensores del funcionamiento de una red TSCH/RPL con fines didácticos. Se espera poder armar una demo utilizando más de diez nodos (remote) para mostrar el funcionamiento de la red en diferentes fases. Los resultados podrían ser usados en una instalación de IdM (Ingeniería de Muestra ,2024), en una instalación en el IIE, o mismo en el curso RSI.

La motivación radica que los tiempos involucrados en una red son muy cortos, y por más que fuera posible visualizar con un destello de un led en encendido de la radio para una transmisión o recepción, sería muy difícil seguir la secuencia de timeslots, por ejemplo en una red TSCH con Orchestra, o el “camino” de un mensaje UDP hacia destino.

Se proponen una serie de intervenciones para visualizar la dinámica de la formación y operación de una red descriptas a continuación:

  1. Funcionamiento enlentecido (efecto "slow motion"): permite visualización de la actividad de la radio aumentando algunos de los tiempos involucrados.
    Siguen algunas ideas iniciales a explorar o sugerencias:

    1. Aumentar los tiempos de timeslot por x10, x50, x100 (timeslot pasa de 10 ms a 100 ms, 500 ms, 1000 ms). Evaluar aumentar los tiempos dentro del timeslot (guardas, etc., ver: archivo tsch-timeslot-timing.c).

    2. Para visualizar la actividad de la radio se sugiere que los LEDs se manejen como monostable. Al recibir encenderse (por ejemplo, recibiendo un evento de turn-on) se mantiene on por un tiempo fijo dado, dependiente o proporcional al tiempo de la actividad y el factor de enlentecimiento.

    3. Para identificar la actividad de la radio usar patrones diferentes: i) LED codifican TX y RX como en Cooja (azul y verde) o, ii) LED on cuando radio on y color es canal 3) Usar patrones: RX LED es fijo, capaz tenue, y TX burst (prende y apaga rápido).

  2. Funcionamiento en tiempo real (velocidad x1): 

Para mostrar sincronización de nodos desde la fase de JOIN de TSCH se sugiere mostrar el canal utilizado con color diferentes de LEDs. Se podría cambiar entre este modo y un uso diferente de LEDs para mostrar la actividad de la radio (TX, RX, escucha). En ese último caso, donde es difícil seguir la secuencia, se podría filmar y luego reproducir en slow motion para mostrar que el efecto de a) es similar al real. Nota: verificar que tiempo de transmisión de un mensaje o escucha es suficiente para encender led.

  1. Definir diferentes demos usando las intervenciones anteriores para comparar modos de funcionamiento:

    1. minimal versus Orchestra: visualizar los slotoffset de cada nodo

    2. RPL formación de DODAG: envío de DIO y DAO.

    3. modos de RPL storing mode versus non-storing mode: visualizar camino de paquete UDP en diferentes modos de operación (se podría ver cómo avanza el mensaje). Nota: evaluar limitar el encendido de LED solamente para mensajes UDP. El envío de un mensaje UDP se puede iniciar con botones eligiendo destino como en laboratorio.

Funcionalidades para la ejecución de los demos.

  1. Bajar la potencia al mínimo para favorecer la formación de redes mesh en áreas relativamente reducidas u otras acciones tendientes a reducir el alcance (¿sacar antena?).

  2. Evaluar cambiar los parámetros en tiempo de ejecución desde un PC conectado al BR, por ejemplo usando comandos CoAP,. Opcionalmente se podría hacer GUI con python o similar. Para TSCH sería conveniente enviar duración de timeslot en EB. Si fuera necesario resetar los nodos para que tomen efectos los cambios se podría mandar un comando via CoAP que llame el comando shell de reset. Opcional: evaluar si es posible cambiar sin necesidad de reprogramar los nodos (se estima dificultad muy alta o inviable).

  3. Evaluar cambiar forma de funcionamiento de LEDs (permitiría por ejemplo mostrar sincronización inicial y luego mostrar slotframes, slottime, Tx/Rx)

Nota: las funcionalidades a implementar y los demos a preparar serán acordados con los docentes

2. RADAR distribuido basado en sincronización de nodos con TSCH

El objetivo del proyecto es implementar un radar que permite calcular la velocidad de vehículos registrando su “pasada” por nodos instalados en columnas de alumbrado equipados con un sensor de barrera (óptico o ultrasonido).

El uso de TSCH permite que los nodos estén sincronizados con precisión (noción coherente del tiempo con errores menores a milisegundos). Los sensores permiten registrar el tiempo en que un vehículo pasa frente a una columna. La información de tiempo de pasada se comparte entre nodos vecinos, junto información adicional.

Siguen algunas ideas de implementación:

  • Información recibida de su vecino (en sentido contrario al sentido de circulación)

    • tiempo de pasada

    • velocidad calculada

    • Nota: la distancia es conocida.

  • Cálculo de la distancia (punteo indicativo) y acciones:

    • Determinar tiempo de pasada de vehículos y registrar en cola/lista.

    • Asociar vehículo a tiempo de pasada del nodo (restringiendo la búsqueda a ventana) y estimar velocidad.

    • Enviar tiempo y velocidad al nodo siguiente.

    • Si la velocidad supera el máximo para su ubicación se manda una alerta.

  • Observaciones

    • Condiciones de borde

      1. Nodo de la punta (posición 0) podría registrar tiempo

      2. Nodo siguiente (posición 1) puede suponer que no se pasan los vehículos y calcular la velocidad basado en los dos tiempos.

    • Se deberá diseñar las pruebas para realizar de forma controlado, pudiendo ser en simulación Cooja pero aspirando que puedan realizarse en hardware (por ejemplo en laboratorio con un AD2 para generar pulsos o en campo accionando un botón)

    • La asignación de vecinos se puede hacer desde el BR (pasar la dirección a quien mandar los valores). 

    • En envío se puede hacer con UDP usando mensajes con formato conocido (struct).

Material:

3. Optimización de Redes de Sensores Inalámbricos

El proyecto se centrará en la automatización de simulaciones para estudiar cómo optimizar el funcionamiento de Redes de Sensores Inalámbricos con distintas topologías, y distintas  aplicaciones.

Se trabajará con una aplicación de recolección de datos (Convergecast), donde cada nodo enviará paquetes de datos periódicamente a un nodo centralizador, similar a lo realizado en los laboratorios. El parámetro que se variará de la aplicación será la frecuencia de envío de mensajes, pudiendo generar redes con tráfico alto, medio y bajo.

Se desarrollará un script en Python que genere distintas topologías de nodos en base a una serie de parámetros de entrada. Los nodos serán distribuidos de forma pseudo-aleatoria en un área acotada. Para ubicar los nodos, se seguirá la siguiente lógica. El primer nodo (i = 0) se ubicará de manera totalmente aleatoria. Luego los siguientes i-ésimos nodos se colocarán a una distancia d_i del (i-1)-ésimo nodo, donde d_i sigue una distribución gaussiana con una media de tres cuartos del rango de transmisión, y una desviación estándar de la mitad de este rango. Los parámetros que se podrán controlar son:

  1. Cantidad de nodos en la red.

  2. Cantidad máxima de vecinos de cada nodo (en un rango menor o igual al rango de transmisión).

  3. Ancho y largo de una caja imaginaria que contiene a todos los nodos, para permitir variar la densidad de nodos de la red.

Es importante notar que puede que dados ciertos parámetros el problema no tenga solución. Habrá que pensar cómo manejar esos casos de borde.

Una vez que se obtengan las topologías de red deseadas, se correrán barridos de simulaciones variando los protocolos de routeo y acceso al medio, y sus parámetros de configuración. A nivel routeo se estudiarán las implementaciones de RPL Classic y RPL Lite y sus distintos parámetros de configuración, mientras que en la capa de acceso al medio se estudiará CSMA, TSCH Minimal y TSCH Orchestra y sus distintos parámetros de configuración.

El objetivo principal del proyecto es, dada una cierta topología de red y aplicación, lograr optimizar los protocolos de routeo y acceso al medio para maximizar la cantidad de paquetes entregados correctamente al centralizador (maximizar PDR) y/o minimizar el consumo energético (minimizar RDC).

Para la automatización de las simulaciones se utilizarán los scripts del ejemplo contiki-ng/examples/benchmarks/result-visualization, y se utilizarán nodos de tipo cooja para acelerar los tiempos de ejecución. Los experimentos tendrán una duración de 60 minutos cada uno, para asegurar que se analiza una muestra representativa de tiempo.

4. NB-IoT

La tecnología NB-IoT (Narrow Band - IoT) ha surgido como una respuesta a la necesidad de estandarizar las comunicaciones entre dispositivos IoT, con requisitos de baja latencia y tráfico de datos reducido. Esta tecnología se clasifica como una red LPWAN (Low Power Wide Area Network) que evoluciona a partir del LTE, siendo compatible con sus bandas. Se distingue por su eficiencia en el consumo de energía,  confiabilidad en la conectividad, capacidad de soportar un gran número de dispositivos, amplio alcance de cobertura y la utilización de estrechos anchos de banda, generalmente alrededor de 200 kHz.

El desafío principal de este proyecto se encuentra en la gestión de un módulo de comunicación que utiliza la red NB-IoT a través de un microcontrolador. Este microcontrolador está equipado con un sensor que recopila datos para su posterior transmisión a través de la red NB-IoT. El hardware seleccionado para este propósito incluye el launchpad CC2605/CC1350 y el módulo de comunicación BG96 de Quectel. Para llevar a cabo esta tarea, se aprovecharán las herramientas proporcionadas por el sistema operativo Contiki-NG.

Uno de los aspectos desafiantes de este proyecto involucra la configuración del módulo de comunicación. Este proceso se realiza mediante comandos AT, y la correcta configuración se determina mediante la interpretación de las respuestas a estos comandos. Además, se deben gestionar las URCs (Unsolicited Result Code) del módulo de comunicación BG96 de Quectel. Para abordar esta complejidad, se ha implementado una solución basada en un intérprete de comandos que se estructura como un árbol y utiliza máquinas de estado.

En el proyecto de 2022 se abordó esta propuesta donde la comunicación es UDP y el dato que se envíaba es el estado del botón. Basándose en el código de ese proyecto, desarrollar una aplicación en la que el nodo trabaje como edge router. El nodo deberá procesar localmente los datos de la red 6lowpan y luego deberá enviarlos vía UDP. Adicionalmente, el nodo deberá obtener datos de alguno de los sensores embebidos periódicamente y éstos datos también deberán ser enviados vía UDP. 

La transmisión de mensajes se podrá llevar a cabo utilizando UDP o MQTT.

Material:

5. Implementación y caracterización de RPL on/off

Un proyecto en el año 2018 implementó y evaluó la estrategia de “apagar la red” en simulación utilizando un nodo z1. Se propone continuar el proyecto adaptando a un nodo que se disponga en hardware. Adicionalmente se hará la migración de ContikiMAC a TSCH. Se evaluará el ahorro en consumo energético mediante medidas de consumo energético y en particular el efecto que tiene aumentar el parámetro de RPL.

Resumen de proyecto de 2018:
Una red que utiliza el protocolo de ruteo RPL se caracteriza por el intercambio de mensajes de control entre nodos. La frecuencia de envío de estos mensajes disminuye en cuanto la red se estabiliza estableciéndose un período máximo de envío de mensajes. Se estudia en este proyecto el consumo asociado a dicho intercambio.
También se evalúa la posibilidad de apagar la red cuando no está enviando datos (para así evitar el consumo asociado al envío de los mensajes de control), a costa de tener un consumo más elevado al momento del reinicio (debidos a la mayor frecuencia de intercambio de mensajes).
Se trabaja con el sistema operativo Contiki y con el simulador Cooja, para el estudio se suponen motes tipo Z1. Los resultados obtenidos reflejan que si bien es real que existe un incremento en el consumo al restablecerse la red, el mismo no es significativo y que a excepción de casos particulares, siempre es conveniente apagar la red cuando está en desuso.

Material:

6. Aplicación con plataforma sensortag (CC1350 o CC2650)

Resumen: Desarrollo de una aplicación que utilice uno o varios de los sensores incluidos en el sensortag de texas instruments (con la misma familia de microcontrolador que la utilizada durante el curso). Puede incluir la caracterización del consumo en hardware utilizando la herramienta Otii Arc.

Motivación: El sensor tag soporta 10 sensores de bajo consumo: ambient light, digital microphone, magnetic sensor, humidity, pressure, accelerometer, gyroscope, magnetometer, object temperature and ambient temperature.

Material:

7. Exploración de nueva plataforma: nrf52840 (Nordic)

Resumen: Explorar el uso de Contiki-NG en una nueva plataforma (nrf52850) y desarrollar una aplicación de redes de sensores inalámbricos en dicha plataforma. Caracterizar el consumo utilizando el equipo Otii Arc y contrastarlo con el consumo teórico basado en la utilización de herramientas como Energest y PowerTracker, así como con el consumo de las plataformas utilizadas durante el curso (CC1350/CC2650).

Material:

8. Contiki-NG en Arduino Nano 33 BLE Sense

Resumen: Desarrollar el código necesario para incorporar una tarjeta de desarrollo Arduino a las plataformas soportadas por Contiki-NG, considerando que el microcontrolador de la Arduino Nano 33 BLE Sense (NRF52840) ya fue portado y se encuentra soportado por Contiki-NG para usar con tecnología IEEE 802.15.4.

Motivación: Explorar más internamente el código fuente de Contiki-NG, familiarizarse con las definiciones de plataformas y agregar una nueva de carácter particularmente interesante por su popularidad entre hobbistas.

Material:

9. IPv6 over Bluetooth low energy (BLE)... with contiki-ng!

Resumen: Explorar la utilización del stack IPv6-over-BLE (BLEach) en una de las plataformas utilizadas durante el curso, y desarrollar una aplicación de redes de sensores inalámbricos. Caracterizar el consumo utilizando el equipo Otii Arc y contrastarlo con el consumo teórico basado en la utilización de herramientas como Energest y PowerTracker, así como con el que se obtiene al utilizar IEEE 802.15.4 (tecnología utilizada durante el curso).

Motivación: Se trata de un protocolo de comunicación con características similares a IEEE 802.15.4 pero más difundido (al estar incorporado, por ejemplo, en dispositivos móviles). 

Material:

10. Exploración de nueva plataforma: Gecko (Silicon Labs)

Resumen: Explorar el uso de Contiki-NG en una nueva plataforma (erf32) y desarrollar una aplicación de redes de sensores inalámbricos en dicha plataforma. Caracterizar el consumo utilizando el equipo Otii Arc y contrastarlo con el consumo teórico basado en la utilización de herramientas como Energest y PowerTracker, así como con el consumo de las plataformas utilizadas durante el curso (CC1350/CC2650).

Material:

11. Seguridad en Contiki-NG

Estudiar y evaluar una o varias opciones de seguridad disponibles en Contiki-NG.

Material:



Última modificación: jueves, 19 de octubre de 2023, 21:30