De anuncios Bluetooth propios a Mesh: qué exige una red multisalto

Supongamos que ya tienes control mediante anuncios Bluetooth: el controlador envía «encender», las lámparas cercanas reciben el mensaje y se iluminan. Controlas dispositivos y aplicación, y el protocolo es sencillo.

Ahora quieres ampliar la cobertura. El controlador no alcanza el dormitorio, así que una lámpara del pasillo retransmite. La primera implementación parece evidente: recibir un paquete conocido y volver a emitirlo.

Con dos lámparas aparecen los problemas: ambas retransmiten, llegan copias por caminos distintos y los vecinos pueden devolverlas. Hay que preguntar: ¿ya he visto este mensaje, debo reenviarlo, ya lo ejecuté y conoce el emisor el resultado?

La primera entrega explicó la relación entre Mesh propio, SIG Mesh y Xiaomi Mesh. Esta examina qué necesita un protocolo de difusión propio para convertirse en una red multisalto.

La red controlador–retransmisor–lámpara es un ejemplo de diseño, no una medición de un producto. Primero analizaremos la fiabilidad y después si merece la pena mantener un Mesh propio.

Paso 1: una identidad que no cambie al reenviar

En un solo salto solemos centrarnos en los campos de control: qué byte representa el encendido y cuál el brillo. Con retransmisores, la identidad del mensaje es igual de importante.

El controlador A envía una solicitud; B y C la retransmiten y D recibe dos copias. D debe reconocer que corresponden a la misma transmisión.

El retransmisor no debe convertirla en una nueva orden de aplicación emitida por él. Puede cambiar el transmisor inmediato de radio, pero el protocolo debe conservar el origen y la identidad iniciales.

Información	Qué aclara
Red o dominio de seguridad	A qué sistema pertenece; el identificador no basta para confiar
Origen inicial y destino	Quién inició la operación y si se dirige a un dispositivo o grupo
Secuencia y generación necesarias	Si es un mensaje de transporte nuevo o una copia conocida
Presupuesto de reenvío	Cuántas retransmisiones adicionales se permiten
Identificador de solicitud de aplicación	Si varias transmisiones pertenecen a la misma operación
Operación, parámetros y autenticación	Qué se pide, si es legítimo y si fue alterado

Son responsabilidades, no un formato listo para implementar. Posición, tamaño y cobertura de autenticación deben diseñarse junto con direcciones, claves y fragmentación.

Una copia del mismo paquete y una transmisión nueva que reintenta una operación no son necesariamente lo mismo. Esa diferencia determina si un reintento se ejecuta dos veces.

Paso 2: limitar el reenvío

Un presupuesto de reenvío disminuye en cada retransmisor y detiene la propagación al agotarse, incluso si existen bucles. Pero no limita por sí solo cuántas veces un nodo procesa copias: B puede reenviar y luego recibir el mismo mensaje desde C.

Una caché de mensajes recientes puede impedir iniciar otro procedimiento de reenvío para la misma identidad. Eso no significa «descartar todos los duplicados en cualquier capa»: la red puede suprimir propagación repetida, mientras la aplicación necesita devolver un resultado guardado ante un reintento. Una sola marca global no sustituye ambas funciones.

La duración y capacidad de la caché cuestan recursos. Si es corta, una copia tardía puede parecer nueva; si es larga, consume memoria y complica reutilizar identificadores. Debe estimarse a partir de frecuencia de mensajes, tiempo de propagación y ventana de reintentos, y validarse bajo carga.

Antes de incorporar un mensaje al estado confiable, deben realizarse las comprobaciones necesarias de formato, red y autenticación. Un paquete falso no debería ocupar una entrada que haga descartar la orden auténtica.

El manual de Bluetooth SIG describe retransmisión y TTL. Un presupuesto propio puede resolver problemas parecidos sin compartir exactamente su semántica: no hay que equiparar directamente sus valores numéricos.

Paso 3: decidir quién retransmite y cuándo

Que muchos dispositivos reciban no implica que todos deban retransmitir inmediatamente. Si reciben y vuelven a emitir casi a la vez, las copias pueden aumentar las colisiones.

Hay que combinar elegibilidad del retransmisor, tiempos, repeticiones limitadas y límites de cola. Retrasos aleatorios controlados reducen la competencia sincronizada; limitar los envíos por mensaje evita colas crecientes.

Más retraso añade latencia acumulada entre saltos. Más repeticiones tampoco garantizan fiabilidad: en congestión pueden desplazar tráfico útil. «Todas las luces como retransmisores» y «duplicar reintentos si hay pérdidas» no son reglas universales. Importan colocación, alimentación y carga.

