Diseño de aplicaciones inteligentes con Bluetooth de bajo consumo con Bluetooth Mesh: Parte 2

Nota del editor: La Parte 1 de esta serie de dos partes detalla la arquitectura y las capacidades del protocolo de Bluetooth Mesh 1.0. Aquí, la Parte 2 describe cómo integrar Bluetooth Mesh en diseños Bluetooth de bajo consumo mediante chips y kits de desarrollo.

Bluetooth Mesh provee las ventajas notables de la conexión en red al popular protocolo de corto alcance. Estas ventajas se desarrollaron en detalle en la Parte 1. Sin embargo, la especificación también trae nuevos desafíos de diseño, en particular cuando se trata de implementar los modelos.

La clave para superar estos desafíos es aprovechar las herramientas de desarrollo actualizadas para obtener una mayor familiaridad con Bluetooth Mesh. Este artículo describe cómo utilizar una selección de hardware y software de Bluetooth, kits de desarrollo (DK) y kits de desarrollo de software (SDK) para configurar y crear aplicaciones de Bluetooth Mesh.

Herramientas de desarrollo de Bluetooth Mesh

La pila de Bluetooth Mesh consta de una capa de host nueva en su totalidad que comparte algunos conceptos con la capa de host de Bluetooth de bajo consumo (BLE), pero que no es compatible con esta. Las primeras versiones de la pila de Bluetooth Mesh ahora están disponibles para el desarrollo de ingeniería, en general como parte de un SDK.

Debido a que Bluetooth Mesh es una especificación complementaria de la Especificación Core de Bluetooth, no es necesario que los proveedores actualicen las capas físicas (PHY) de Bluetooth de bajo consumo (BLE) o las pilas de software para admitirlo. Sin embargo, agregar Bluetooth Mesh requiere que los proveedores presenten sus propias implementaciones de la pila para los clientes.

Por ejemplo, el proveedor de BLE Nordic Semiconductor ha presentado el SDK nRF5 para Mesh. El kit incluye una pila de Bluetooth Mesh, selección de controladores, bibliotecas y ejemplos para aplicaciones de Mesh. El SDK opera en varios entornos completos de desarrollo integrado (IDE) y compiladores que incluyen SEGGER Embedded Studio de Segger Microcontroller Systems y CMake.

Debido a que Bluetooth Mesh es compatible con todas las versiones de BLE (es decir: la 4.0, 4.1, 4.2 y 5), el SDK de Mesh de Nordic con el tiempo funcionará con todos los chips BLE. La versión actual, sin embargo, solo funciona con las últimas soluciones BLE de la serie nRF52 de la compañía, como el chip nRF52832 de rango medio compatible con Bluetooth 5.

Debido a que no hay ningún cambio en la PHY de BLE o la pila de software, el trabajo de desarrollo de Bluetooth Mesh se puede realizar en un DK existente que incorpore el dispositivo de destino. El DK recomendado para el nRF52832 es el DK nRF52 (Figura 1).

Figura 1: El SDK de Mesh de Nordic Semiconductor funcionará con el DK nRF52 que incorpora un dispositivo de destino de sistema en chip (SoC) nRF52832. (Fuente de la imagen: Nordic Semiconductor)

El desarrollo en malla (mesh) exige al menos tres (y se prefiere más) dispositivos para comunicarse y simular un entorno de malla. Se podrían emplear, de manera ideal, varios DK para representar los nodos en una malla, pero esto tiene el inconveniente de aumentar en gran medida los costos del desarrollo de hardware. Un enfoque alternativo es usar un DK y comprar módulos BLE comprobados y verificados (basados en el dispositivo de destino) para formar los nodos adicionales. Para el desarrollo con el nRF52832 de Nordic, el BMD-300 de Rigado o el BL652-SA-01-T/R de Laird son buenas opciones de módulos.

Cypress Semiconductor ha adoptado un enfoque similar a Nordic. La empresa ofrece el SDK de Bluetooth Mesh para el DK BCM92073X WICED Smart que está basado en el BCM20736S de PHY de Bluetooth v4.1 de Cypress. Los módulos BLE adecuados para el trabajo de desarrollo de malla basado en esta PHY incluyen el ISM20736S de Inventek.

Entender los modelos

