Infraestructura IoT con IDM

IDM es un protocolo de red virtual que hace posible la comunicación extremo a extremo de dispositivos conectados a cualquier tipo de red. Esencialmente resuelve el mismo problema que IP (extrapolable a IPv6), es decir, interconectar redes heterogéneas.

[The is an English version of this article]

Pero hay varios motivos por los que IP no es una solución directamente aplicable para IoT, y de ahí que se estén proponiendo alternativas. Aunque IP es un protocolo sencillo, solo resuelve una parte del problema: lleva el mensaje hasta el nodo. Por tanto, suele ser necesaria la pila TCP/IP completa, que entraña una complejidad nada desdeñable, sobre todo si tenemos en cuenta que es deseable que los dispositivos IoT sean pequeños, baratos y de muy bajo consumo. Por otra parte, hay y habrá muchas redes que utilicen protocolos de red propietarios que fueron diseñados para un propósito específico (control industrial por ejemplo) y que no son directamente integrables con IP.

Varias de las propuestas necesitan de una pila compleja o resuelven solo parte del problema. Desde nuestro punto de vista, un protocolo IoT debe permitir construir una inter-red de dispositivos de tecnología arbitraría que se puedan comunicar directa y simétricamente con cualquier otro, sin transformaciones y sin intermediarios/delegados. Sin embargo, muchas soluciones IoT se basan enviar lecturas procedentes de sensores hacia repositorios de datos en la nube y después, las aplicaciones acceden a esos repositorios, de modo que no hay comunicación directa entre el origen de la información y el destinatario que la necesita. En el caso de sensores que capturan información, el uso del repositorio aumenta la latencia y obliga a las aplicaciones a usar un modelo pull, o añadir un sistema adicional de notificación, con los consiguientes problemas de escalabilidad. En el caso de actuadores, la solución resulta claramente inadecuada, y se opta por pasarelas de aplicación, con el alto nivel de acoplamiento que ello implica..

Esta charla de Vinton Cerf ilustra algunos aspectos clave de la cuestión: Vinton Cerf: El futuro de Internet, retos y oportunidades

IDM utiliza los protocolos disponibles en cada red y proporcionados por cada fabricante. Es una propuesta cross-layer, es decir, puede prescindir de algunas capas de la pila si no nos necesarias. Es un protocolo que se puede encapsular sobre cualquier tecnología de enlace, red o transporte capaz de transportar mensajes o paquetes entre 2 puntos.

Asumimos que todo dispositivo final (sensor o actuador) proporciona una interfaz (un conjunto de operaciones bien definido). El objetivo de IDM es transportar los mensajes que invocan esas operaciones desde un cliente a uno de esos dispositivos. Llamamos objetos a estos dispositivos individuales, en parte porque la implementación actual está basada en un middleware orientado a objetos (ZeroC Ice), aunque en realidad se puede considerar más cercano a SOA que a OO.

IDM significa Inter-Domain Messaging, precisamente porque el objetivo es transmitir mensajes entre dominios con tecnologías de red, a priori, incompatibles. Esto se logra mediante routers IDM.

La denominación dominio se debe a que en la infraestructura IDM todos los dispositivos que comparten una tecnología y esquema de direccionamiento son vistos como una única entidad (un dominio). Así, toda la Internet pública es un único dominio IDM.

El router no modifica en absoluto los mensajes que reenvía. Así por ejemplo, puede recibir un mensaje de un dispositivo RS485 en una de sus interfaces y reenviarlo a un dispositivo en una red Bluetooth. Este es un punto clave, el router IDM no tiene estado, no crea delegados o proxies de los dispositivos, no transforma direcciones, únicamente reenvía mensajes completos entre sus interfaces.

Esto es posible porque el mensaje IDM permanece inalterado desde su creación en el cliente hasta su llegada al objeto. Los routers IDM solo cambian su encapsulación, de forma análoga a un router IP. Obviamente el router necesita disponer de una interfaz en cada uno de los dominios que interconecta, pero los detalles concretos de la tecnología de esa red son invisibles para el resto. A diferencia de un protocolo de red convencional como IPv6, las direcciones de IDM se refieren a los objetos en lugar de a los nodos (un nodo puede albergar varios objetos). Estas dos características permiten que el mensaje IDM se pueda encapsular incluso sobre el protocolo de enlace propio de la LAN, prescindiendo del protocolo de red «local».

Infraestructura del demostrador

Aunque IDM pretende resolver también otros problemas, en este demostrador nos hemos centrado en poner de manifiesto su capacidad de «homogeneización», es decir, poder considerar a todos los objetos IoT como virtualmente iguales, aunque sus comunicaciones y arquitectura sean diferentes.

El demostrador está formado por 5 dominios:

• RS: 3 nodos Moth Rs485
• ZB: 3 nodos Moth ZigBee (Arduino FIO + XBee).
• WF: 3 nodos Moth WiFi y 1 sonoff (ESP8266).
• ITSI-office: 5 nodos sonoff (ESP8266).
• Internet pública (solo para comunicaciones).
• Nube Node-RED (ver más adelante).