Escanear continuamente y ayudar a otros consume energía. Un interruptor a pilas que transmite una pulsación no es necesariamente un retransmisor permanente adecuado.

Low Power y Friend en SIG Mesh distribuyen el trabajo: Friend conserva temporalmente mensajes para que el nodo de bajo consumo no escuche siempre. Un sistema propio para dispositivos dormidos necesita ventanas de recepción, almacenamiento u otra coordinación; no basta con declarar «compatible con baterías».

Paso 4: definir en qué capa se produce el éxito

Conviene resolverlo antes de diseñar paquetes. «Transmisión completada», devuelto por el módulo Bluetooth, describe su operación. No demuestra que la lámpara del dormitorio recibiera el mensaje ni que se encendiera.

Incluso una respuesta del destino necesita significado: recibido, aceptado, ejecutado o estado físico observado. Un controlador de relé puede informar que activó la salida; sin medida de corriente u otra realimentación, no sabe si la carga funcionó. La interfaz debe mostrar lo que realmente puede observar.

Un retransmisor tampoco debe anunciar éxito en nombre del destino. Solo acredita un salto intermedio. Si importa el estado final, hace falta una respuesta de extremo a extremo vinculada a la solicitud.

Confirmarlo todo tiene otro coste: los grupos. Una orden de apagado puede provocar respuestas simultáneas de todas las lámparas, multiplicadas por la retransmisión. El manual SIG también señala que los mensajes confirmados funcionan bien con destinos individuales, pero escalan peor con grupos grandes.

Podemos confirmar configuraciones importantes una a una, repetir de forma limitada órdenes de grupo y consultar estados de manera escalonada, o definir agregación y plazos para obtener resultados completos. Hay que declarar la garantía real: sin comprobar los estados, no se puede afirmar que todos ejecutaron correctamente.

Paso 5: que reintentar no encienda y vuelva a apagar

La lámpara ejecuta una orden, pero se pierde la respuesta. El controlador agota el plazo y reintenta. Si la orden es «alternar», dos ejecuciones restauran el estado anterior: el usuario podría ver un destello y después oscuridad.

«Establecer encendido» suele evitar ese problema. En operaciones de estado objetivo, conservar el mismo efecto al repetir es útil. Pero «mover el motor un paso», «restar una unidad» o «iniciar un temporizador» pueden duplicar efectos. Requieren identidad de solicitud, registro del resultado y recuperación.

Secuencia de transporte e identificador de aplicación pueden tener cometidos distintos: cada nueva transmisión sigue las reglas de seguridad, mientras la aplicación reconoce la operación anterior y devuelve su resultado sin repetirla.

Queda un fallo sutil: primero se pide brillo al 30%, después al 80%, pero un reintento tardío del primer comando llega al final y restaura el 30%. Cada orden por separado tolera repetición, pero el estado retrocede.

También necesitamos orden y vigencia: versiones dentro de un flujo de control, caducidad o cancelación de reintentos antiguos cuando llega una operación nueva. Varios controladores requieren una política de sobrescritura.

Repetir sin duplicar efectos no garantiza por sí solo el resultado correcto. Tampoco conviene prometer ejecución exactamente una vez si la energía puede fallar después de actuar y antes de guardar el resultado.

Paso 6: reiniciar no debe borrar la seguridad

Quien recibe emisiones cercanas puede grabar una orden válida y reproducirla más tarde. Cifrar no resuelve todo: un texto cifrado legítimo y sin modificar puede volver a presentarse en un momento indebido.

La caché breve de duplicados y la protección contra repetición son diferentes. Liberar memoria no debería volver a autorizar órdenes antiguas.

Debemos considerar emisor y receptor. ¿Cómo evita el emisor reiniciado reutilizar de manera insegura secuencias o nonces? ¿Cómo evita el receptor aceptar mensajes antiguos tras olvidar su estado? ¿Qué ocurre al restablecer fábrica, reincorporar o cambiar claves?

Para algoritmos de cifrado autenticado que exigen nonce único por clave, no basta un contador en RAM que arranque en cero. Varios emisores con claves compartidas también deben evitar colisiones. La construcción debe seguir los requisitos del algoritmo y de un protocolo maduro.

RFC 5116 trata cifrado autenticado y uso de nonces, y separa explícitamente su interfaz de los servicios completos de antirrepetición y control de acceso. «Usamos AES» puede ocultar esa distinción.