El hardware, el software y las herramientas de desarrollo de Nordic y Cypress vienen completos con ejemplos y tutoriales para guiar a los desarrolladores con los pasos para construir una simple aplicación de Bluetooth Mesh. Pero antes de embarcarse en un primer diseño, ayudan a ejecutar los tutoriales asociados para comprender las características únicas de la arquitectura de Bluetooth Mesh, ya que tiene una gran influencia en el proceso de diseño.

Dichos tutoriales destacan que, si bien los nodos de Bluetooth Mesh vienen en cuatro tipos genéricos (consulte la Parte 1 de esta serie de artículos de dos partes), las capacidades de cada uno están determinadas por el/los modelo(s). Entender los modelos es la clave para aprovechar al máximo las capacidades de Bluetooth Mesh.

Bluetooth Mesh ofrece la flexibilidad necesaria para crear aplicaciones de malla novedosas, ya que los desarrolladores pueden construir modelos que habilitarán dispositivos con muchos comportamientos personalizados. Un modelo define los estados requeridos, los mensajes que actúan sobre esos estados y el comportamiento asociado. Todas las comunicaciones a través de una red de malla son facilitadas por mensajes.

Un estado es un valor que representa una condición de un elemento. Un elemento es una entidad direccionable de un dispositivo o nodo. Cada dispositivo tiene al menos un elemento (primario) y puede tener uno o más elementos secundarios. El número y la estructura de los elementos no cambia a lo largo de la vida del nodo. Un elemento que “expone” un estado se llama servidor. A un elemento que “accede” a un estado se lo conoce como cliente.

Es importante destacar que los modelos son de tres tipos: servidor, cliente y control. Un modelo de servidor se compone de uno o más estados que abarcan uno o más elementos. Define un conjunto de mensajes obligatorios que puede transmitir o recibir, el comportamiento del elemento cuando transmite y recibe los mensajes, y cualquier comportamiento adicional que se produce después de que los mensajes se transmitan o reciban.

Un modelo de cliente define un conjunto de mensajes que un cliente usa para solicitar, cambiar o “consumir” los estados de servidor correspondientes, tal como se define en un modelo de servidor. El modelo de cliente no tiene estados.

Un modelo de control puede combinar la funcionalidad del modelo de cliente (para comunicarse con otros modelos de servidor) y la funcionalidad del modelo de servidor (para comunicarse con otros modelos de cliente). Un modelo de control también puede contener lógica de control: un conjunto de reglas y comportamientos que coordinan las interacciones del modelo de control entre otros modelos a los que se conecta el modelo de control (Figura 2).

Figura 2: Se muestra la estructura del modelo de elemento de un dispositivo de Bluetooth Mesh que implementa un modelo de control. El dispositivo C puede comunicarse con los modelos de servidor (dentro de los dispositivos A y B) como un cliente (mensajes X, Y y Z y mensajes R, S y T, respectivamente) y los modelos de cliente (dentro del dispositivo D) como servidor (mensajes de apoyo A, B y C). (Fuente de la imagen: Bluetooth SIG)

Para ilustrar el uso de modelos en un ejemplo práctico, considere una banda de alimentación que comprenda dos tomas de corriente independientes, cada una capaz de controlar la salida de corriente e integrando una radio BLE, que permita que la banda se conecte a Bluetooth Mesh.

El dispositivo (la regleta) cuenta con dos elementos que representan cada uno de los dos enchufes de alimentación. La funcionalidad de cada elemento está definida por el modelo de servidor de nivel de potencia genérico que define un conjunto de estados en un servidor, así como un conjunto de mensajes que opera en los estados. Se puede enviar un mensaje establecido genérico de nivel de potencia al dispositivo para controlar la potencia de salida. El mensaje está dirigido a uno de los elementos del enchufe.

Los enchufes también pueden controlarse mediante un dispositivo genérico, como un atenuador, que implementa el modelo de cliente de nivel genérico. Este modelo establece un nivel deseado en cero, un valor máximo o un valor intermedio. La alimentación a los enchufes se controla mediante un enlace de estado. En cada enchufe, el estado real genérico está vinculado al estado de nivel genérico. Un cliente de nivel genérico envía mensajes de nivel genérico al servidor de nivel genérico. El estado de nivel genérico cambia, lo que a la vez (a través del enlace definido) cambia el estado de energía genérica real que controla la salida de potencia.

