¿Por qué una red Bluetooth Mesh se vuelve más lenta al añadir más nodos Relay?

La luz al fondo del pasillo deja de responder de vez en cuando, así que activas la función Relay en varias luces cercanas.

Parece funcionar. Entonces decides activarla en todas las luces compatibles y aumentar el número de retransmisiones: «Si se envía más veces, alguna llegará, ¿no?».

Pero, al regular la intensidad de todo un grupo, las luces vuelven a reaccionar con lentitud. Unas cambian antes que otras, mientras el estado en el teléfono sigue actualizándose.

Puede que el problema haya dejado de ser «el mensaje no llega» y haya pasado a ser «hay demasiadas transmisiones en el mismo espacio radioeléctrico».

Los nodos Relay pueden añadir rutas de comunicación, pero cada retransmisión también consume recursos inalámbricos. Para decidir si conviene añadir o reducir retransmisiones, distingue primero qué falta: cobertura, una ruta alternativa o menos tráfico duplicado.

La situación anterior es un ejemplo hipotético, no un registro de pruebas. Este artículo trata principalmente sobre redes SIG Mesh que utilizan transmisión por difusión y Managed Flooding (inundación controlada); no representa todas las implementaciones de productos Bluetooth. No se han medido la latencia, la capacidad ni la tasa de éxito de dispositivos concretos. El orden de diagnóstico propuesto es una recomendación de ingeniería.

Ilustración generada con IA. Los arcos no representan cobertura medida, intensidad de señal ni rutas reales.

1. Un nodo Relay vuelve a emitir el mensaje desde otro lugar; no «sube la señal al máximo»

Consideremos una ruta sencilla:

Interruptor de pared → nodo Relay del pasillo → luz alejada.

El interruptor no alcanza directamente la luz alejada, pero un nodo del pasillo puede recibir el mensaje y volver a emitirlo. Ahí está el valor de Relay: permite que el mensaje atraviese un tramo al que antes no llegaba.

No aumenta la potencia de transmisión del interruptor ni reserva un canal exclusivo para esa orden de control.

Si hay muchos nodos con Relay habilitado en una misma habitación, todos pueden recibir un mensaje que cumpla las condiciones de reenvío y participar en su retransmisión. Tener varias rutas puede aumentar las oportunidades de entrega, pero también implica más transmisiones inalámbricas.

Tanto un artículo de Bluetooth SIG sobre diseño de redes como la documentación de optimización de Silicon Labs insisten en lo mismo: cada nodo Relay debe tener una ubicación y una función; no hay que habilitarlos todos solo porque los dispositivos lo permitan.[1][2]

Por eso, antes de «añadir otro nodo Relay», pregúntate:

• ¿Qué tramo de una ruta inestable puede conectar?
• ¿Aporta una ruta alternativa distinta de las que ya existen?
• ¿Quedará sin alimentación cuando se apague el interruptor de pared?

Si no puedes responder a esas preguntas, quizá estés añadiendo principalmente transmisiones duplicadas, no cobertura útil.

2. Si se filtran los paquetes duplicados, ¿por qué aumenta la carga?

Es fácil pensar: «Si Mesh filtra los paquetes duplicados, da igual cuántos nodos Relay haya, ¿no?».

El filtrado evita que un nodo procese repetidamente un paquete que ya ha visto, pero no puede borrar las señales inalámbricas que otros nodos ya han transmitido.

Por ejemplo, los nodos Relay B y C reciben un mensaje de A. Al recibirlo por primera vez, ambos pueden cumplir las condiciones para reenviarlo. Más tarde, D puede identificar como duplicadas las copias procedentes de B y C, pero ambas transmisiones ya se han producido.

También hay que distinguir dos situaciones:

• Recibir copias duplicadas de otros nodos no debe hacer que un nodo Relay inicie nuevos reenvíos indefinidamente.
• Para mejorar la fiabilidad, el emisor o el propio nodo Relay pueden transmitir varias copias según su configuración.

La primera situación está limitada por mecanismos como la caché; la segunda corresponde a transmisiones repetidas configuradas. No son contradictorias. El material introductorio de SIG presenta TTL y la caché de mensajes como mecanismos que limitan Managed Flooding; la documentación de Silicon Labs explica además la configuración de Network Transmit y Relay Retransmit.[2][3]

¿Qué conviene revisar primero? No te limites a comprobar que el registro de la aplicación muestra «una orden recibida». Que la capa de aplicación la entregue una sola vez no demuestra que por radio se haya transmitido una sola vez. Combina los contadores de la pila de protocolos, los registros de la cola de envío y las herramientas de captura disponibles para determinar en qué capa se producen las repeticiones. Un único punto de captura también puede perder paquetes y no representa necesariamente todo el tráfico de la red.

3. No llames «mejorar la señal» a cuatro ajustes diferentes

