En artículos anteriores hemos explicado la base del nuevo protocolo de Internet y el hecho de que la Internet6 está creciendo rápidamente, en paralelo a la red actual. En esta nueva entrega, os explicamos de forma didáctica cómo IPv6 está llamado a convertirse en una parte esencial del paradigma de la “WEB de las cosas”.

Seguramente has escuchado en numerosas ocasiones los términos M2M (Machine-to-Machine) e IoT (Internet-of-Things o Internet de las cosas). La Internet de las Cosas supone conectar a la red millones de nuevos dispositivos autónomos. El concepto abarca, desde sencillos sensores o actuadores para manejar electrodomésticos, hasta complejas infraestructuras públicas de alumbrado o sistemas industriales, pasando por coches y casas inteligentes.

De la “Internet de las cosas” a la “WEB de las cosas”

Si analizamos detenidamente muchas de las soluciones IoT existentes actualmente, concluiremos que, en sentido estricto, los dispositivos no son realmente parte de Internet. Por ejemplo, no tienen dirección IP.
Además, los servicios WEB no se ofrecen desde los mismos dispositivos, sino desde pasarelas intermedias (gateways) o plataformas. Estas últimas son las que realmente están presentes en Internet y ofrecen los servicios a los usuarios.
Por último, al no ser la comunicación entre los dispositivos y las pasarelas un estándar de Internet, han proliferado los protocolos y soluciones propietarias. En muchos casos, están protegidos por patentes y suponen en definitiva el pago royalties para el desarrollo de nuevas implementaciones. La siguiente figura muestra la alternativa que describimos en este artículo.

Conexión de dispositivos 6LowPAN a Internet a través de Gateway pero con conectividad extremo a extremo utilizando IPv6

En dispositivos de cierta entidad y alimentados mediante red eléctrica es posible utilizar TCP/IP sobre redes WiFi o 3G, y que el dispositivo implemente los conocidos servicios WEB de tipo REST para su manejo.
Sin embargo, uno de los retos a los que nos enfrentamos en la comunicación de los dispositivos es que, en muchas ocasiones, se trata de pequeños sensores alimentados por baterías y enlazados con pasarelas más potentes a través de redes radio de baja potencia (redes WSN o LowPAN).
Estas redes radio tienen mayor probabilidad de pérdida de mensajes y para su funcionamiento óptimo precisan que los mensajes sean lo más cortos posibles.
Como consecuencia, el uso de HTTP-REST sobre TCP/IP resulta ineficiente y desaconsejable en estos entornos.
No obstante, como veremos a continuación, las mejoras en la integración de componentes, consumo de energía y nuevos estándares ha evitado finalmente que abandonemos la idea que todos los dispositivos, incluyendo pequeños sensores a pilas, tengan dirección IP y ofrezcan sus propios servicios en la nueva WEB. Obviamente, para que haya direcciones suficientes no sirve IPv4, tiene que ser IPv6.
Así, recientemente, el IETF (Internet Engineering Task Force, la organización de estándares de protocolos de Internet) ha definido una alternativa en forma de estándar para que estos dispositivos estén realmente conectados a Internet, más concretamente a la Internet6. Se conoce con el nombre de “6LowPAN”,  el IPv6 de las redes LowPAN (Low Power Area Networks).


Pila de protocolos utilizada por sensores 6LowPAN


La principal diferencia con el modelo anterior es que los dispositivos son nodos de Internet de pleno derecho, es decir, tienen dirección IPv6 y cuentan a priori con conectividad extremo a extremo con cualquier otro nodo en la Internet6.
Además, estos nodos finales (los dispositivos) son los que ofrecen directamente los servicios WEB (medidas o comandos con estándares SensorML, XML, JSON, etc.). Por este motivo, se dice que 6LowPAN abre el paradigma de la “WEB de las cosas” (WoT, Web of Things) o “Internet of Embedded Systems”.
En cualquier caso, como veremos en el siguiente apartado, no se emplea el esquema tradicional de servicios REST sobre HTTP/TCP, sino el nuevo estándar CoAP/UDP, extendiendo notablemente el paradigma de la WEB actual.
En la figura anterior podemos ver que también se necesita una pasarela a la Internet IPv6. Sin embargo, se trata simplemente de un encaminador (router) que comprime y expande las cabeceras, siguiendo el estándar 6LowPAN. Debido a esto, estas redes y dispositivos son una parte más de la Internet6.
Además, se trata de tecnologías totalmente abiertas que cualquiera puede implementar sin infringir patentes o asumir costes de propiedad intelectual.
Finalmente, aunque los dispositivos tengan toda la inteligencia para ofrecer servicios básicos en Internet, esto no quiere decir que no construyamos plataformas que nos permitan su gestión y la provisión de servicios más complejos. En lo que se refiere a las plataformas, la principal ventaja es que evitamos protocolos y pasarelas propietarias que introducen retardos, limitaciones y costes.

¿Cuál es la arquitectura de esta“Web de las cosas” en Internet6?