Debido a que los elementos pueden informar estados, cada enchufe puede informar el nivel de potencia y el consumo de energía de un dispositivo conectado al enchufe. El consumo de energía se informa mediante mensajes definidos por el modelo de servidor de sensores.

Construcción de una red de Bluetooth Mesh

En el caso de que el desarrollador se haya familiarizado con la arquitectura de Bluetooth Mesh y el desarrollo de BLE (consulte el artículo de DigiKey: "Los SoC de BLE y las herramientas compatibles con Bluetooth 4.1, 4.2 y 5 están a la altura de los desafíos de IoT" para obtener más información sobre el diseño BLE general) y esté equipado con SDK de Bluetooth Mesh, SDK de host, DK y módulos adicionales o DK para configurar una red, el desarrollador puede configurar con cierta facilidad una implementación de Bluetooth Mesh.

El primer paso es construir la pila de malla. En el caso de Nordic, la pila se genera mediante el entorno completo de desarrollo integrado (IDE) seleccionado. Por ejemplo, con Embedded Studio de SEGGER, la pila se genera mediante el uso de uno de los ejemplos incluidos con el SDK de Bluetooth Mesh (como el "interruptor de luz") y la compilación usando el IDE.

La PHY de destino en el DK se borra y se reprograma con la pila de Bluetooth Mesh y la pila de BLE compiladas. Una vez que las pilas están programadas y verificadas, el SDK se puede usar para configurar y construir redes de malla.

Aprovisionamiento: Las herramientas de desarrollo de Nordic incluyen una interfaz de programación de aplicaciones (API) de aprovisionamiento que se utiliza para agregar nuevos dispositivos a la red en malla. El aprovisionamiento lo gestionan los aprovisionadores (dispositivos ya conectados a la red y configurados previamente para dicha tarea) y se utiliza para brindar a los nuevos dispositivos la información que necesitan para unirse a una red en malla. En un comienzo, el dispositivo se suministra con una clave de red, una dirección y una clave de dispositivo para establecer un canal seguro para la configuración después del aprovisionamiento.

La API permite que el desarrollador comience a escuchar la baliza de transmisión del nodo no aprovisionado (o aprovisionado: el dispositivo que se agregará a la red) enviada en uno de los tres canales publicitarios de BLE. Bluetooth Mesh transmite y recibe mensajes mediante los canales de publicidad de BLE, en lugar de los 37 canales de datos de ancho de banda completo. Las solicitudes de enlaces entrantes en el canal serán aceptadas automáticamente por el aprovisionador.

Cuando se establece el enlace, se autentica mediante un método fuera de banda (OOB) para garantizar que el dispositivo que se une a la red sea el objetivo deseado. El uso de métodos OOB reduce la posibilidad de ataques de "intermediario" desde dispositivos que escuchan la reasignación de espectro de BLE. Luego, un evento API facilita los datos de aprovisionamiento y la clave del dispositivo para el dispositivo.

Configuración: La aplicación de "interruptor de luz" de Nordic (incluida con el SDK) muestra cómo desarrollar aplicaciones con funciones como aprovisionador y aprovisionado. En la demostración, un modelo de cliente de interruptor de luz (el interruptor) es el aprovisionador y el modelo de servidor de interruptor de luz (el foco) es el aprovisionado.

El ejemplo de Nordic aprovecha al máximo el hecho de que el servidor más simple en la especificación de Bluetooth Mesh es un servidor encendido/apagado genérico, que muestra que el servidor está encendido o apagado. Por ejemplo, el cliente más simple es un cliente encendido/apagado genérico que puede controlar un servidor encendido/apagado genérico a través de mensajes definidos por el modelo encendido/apagado genérico.

Cuando este modelo de servidor recibe un mensaje GET o SET (confiable) de un modelo de cliente, envía el valor actual del estado encendido/apagado como respuesta. Esto mantiene al cliente actualizado sobre el estado del servidor (Figura 3).

Figura 3: Mensajes y códigos de operación ATT compatibles con el modelo genérico de encendido/apagado. (Fuente de la imagen: Nordic Semiconductor)

