Entrevista con Inés Robles sobre las actividades del grupo ROLL de IETF

Inés Robles se encuentra actualmente realizando un PhD en Internet of Things. Ella trabaja como investigadora en Ericsson Finlandia y es co-chair del grupo de trabajo ROLL (Routing over Low Power and Lossy Networks) de la IETF.

¿De qué se ocupa el Grupo de Trabajo “Roll”? (Roll: Routing Over Low power and Lossy networks)

En el IETF hay un grupo de trabajo que se llama ROLL (Ruteo sobre redes con restricciones y con pérdidas). Se creó para organizar el ruteo en este tipo de redes con restricciones de recursos, es decir, dispositivos con poca memoria, con bajo poder de procesamiento, y a la vez redes con pérdidas. La IETF dijo “bueno, necesitamos un algoritmo de ruteo para estos tipos de redes; vamos a analizar los protocolos que ya existen, y vamos a ver cuál de todos ellos se adapta a estos tipos de redes con pérdidas y que van a ser utilizados con dispositivos con pocos recursos”. Entonces hicieron un estudio (https://tools.ietf.org/html/draft-ietf-roll-protocols-survey-07)), y analizaron protocolos de ruteo solamente pertenecientes al IETF, y llegaron a la conclusión de que ninguno de ellos se adaptaba 100% a este tipo de redes. Entonces decidieron armar un nuevo protocolo que se llama RPL.

¿Qué aplicaciones de capas superiores podría mencionar?

Todo lo que es IoT, nosotros podemos decir que se refiere a conectividad. Por ejemplo, podemos hacer a través de RPL - que es el protocolo de ruteo- la conectividad entre dispositivos, capa física, capas de Mac Layer. Ahora, para las capas superiores, IETF también desarrolló CoAp que es el protocolo de capa de aplicación, y ahora están trabajando en conjunto en el IETF con el W3C que es la organización de estándares que desarrolló protocolos web. Hicieron un grupo que se llama Web Of Things, cuyo objetivo es armar la capa de aplicación de IoT. O sea, IoT connectivity sería todo lo que es ruteo, Mac y capas físicas, y Web of Things sería la capa de aplicación para IoT. Entonces, el objetivo de la organización de estándares no es crear un nuevo estándar sino, con los ya existentes, lograr interoperabilidad, realizar las capas o los protocolos necesarios para poder, con los protocolos que ya existen, coordinarse y poder llevar los objetos a la web. Por ejemplo, que yo pueda acceder a mi dispositivo desde un browser.

¿Cuáles son los principales componentes de WoT?

La W3C desarrolló unos componentes que denominó building blogs, y básicamente son un protocol building template, como una capa que me permite determinar qué protocolo de comunicación voy a utilizar (ya sea HTTP o CoAp). Yo como puedo conectar mis dispositivos a cualquier otro dispositivo, porque yo quiero lograr interoperabilidad, tengo que poder elegir qué protocolo de capa de aplicación quiero para mi dispositivo que se conecte via web.

Esa es una capa, arriba de eso tiene lo que se llama Interaction model, que es un modelo que me determina a más alto nivel, qué interacción puedo tener entre dispositivos.

Este interaction model viene acompañando de lo que se llama Thing Description, que vendría a ser la descripción de un objeto. Después tenemos un Runtime Environment, cuyo objetivo es que yo pueda correr aplicaciones independientes. Yo escribo un programa, y lo quiero correr en todos los dispositivos. Yo necesito correr ese application script en un ambiente en que todos los dispositivos tengan el runtime environment, y que tiene que tener las interfaces – las API- definidas por el standard. Y el beneficio que tengo es que yo escribo el programa una vez y lo puedo correr en todos los dispositivos. Puedo instalar este script, este programa que yo haga, en la cafetera, en el televisor, porque todos estos dispositivos van a tener el runtime environment. Y a raíz de esto también voy a utilizar un scripting API que me va a dar las herramientas para que el programa que yo escriba pueda interactuar también con los otros.

¿Qué es un “Servient”?

Servient es una entidad que han definido en W3C, que es una entidad que mezcla la funcionalidad de servidor y de cliente. O sea, un dispositivo puede ser a la misma vez servidor y cliente.

¿Cuáles son los escenarios propuestos para el desarrollo de WoT?

El standard tiene un montón de casos de uso, pero obviamente englobó algunos patrones de diseño de comunicación que serían: Web of Things Client; correr el Servient en el dispositivo en sí mismo, correr el Servient en el Smartphone: correr el Servient en un gateway; correr el Servient en cloud y en el gateway y finalmente correr el Servient en el cloud server.

En el primer caso (Web of Thing client), yo tendría una entidad – el Servient- con todos los bloques y se conectaría al dispositivo en sí (por ejemplo, a una lamparita). Entonces el servient, que por ejemplo sería un browser, va a tener un Protocol Building Layer que me va a determinar qué protocolo voy a utilizar para transferencia web. Arriba de eso voy a tener un web of things runtime environment que correspondería al browser, y después voy a tener los scrpting API que me permite correr las aplicaciones. Y a la vez, este Servient tiene que decir “bueno, me voy a contactar con la lamparita y necesito saber cómo me puedo conectar con ella”. Entonces lo que hace es localizar el thing Description. El thing description es una estructura de datos – que también está definido por el estándar – que lo que me da es información del dispositivo, me da Meta Data. Me dice qué dispositivo es, me da el contexto (qué semántica describe el dispositivo), qué operaciones puedo hacer con el dispositivo, qué serialización puedo utilizar, qué recursos puedo utilizar, y también me va a indicar la meta data de comunicación. Esa meta data de comunicación la va a utilizar el protocol building layer, y todo lo demás lo va a utilizar el application script.

El W3C también definió en el thing description la interacción a través de 3 patrones: propiedad, acciones y eventos. Entonces yo puedo interactuar con el dispositivo a través de propiedades, acciones y eventos (también eso está incluido en la estructura de datos). La propiedad es un recurso del dispositivo, yo puedo acceder a través de una URI, puedo acceder a los recursos del dispositivo: quiero leer la temperatura, quiero ver la humedad, etc. Puedo también invocar acciones, procesos. Y después puedo suscribirme a eventos, por ejemplo, cuando llega a la temperatura de 25 grados, me avisa. Entonces, a través de la estructura de datos de thing Description, puedo llegar a interactuar si la aplicación necesita esa información que puede estar en el dispositivo o puede estar en cualquier otro lado. Entonces, el Web of things Client sería el servient que se conecta con el dispositivo. Para conectarse utiliza el thing description para saber la meta data del dispositivo y también saber la meta data de comunicación, de qué protocolo va a utilizarse.

Ese sería el primer caso, los demás serían similares salvo que el servient está en diferentes contextos. En el segundo caso el servient está en el dispositivo en sí (la lamparita tiene la propiedad de servient). En el tercer caso el servient está en el Smartphone, tengo un dispositivo que no tiene los suficientes recursos para alojar el servient (en mi Smartphone pongo el stack de servient, el Smartphone se comunica con el dispositivo y el browser se comunica con el servient del mismo Smartphone).

El otro caso sería cuando el servient está en el gateway, el cual, además de cumplir las funcionalidades de gateway, actúa también como servient. Entonces el browser se va a conectar con el gateway, y el gateway se va a conectar con el dispositivo (el browser y el gateway van a tener el mismo stack).

Cuando el servient está en el cloud y en el gateway, básicamente lo que hace es mirror. Por ejemplo, cuando tengo mi red local en mi casa, puedo acceder a través del gateway al dispositivo. En el gateway tengo el servient para acceder localmente. Pero cuando estoy afuera de mi casa y por un requerimiento de seguridad no accedo al gateway, accedo a través cloud. Entonces el cloud va a hacer un mirror de lo que tiene el gateway. Entonces el browser va a acceder al cloud, el cloud se va a conectar con el gateway, y el gateway se va a conectar con el dispositivo.

Y el último caso es cuando el servient está en el cloud directamente. Entonces en este caso yo tengo mi gateway en legacy device (que no tiene el stack de servient), y lo que hace el browser es conectarse con el cloud, y el cloud se conecta directamente con el gateway, y ahí el gateway le pasa la información del dispositivo.

¿Qué ejemplos de la vida real puedes darme? ¿En qué se usa WoT?

Por ejemplo, si yo quiero desde el browser manejar una lamparita, manejar el aire acondicionado, prender la cafetera. Sin importar la marca o el fabricante.

¿Esa es la verdadera ventaja del WoT? ¿Que lo trabajo a partir de un browser independiente de lo que esté administrando?

Mientras yo tenga el ambiente (runtime environment), sí. Porque el protocol building layer me decide qué protocolo de transporte puedo utilizar. No importa cómo esté implementado, yo tengo que poder conectarme con mi dispositivo. Ese es el objetivo: la interoperabilidad. Si yo tengo esta lamparita que es General Electric, esta computadora, etc, y quiero conectarme, puedo. Mientras obviamente tenga el estándar del W3C.

¿Hay algo que ya esté funcionando de esta manera?

Está todo en prototipos todavía. Se han hecho como eventos de Hackathon para probar, pero todavía el estándar está en borrador. Sí hay una lista pública que uno puede comentar, es decir, los drafts están libres en Internet, uno lo puede leer y comentar en la lista pública.

¿WoT está pensado para grandes volúmenes o para objetos de la vida cotidiana?

Para ambos. Los ejemplos que presentan tratan de investigar “Smart home”, que es la aplicación directa. Pero también tienen en cuenta que en la parte industrial es muy necesario poder tener la interoperabilidad entre estándares.

¿Qué tan lejos se está de poder sacar esos dos estándares?

No creo que esté tan lejos porque están trabajando bastante fuerte en WoT. Y desde el año pasado se ha avanzado bastante y se han definido los casos de uso. Además, la comunidad está presente permanentemente, porque es abierto, la comunidad puede opinar, se hacen hackathons, está el código abierto.