6LowPAN se ha definido para trabajar sobre el estándar de redes radio IEEE 802.15.4. Este estándar permite topologías malladas (“Meshed networks”) inalámbricas. De esa manera, unos nodos pueden hacer uso de otros como repetidores o routers de sus mensajes para garantizar siempre la cobertura, y el envío y recepción de mensajes.
En lo que respecta a la capa de servicios, lo lógico sería utilizar el omnipresente modelo de servicios REST, dado que existen muchas implementaciones, herramientas y experiencia por parte de los desarrolladores. Sin embargo, utilizar HTTP-REST en redes LowPAN presenta muchos inconvenientes, debido a que se emplea como transporte el protocolo TCP.
El problema de TCP es que es un protocolo orientado a conexión y por tanto necesita mensajes de establecimiento y terminación (Three-wayhandshake). Además, al ser un protocolo de transporte fiable, realiza retransmisiones siempre que se pierde cualquiera de los datagramas en los que se ha divido la información que se va a transmitir.
Por este motivo, el IETF ha definido CoAP, una nueva capa de servicio para entornos restringidos que conserva el modelo REST, pero utiliza UDP como capa de transporte.


CoAP es una nueva capa de servicio para entornos restringidos que conserva el modelo REST, pero utiliza UDP como capa de transp


CoAP presenta una API idéntica a REST-http, es decir, el conjunto de operaciones CRUD (Create, Read, Update y Delete), pero el transporte se realiza sobre el protocolo UDP, no orientado a conexión y no fiable.CoAP permite dos tipos de mensajes: confirmados y no confirmados.
Los mensajes confirmados suponen una aceptación por parte del receptor (ACK), de tal manera que, si se pierden, se retransmiten un número limitado de veces. Los mensajes no confirmados se pueden emplear para aquellos casos en que es preferible perder la información periódica de algunos sensores, antes que saturar la red con retransmisiones, algo que no es posible con el modelo REST-HTTP.
Con todo lo anterior hemos descrito la arquitectura completa de la “Web de las Cosas” para redes radio con topología mallada:
  • IEEE802.15.4, para el nivel radio (capa física y de enlace, niveles 1 y 2 OSI).
  • 6LowPAN, para el nivel de red (capa de red, nivel 3 OSI).
  • UDP: para el nivel de transporte.
  • CoAP: que ofrece una API REST y capacidades de reenvío para mensajes confirmados.
Los dispositivos pueden emplear sobre CoAP cualquier estándar empleado en la actualidad, como SensorML u otras variantes basadas en XML o JSON.

¿Existen prototipos o kits de prueba?

La arquitectura descrita anteriormente ha pasado a formar parte de los estándares promovidos por ETSI M2M, de tal manera que han aparecido múltiples implementaciones, que se han probado en los test de interoperabilidad de ese organismo de estándares.
Además de desarrollos propietarios por parte de empresas comerciales, existen ya dos sistemas operativos libres, Contiki y TinyOS, para sistemas embebidos que implementan la pila 6LowPAN y la capa de servicios CoAP.
Gracias a estos sistemas operativos libres y al hardware abierto, se pueden desarrollar dispositivos con esta arquitectura a precios muy asequibles, en el marco de proyectos o prototipos DIY (“Do-It-Yourself”).
En lo que se refiere a hardware abierto, existen placas de propósito general, como Arduino o Zigduino (que incorpora de serie el chipset radio), o bien módulos o “motas” orientadas al prototipado de sensores y actuadores.
En la siguiente foto se muestra un módulo de hardware abierto adquirido recientemente para hacer pruebas con 6LowPAN y CoAP, gracias al sistema operativo Contiki.


Módulo de hardware abierto para pruebas 6LowPAN y CoAP, con sistema operativo Contiki


Los usuarios y plataformas que acceden a estos servicios, se pueden hacerlo mediante el tradicional REST-HTTP (CoAP se diseñó para que los proxies entre ambos protocolos sean sencillos y eficientes) o bien implementando CoAP en la plataforma o cliente. Esto último resulta también muy sencillo puesto que ya hay librerías de CoAP para C, C++, Java y Python.


¿Se está posicionando la industria con implementaciones?

Un ejemplo relevante es la bombilla controlable mediante smartphones Android anunciada por Google. Esta solución emplea tecnología 6LowPAN. En el siguiente diagrama se incluye un esquema de referencia de una bombilla similar publicado por el fabricante JennetIP.


Esquema de referencia de una bombilla similar a la bombilla controlable mediante smartphones Android de Google que emplea tecnología 6LowPAN


Otro conocido ejemplo es la bodega de vinos inteligente de Vinton Cerf (considerado padre de Internet) presentada en el CES de Las Vegas este mismo año y que se basa en dispositivos 6LowPAN.

¿Dispositivos con dirección IP? ¿Será caro? ¿Será ineficiente?

Muchas veces nos hacen esta pregunta. En realidad, la electrónica y el software han alcanzado cotas mucho mayores en las escalas de integración, consumo de potencia y precios. Un ejemplo claro son los smartphone.
En la actualidad hemos podido probar dispositivos conla arquitectura descrita anteriormente (motas 6LowPAN) y que funcionan con dos baterías AA de 1,5V durante algo más de un año.
Por otro lado, CoAP/6LowPAN ofrece una gran optimización en cuanto a número total de información (bytes) transmitida y el tiempo de transmisión, lo que redunda también en una mayor duración de las baterías.
Para concluir, el siguiente diagrama muestra una comparativa de la transmisión de un mensaje de un sensor en una red LowPAN sobre CoAP/UDP y sobre REST-HTTP.



Comparativa de la transmisión de un mensaje de un sensor en una red LowPAN sobre CoAP-UDP y sobre REST-HTTP