El servidor de configuración se utiliza para representar una configuración de red en malla de un dispositivo y es un requisito obligatorio para los nodos de Bluetooth Mesh. El servidor de configuración maneja la comunicación con la configuración del cliente y las instrucciones de esta (controlada por el aprovisionador).

La configuración comienza luego de que se complete el aprovisionamiento. El aprovisionador lee los datos de composición del aprovisionado para identificar los metadatos del dispositivo y qué modelos están vinculados a qué elemento del dispositivo. A continuación, la(s) clave(s) de aplicación y/o de red se agregan y enlazan a los diferentes modelos (Figura 4).

Figura 4: Diagrama de flujo de aprovisionamiento y configuración desde el SDK nRF5 para Mesh. Las llamadas “nrf_mesh ...” son funciones API. (Fuente de la imagen: Nordic Semiconductor)

Agregar más dispositivos a la red es simplemente repetir el proceso de configuración y aprovisionamiento para cada nuevo nodo.

Publicación y suscripción: La etapa final de configuración y creación de una aplicación inicial es configurar el estado de publicación de los modelos. Por ejemplo, la dirección utilizada para publicar eventos de estado, con esa clave, mediante el valor "Time-To-Live" (TTL) y establecer suscripciones.

Los mensajes se envían cuando se publican desde la dirección de publicación de cada modelo. La publicación es usada, por ejemplo, por un nodo sensor que informa datos de manera periódica. Los mensajes se pueden publicar solo una vez o repetir, y se envían a una difusión individual, a un grupo o a una dirección virtual (consulte la Parte 1 de este artículo). La publicación también es utilizada por los modelos de cliente para enviar mensajes a los modelos de servidor.

La configuración de los estados relacionados con la publicación por lo general está controlada por un aprovisionador a través del modelo de configuración.

Cuando se utiliza el SDK de Nordic, los mensajes se publican mediante la función API “access_model_publish()”, que notificará un mensaje de acuerdo con la configuración de publicación (intervalo, destino) del modelo de publicación.

Las suscripciones permiten a los modelos escuchar los mensajes entrantes desde direcciones específicas. Esto se puede usar para escuchar, por ejemplo, los mensajes periódicos publicados desde los nodos del sensor. El SDK de Nordic permite a los modelos suscribirse a una dirección a través de una reasignación de una lista de suscripción mediante la función API “access_model_subscription_list_alloc()”.

Tenga en cuenta que cuando se utiliza un modelo de cliente, no es necesario suscribirse a la dirección desde donde se envían los mensajes para recibir respuestas a esos mensajes. Las suscripciones solo se utilizan para recibir mensajes no solicitados de nodos.

Durante el proceso de desarrollo, puede ser ventajoso conectar un dispositivo que no esté habilitado para Bluetooth Mesh a Bluetooth Mesh. Un ejemplo podría ser un teléfono inteligente que el desarrollador desee utilizar para controlar un prototipo de aplicación de iluminación inteligente de malla. La interacción entre el móvil y la malla se logra a través de la interfaz del perfil de atributo genérico (GATT) del dispositivo del nodo y del teléfono inteligente en la pila Bluetooth, en lugar de la pila de Bluetooth Mesh.

Conclusión

Bluetooth Mesh agrega nuevas capacidades a las aplicaciones BLE. Sin embargo, debido a que no se incluyó como parte de la especificación Core original, la adopción de malla ha presentado algunos compromisos y ha agregado cierta complejidad al proceso de diseño. Los desarrolladores familiarizados con el diseño mediante la pila de protocolos de Bluetooth tendrán ventaja sobre aquellos que no tengan conocimiento, pero incluso para ingenieros experimentados, implementar Bluetooth Mesh requiere aprender una nueva arquitectura y comprender los matices, como los estados, los elementos y los modelos.

El reto del diseño puede aliviarse al asociarse con un proveedor como Nordic Semiconductor o Cypress Semiconductor. Estos proveedores han lanzado pilas de Bluetooth Mesh para complementar las soluciones BLE maduras. Las pilas vienen acompañadas de los SDK diseñados especialmente que permiten al desarrollador utilizar chips, firmware y herramientas de diseño con los que están familiarizados para acelerar el proceso de aprendizaje del diseño de aplicaciones de Bluetooth Mesh.

Referencia

1. “Mesh Profile”, especificación Bluetooth v1.0, Bluetooth SIG, julio de 2017.