Al ajustar parámetros sobre el terreno, es fácil perder la capacidad de evaluar los resultados si activas más nodos Relay, elevas el TTL, aumentas las retransmisiones y haces que la aplicación reintente más veces, todo a la vez.

Cada ajuste tiene un efecto distinto:

Ajuste	Qué cambia principalmente	Qué comprobar antes de modificarlo
Activación y ubicación de Relay	Qué nodos participan en el reenvío y dónde existen rutas de comunicación	¿Cubre una zona sin servicio o añade reenvíos duplicados donde ya hay cobertura?
TTL	El alcance del mensaje en número de saltos	¿Dónde están los dispositivos que se controlan y hasta dónde deben llegar las rutas alternativas necesarias?
Network Transmit / Relay Retransmit	El número de copias enviadas y los intervalos de envío en la capa de red, desde el nodo de origen o un nodo Relay	¿El campo del SDK actual indica el número de retransmisiones o el número total de envíos?
Publicación de modelos, consultas y reintentos de la aplicación	Cuántos mensajes genera la lógica de la aplicación y cuándo vuelve a enviarlos	¿Hay informes demasiado frecuentes, consultas simultáneas o envíos duplicados?

El TTL es especialmente fácil de interpretar mal. Limita hasta dónde puede propagarse un mensaje: no es la potencia de radio ni un porcentaje de fiabilidad. Un mensaje con TTL igual a 0 no se reenvía mediante nodos Relay; por tanto, no puede llegar así a un dispositivo que requiere un salto intermedio.[3]

Pero eso tampoco significa que convenga establecer siempre un TTL alto. «El mensaje puede viajar más lejos» no equivale a «esta luz tiene más probabilidades de recibirlo». La propagación innecesaria también puede aumentar la carga en otras zonas.[1]

Además, un «3» en la interfaz de configuración puede significar tres envíos o tres retransmisiones. Hay que consultar la API del SDK y la codificación del parámetro para saber si el envío inicial se cuenta aparte. Antes de aclarar qué significa el campo, no copies sin más los valores de otra instalación.

4. ¿Cómo distinguir la falta de cobertura del exceso de mensajes?

No saques conclusiones porque «ahora vuelve a funcionar». Mantén fijos los dispositivos, las posiciones y las acciones de control, y realiza dos comparaciones.

Primera comparación: con poca carga, ¿el problema sigue concentrándose en los dispositivos alejados?

En el entorno de prueba, conserva el control necesario y reduce las consultas y los informes en segundo plano que puedas ajustar. Si los dispositivos alejados siguen siendo inaccesibles repetidamente y cambiar la posición de un nodo Relay situado para cubrir ese tramo mejora claramente el resultado, conviene investigar primero la cobertura o las rutas.

Eso aún no es un diagnóstico definitivo: la instalación de la antena, los obstáculos, la alimentación o una configuración incorrecta también pueden influir.

Segunda comparación: sin mover los dispositivos, ¿aparece el problema al aumentar la carga de trabajo?

Un encendido o apagado aislado funciona razonablemente bien, pero surgen retrasos al regular la intensidad con mucha frecuencia, consultar muchos dispositivos a la vez o enviar informes periódicos. Si al reducir una de esas clases de tráfico mejora el comportamiento, sigue investigando la carga radioeléctrica, las colas de la pila de protocolos y la capacidad de procesamiento del gateway, en lugar de añadir inmediatamente otro nodo Relay.

Silicon Labs advierte expresamente que una frecuencia de publicación de modelos demasiado alta aumenta el tráfico de red y puede ralentizar la respuesta.[2] Sin embargo, que «mejore al reducir la frecuencia» solo acota la investigación: no demuestra por sí solo que todos los problemas sean colisiones de radio.

Hay otra comprobación que suele pasarse por alto: ¿lo que tarda es la luz en cambiar, o el estado en volver a la aplicación?

El artículo anterior distingue entre la aceptación por el emisor, el estado del modelo del dispositivo y el cambio real de la luz. También al optimizar hay que registrarlos por separado; de lo contrario, podrías ajustar una ruta de control de las luces que funciona bien solo porque «la interfaz tarda en actualizarse».

5. Si vas a ajustar la red, sigue este orden y conserva las pruebas

Esta es una secuencia práctica para las pruebas de integración, no un procedimiento de ensayo establecido por el protocolo.

Guarda primero una referencia inicial. Anota las versiones del firmware y del SDK, la ubicación de los dispositivos, qué nodos tienen Relay habilitado, el TTL, las retransmisiones de la capa de red, los periodos de publicación de modelos y la estrategia de consultas y reintentos del controlador. Oculta las claves al exportar la configuración. Sin una referencia inicial, será difícil saber a qué cambio se debe una mejora.

Asigna después una función a cada nodo Relay. Marca en un plano cuáles conectan habitaciones, cuáles cubren el pasillo y cuáles proporcionan cobertura alternativa. Conserva primero los nodos que cumplen esas funciones y evalúa por grupos los que ofrecen una cobertura muy solapada. No desactives una zona entera de golpe ni elimines mediante configuración remota la única ruta de administración; prepara antes una forma de recuperar la instalación sobre el terreno.