Los tres primeros se encuentran en el laboratorio ARCO y el cuarto en el ITSI.

Los nodos Moth son prototipos propios. Aunque tienen diferente controlador, todos cuentan con los siguientes sensores/actuadores:

• Relé para controlar una carga de potencia.
• LEDs rojo, verde y amarillo
• Sensor de movimiento PIR
• Sensor de luz LDR
• Sensor de temperatura
• Micrófono

Cada dominio tiene un router IDM independiente. Los routers IDM de los dominios ZB, RS e ITSI-office se ejecutan sobre Raspberry Pi, el de la red WF en un PC convencional.

En la siguiente figura se muestra la topología lógica del conjunto:

Clientes y objetos

Tanto los sensores como los actuadores pueden actuar como clientes (envían invocaciones).

• Los sensores invocan a un receptor designado cuando su estado cambia (el valor que leen).
• Los actuadores también pueden invocar a un tercero cuando su estado cambia como consecuencia de una invocación recibida.

También sensores y actuadores actúan como objetos (reciben invocaciones). Todos exponen un interfaz que permite configurar la dirección IDM del objeto que recibirá sus cambios de estado.

Encaminamiento

Los routers IDM realizan un proceso de reenvío de mensajes basado en el direccionamiento jerárquico de IDM, de modo similar a como trabaja un router IP. Sin embargo, su gestión obedece a un enfoque SDN fuertemente inspirado en OpenFlow. Los routers IDM son también objetos IDM que exponen una interfaz de gestión. El Controlador IDM es el encargado de implementar el esquema de encaminamiento introduciendo descripciones de flujo (flows) en los routers.

Las direcciones IDM son de tamaño flexible, pueden tener desde 16 a 128 bits. De ese modo, en un infraestructura con pocos objetos los mensajes pueden ahorrar unos valiosos bytes, algo muy conveniente cuando se utilizan protocolos con MTU pequeñas. Internamente, los routers utilizan siempre direcciones de 128 bits. Las direcciones más cortas se rellenan con ceros por la izquierda.

Un flujo está compuesto por un predicado y una o varias acciones. Cuando el predicado se cumple, el router ejecuta las acciones. Un flujo de reenvío es sencillo: si el mensaje entrante va dirigido a una dirección que corresponde con el prefijo del predicado, se ejecuta la acción, que implica reenviar el mensaje a la dirección indicada.

Esta forma de gestionar los routers es tremendamente flexible y simplifica en muchos casos su implementación. Como parte de este protocolo de gestión, los routers pueden descartar determinados mensajes (como haría un firewall), informar al conmutador cuando llega un mensaje que no corresponde con ninguna regla, asignar un tiempo de vida a las reglas, registrar errores o estadísticas, etc.

La siguiente figura es una captura de la interfaz gráfica del Controlador IDM, que permite editar de forma visual los flujos de los encaminadores.

Integración homogénea

Una vez realizado el despliegue, cualquier objeto puede invocar a cualquier otro conociendo únicamente su dirección IDM. Como se ha indicado, para disponer de total flexibilidad, es posible indicar a cualquier objeto dónde debe enviar su estado (indicando la dirección del destino).

Por ejemplo, se puede indicar al objeto que gestiona el sensor PIR del Moth ZB1 (dirección 10:17) que envíe sus cambios de estado a uno de los LEDs del Moth RS2 (por ejemplo, al rojo, dirección 12:22). Cuando el PIR en cuestión detecte movimiento el LED se encenderá, demostrando que la invocación fue generada por un dispositivo conectado a una red ZigBee, atravesó una red TCP/IP y llegó a un dispositivo conectado a una red RS485.

Por supuesto, es posible implementar objetos en un PC convencional, un smartphone o cualquier otra plataforma de cómputo imaginable con capacidad de comunicación. En todos los casos, la comunicación extremo a extremo funciona exactamente del mismo modo.

Hemos creado incluso componentes Node-RED que permiten la configuración visual de los receptores de eventos. Además, es posible crear objetos y clientes virtuales que «viven» en el servidor Node-RED, y por tanto constituyen un nuevo dominio IDM conectado a la infraestructura.

En la figura anterior aparecen 3 flujos Node-RED, su significado es el siguiente:

• El primero representa la configuración del objeto con dirección 10:17 (el PIR de la Moth ZB1 en el dominio ZigBee) para que envíe sus notificaciones de cambio de estado al objeto 12:22 (el LED rojo de la Moth RS2, en el dominio RS485).
• El segundo flujo implica la creación de un objeto virtual con dirección DD:12, que queda registrado en el router IDM local y que puede ser invocado desde cualquier punto de la inter-red IDM. Cuando recibe una invocación, Node-RED imprimirá su valor en la salida de registro en pantalla.
• El tercer flujo se puede utilizar para enviar invocaciones a ese mismo objeto (DD:12) con un valor booleado). Del mismo modo, podría enviar invocaciones a cualquier otro objeto (real o virtual) en cualquier parte, sin más que indicar su dirección.