Persistir datos añade desgaste de flash, consistencia ante cortes y recuperación. Reservar rangos de contador con un límite persistido es una posible estrategia, pero debe demostrarse que una escritura interrumpida no permite retroceder o reutilizar valores. No basta probar reinicios normales.

El ciclo de claves también pertenece al diseño inicial: incorporación segura, retirada de dispositivos perdidos o vendidos y revocación. Borrar una fila de la aplicación no revoca las claves dentro del dispositivo.

Paso 7: mensajes pequeños antes de fragmentación y actualizaciones

Las órdenes de encendido son cortas y el prototipo puede ignorar el tamaño. Configuración masiva, propiedades largas y firmware plantean otros problemas: identificar fragmentos, reconstruir mensajes, recuperar piezas perdidas, limitar tiempo de almacenamiento y concurrencia.

La capacidad teórica de anuncios BLE, anuncios extendidos o un SDK no equivale a carga útil de aplicación. Cabeceras, seguridad, soporte de dispositivos y portador reducen o limitan el espacio.

Fragmentar multiplica tráfico: una operación se convierte en varios paquetes potencialmente retransmitidos. Una política de reintentos deficiente puede hacer que poca configuración bloquee el control habitual.

Primero establecería órdenes breves, informes de estado y recuperación. OTA requiere un diseño propio de transporte, control de tráfico, verificación de firma y recuperación de fallos. Poder mover datos por Mesh no equivale a tener actualizaciones fiables.

Cómo superar la demostración que funciona

Una red pequeña puede revelar rutas de fallo antes de buscar grandes cantidades de nodos. Estas son pruebas propuestas, no resultados medidos.

Escenario	Qué observar
Una orden llega por dos retransmisores	Copias limitadas y ausencia de ejecución duplicada
Se pierde la respuesta tras ejecutar	Reintentos sin repetir efectos y devolución del resultado conocido
Llega la orden nueva antes del reintento viejo	Si la petición tardía sobrescribe el estado reciente
Se apaga o mueve un retransmisor	Continuidad con ruta alternativa y fallo explícito sin ella
Informes simultáneos y respuestas de grupo	Latencia, fallos, repeticiones y presión en colas
Cortes en momentos críticos de emisor y receptor	Recuperación de secuencias, nonces, solicitudes y antirrepetición
Retirada o reincorporación de un dispositivo	Si claves, mensajes o vínculos antiguos permiten acciones indebidas

Definamos los extremos de la medición: ¿desde la aplicación hasta la emisión, o hasta el informe de ejecución del destino? Sin sensor de la carga real, el segundo no debe llamarse tiempo físico de respuesta de la luz.

Además de promedios, registremos colas de latencia, tiempos agotados, ejecuciones duplicadas y transmisiones. Al presentar mediana y P95, indiquemos muestras y fallos por separado. Excluir todos los tiempos agotados y mostrar solo éxitos produce cifras engañosas.

También hay que registrar distribución, alimentación, interferencia Wi-Fi, escaneo y frecuencia del tráfico. De lo contrario, pruebas de días distintos quizá no sean comparables.

Después decidimos cuánto desarrollar nosotros

Reemitir un anuncio puede requerir pocas líneas. Una red mantenible necesita reglas coordinadas de identidad, direcciones, reenvío limitado, duplicados, confirmaciones, reintentos, seguridad, recuperación y diagnóstico.

No todos los productos deben reimplementar SIG Mesh. Un ámbito preciso, dispositivos controlados y muchos productos instalados pueden justificar un diseño propio. Importa saber qué capacidades omitimos y si esas omisiones encajan con el producto.

Si la única razón es «nuestro protocolo de anuncios es sencillo», conviene calcular el coste de mantenimiento durante el prototipo. Una solución madura o una pila estándar puede reservar tiempo para funciones de dispositivos y lógica de pasarela.

En nuestra dirección de pasarela Matter, comportamiento del producto, mapeo de estados y manejo de errores son áreas valiosas para conservar. Cuánta red inalámbrica implementamos depende de poder validarla y mantenerla, no solo de que arranque la primera versión.

La próxima entrega vuelve a SIG Mesh: ¿qué sucede desde descubrir un dispositivo y completar Provisioning hasta controlarlo realmente? Claves de red y aplicación, vinculación de modelos y publicación/suscripción aportarán una referencia concreta.

Si ya mantienes anuncios privados, empieza por por qué necesitas retransmisión, qué dispositivos tienen alimentación permanente y qué fallo es inaceptable. Podemos hablar aquí.