Luego modifica solo una clase de variable cada vez. Mantén fija la carga de trabajo para comparar configuraciones de Relay; después, mantén fija la distribución de nodos Relay para comparar las transmisiones repetidas o la frecuencia de publicación. Así podrás evaluar el efecto de cada cambio. No hace falta eliminar toda la redundancia que aporta fiabilidad solo para reducir al mínimo el número de envíos.

Por último, prueba la red bajo carga y ante fallos. Poder controlarla cuando está inactiva es solo la mitad del trabajo. También hay que probarla con la carga de regulación de intensidad, informes y consultas prevista para el producto, y desconectar de forma planificada un nodo que actúe como Relay antes de volver a conectarlo.

Conserva, como mínimo, estos registros en cada ronda:

Dato registrado	Cómo registrarlo para que permita comparar
Condiciones de prueba	Usa la misma ubicación, acción, carga y ventana de observación; indica qué se modificó en esta ronda
Resultado del control	Registra el resultado por «dispositivo de destino × acción de control»; separa los estados desconocidos de los éxitos confirmados
Tiempo de respuesta	Define el inicio y el final de la medición: envío de la solicitud, recepción del estado del modelo o cambio real de la iluminación
Respuestas lentas y anomalías	Conserva el número de muestras, las muestras más lentas y la ubicación de los fallos; no informes solo del promedio
Rutas alternativas	Registra qué dispositivos se ven afectados cuando se desconecta un nodo Relay clave y si vuelven a funcionar tras su recuperación

Si necesitas comparar el tiempo real que tarda una luz en cambiar, debes contar con medios adecuados de observación o medición sobre el terreno; los registros de la aplicación no sustituyen el resultado físico.

El objetivo de esta ronda no es elegir el TTL que parezca más bajo ni el menor número posible de nodos Relay. El objetivo es conservar rutas suficientemente fiables con la carga normal y ante los fallos previstos, a la vez que se reducen los envíos innecesarios.

6. ¿Directed Forwarding elimina la necesidad de ocuparse de todo esto?

Bluetooth Mesh dispone también de Directed Forwarding (reenvío dirigido), un mecanismo opcional. Permite que los nodos participantes en una ruta de reenvío determinada transmitan los mensajes pertinentes, en lugar de que participen todos los nodos Relay que cumplen las condiciones de Managed Flooding. Así se reducen las transmisiones inalámbricas innecesarias.[3]

Pero que «exista en el protocolo» no significa que tus dispositivos, tu SDK y tus herramientas de configuración lo admitan y lo tengan habilitado. Tampoco sustituye el diseño del tráfico de la aplicación: si esta genera continuamente nuevas órdenes, consultas y reintentos, sigue siendo necesario comprobar si esos mensajes hacen falta.

Para un proyecto existente, lo más práctico es empezar por enumerar las funciones y los parámetros realmente habilitados y, después, decidir si merece la pena incorporar un mecanismo nuevo. No consideres la actualización de la versión del protocolo como la solución antes de identificar el cuello de botella.

La próxima vez que «un dispositivo alejado no responda de vez en cuando», no actives inmediatamente todos los nodos Relay.

Responde primero a una pregunta: ¿qué tramo de la ruta cubrirá este nuevo nodo Relay?

Si el problema solo aparece cuando la red está ocupada, plantea otra: ¿qué mensajes de esta red no necesitan enviarse tantas veces?

Lecturas relacionadas: Qué hace falta para pasar de la difusión a varios saltos · Por qué los nodos alimentados por batería esperan los mensajes descendentes

Fuentes y ámbito de aplicación

1. Bluetooth SIG: How Bluetooth Mesh Networking puts the ‘large’ in large-scale wireless networks, 26-06-2018. Este artículo toma los principios de diseño de sus secciones sobre Relays, TTL y Network retransmissions, pero no utiliza el tamaño de red, los intervalos de retransmisión ni los multiplicadores de tráfico de sus ejemplos como indicadores de rendimiento de un producto.
2. Silicon Labs: Bluetooth Mesh Networking Principles, 11.0.2. Se utiliza para comprobar las recomendaciones sobre densidad de nodos Relay, frecuencia de publicación y configuración de envíos en la capa de red; las API concretas y los valores de los parámetros deben consultarse en el SDK de destino.
3. Bluetooth SIG: The Bluetooth Mesh Networking primer. Se consultan especialmente las secciones 4.18.1, 4.19.2 y 4.19.3 para verificar TTL, la caché, Managed Flooding y Directed Forwarding.

Fecha de verificación de las fuentes: 06-11-2026. No se han realizado pruebas de hardware para este artículo; no se ofrecen parámetros óptimos universales, una capacidad fija de nodos ni promesas de mejora del rendimiento.