Estado de la Red Contacto

Comparativo de proyectos mesh

Analiza las diferencias entre Meshtastic, MeshCore, Reticulum y MeshCom. Comparación detallada con criterios técnicos y fuentes.

cumple/verdadero no cumple/no es el foco
Criterio
Meshtastic
MeshCore
Reticulum
MeshCom
Topología mesh “pura” (no jerárquica)
Si cualquier nodo puede encaminar paquetes sin roles fijos.
Malla no jerárquica con managed flood; cualquier nodo puede actuar como relay.
No es una malla “pura”. Encaminamiento concentrado en repetidores; los clientes no repiten.
Stack descentralizado multi-hop con autodiscovery y políticas flexibles.
Usa formato tipo APRS/AX.25 con MAX-HOP y campo Digipeater; cualquier nodo puede actuar como digipeater/encaminador, además de gateways para red de mensajes/HAMNET.
Clientes retransmiten/encaminan
Si un dispositivo “cliente” también puede actuar como nodo de retransmisión.
Perfiles permiten retransmisión (Client/Router/Repeater). La versión 2.6 introduce next-hop para DMs, aprendiendo el mejor relé y reduciendo airtime.
Los clientes no retransmiten. Solo repetidores encaminan, imponiendo jerarquía y exigiendo planificación de red.
Cualquier nodo puede rutear según políticas y enlaces activos; el diseño del stack favorece multi-salto descentralizado.
Soporta digipeating via protocolo (campo de ruta y MAX-HOP), sin requerir roles separados de “repetidor”.
Criptografía documentada (algoritmo/modo)
Indica si el proyecto especifica claramente las cifras y modos de operación.
Payload cifrado con AES-256-CTR, cabecera en claro para permitir retransmisión. La documentación oficial describe el esquema y la gestión de claves.
Existe criptografía (p. ej., DMs y salas), pero no hay documentación técnica detallada sobre algoritmo/modo; dependencia de posts comunitarios y wiki incompleta.
E2EE completo con forward secrecy y ACKs autenticados; el manual detalla cifras, derivación de claves y mecanismos de seguridad.
Sin E2EE documentado. Protocolo basado en APRS/AX.25, típicamente sin cifrado por regulaciones de radioaficionados; el sitio/protocolo no describe cifrado de extremo a extremo.
Store-and-Forward / historial
Capacidad de guardar y reenviar mensajes hasta entrega o timeout.
Implementa retransmisión fiable con ACK/TTL: los nodos mantienen el mensaje hasta entrega o expiración. Funciona bien en microcomunidades; en redes nacionales densas puede causar congestión, pues cada radio mantiene colas esperando ACK.
Usa un Room Server dedicado que almacena historial (p. ej., últimas ~16 mensajes) y reenvía a nuevos clientes.
LXMF con Distribution Net y E2EE: entrega diferida asíncrona incluso con nodos offline; historial gestionado por el protocolo.
Soporta gateways/servidor, “Unified messaging” (APRS↔MeshCom) y Mailbox (BBS) — soluciones de historial/entrega diferida vía servidor.
Telemetría (tipos, cadencia y desactivación)
Métricas soportadas, intervalos configurables y forma de desactivar/limitar.
Incluye un módulo de telemetría que envía datos como nivel de batería, utilización del canal y estado del dispositivo, así como información ambiental. La frecuencia de envío puede ajustarse y, si prefieres, es posible reducir o desactivar esos envíos.
Sin módulo de telemetría documentado comparable a Meshtastic. La documentación pública se centra en Repeater/Room Server y operación vía CLI/serial; no describe claramente tipos/cadencia de telemetría ni cómo desactivar a nivel de protocolo. Puede requerir soluciones específicas por firmware/app.
La telemetría es a nivel de aplicación (p. ej., LXMF/Sideband): puede incrustar telemetría en mensajes y hacer store-and-forward. Cadencia y activar/desactivar se definen por la app/servicio (no por el stack).
Telemetría rica (BME/BMP/INA/DS18B20, etc.), compilación dinámica, envío a APRS.fi; comandos para activar/desactivar sensores y definir intervalos.
Entrega de mensajes (confirmación)
Indica si hay feedback al usuario sobre envío y entrega de mensajes.
Apps Android e iOS muestran estados como enviado y entregado, soportados por ACKs en el protocolo para confirmar entrega punto a punto.
Las apps móviles también muestran indicadores de envío/entrega, aunque la confirmación se basa en la topología y funcionalidades actuales de la aplicación.
Soporte a ACKs autenticados en el core y apps LXMF/Sideband muestran estados detallados (enviado, confirmado, entregado).
Sin ACK E2E documentado en RF; las apps muestran estado, y el servidor puede reenviar/entregar (p. ej., BBS), pero no hay especificación de confirmación RF punto a punto.
Escalabilidad en redes densas (airtime/colisiones)
Capacidad de manejar muchos nodos sin saturar el canal de radio.
El modelo de broadcast/flood puede causar congestión y colisiones en redes muy densas. La versión 2.6 introduce next-hop para DMs, mitigando parte del problema.
Como los clientes no retransmiten, el tráfico se concentra en repetidores, reduciendo colisiones. Requiere planificación de red para buen rendimiento.
Diseñado para operar en escenarios de baja banda y alta latencia, con protocolos eficientes para reducir colisiones y soportar redes densas.
Multi-hop con MAX-HOP y filtrado por grupos; uso de gateways y BBS puede reducir carga RF en redes grandes.
Resiliencia en emergencias (off-grid y redundancia)
Capacidad de mantener comunicaciones durante apagones o fallos de Internet, usando energía autónoma y mecanismos locales.
Comunicación 100% off-grid via LoRa multi-hop. MQTT es opcional y solo sirve como extra para integración con redes IP (p. ej., apps, mapas); la red LoRa funciona autónomamente incluso sin MQTT.
Funciona off-grid con repetidores autónomos a paneles solares, como se reporta en varios casos prácticos. Sin embargo, la arquitectura híbrida depende de repetidores fijos: los clientes no enrutan, por lo que la cobertura exige planificación. No tiene un backend MQTT nativo oficial; la comunicación es solo LoRa.
Concebido para máxima resiliencia: opera sobre LoRa, radio, IP o cualquier medio disponible. Funciona totalmente off-grid, con soporte de energía autónoma y protocolos store-and-forward (LXMF) para nodos offline.
LoRa off-grid; puede conectarse vía gateways a HAMNET/Internet para redundancia entre mallas.
Modelo de licenciamiento / costes
Indica si el proyecto es totalmente open-source o si hay recursos de pago/freemium.
Totalmente open-source, sin funciones de pago ni capas freemium. Licencia permisiva, comunidad activa.
OSSGratis
Tiene funcionalidades premium (p. ej., algunos firmwares de radios) con licencia de pago. El core es gratuito, pero los extras requieren pago.
FreemiumPremium features
Proyecto 100% open-source, sin capas de pago, orientado a privacidad y libertad del usuario.
OSSGratis
Open-source (firmware y apps públicos); sin referencias a funciones de pago.
OSSGratis
Interoperabilidad entre proyectos
Capacidad de comunicar directamente en el aire sin gateways/conversores.
No interoperable nativamente con MeshCore. Pila de protocolo, framing y esquema de cifrado propios de Meshtastic.
Tampoco habla con Meshtastic. Usa formatos y roles propios (Repeater/Room), no compatibles con la malla de Meshtastic.
Ecosistema separado (Reticulum/LXMF). Define su propia capa de red y mensajes; no es interoperable over-the-air con Meshtastic/MeshCore.
Protocolo propio (APRS/AX.25-like). Interconecta con APRS/HAMNET vía gateways, pero no con Meshtastic/MeshCore/Reticulum en el aire.
Roles/firmware (flexibilidad de configuración)
Cómo cada proyecto maneja funciones de nodo y si exige firmwares distintos.
Un único firmware con perfiles ajustables (Client, Router, Repeater), configurable vía app oficial o CLI.
Funciones separadas por firmware: Repeater, Terminal Chat y Room Server tienen builds propios, requiriendo flash diferente para cada rol ⇒ menos flexible.
El stack Reticulum define rol dinámico por nodo y enlace, sin dependencia de firmwares específicos.
Un único firmware puede actuar como cliente o gateway; solo RAK con ETH tiene firmware propio de gateway.
Tamaño de la comunidad/adopción
Tamaño y actividad de la comunidad, presencia de documentación e integraciones.
Comunidad amplia y activa, con diversas integraciones (apps, mapas, gateways) y documentación abundante.
Comunidad significativamente menor, con menos guías/artículos y adopción limitada a algunos países.
Comunidad de nicho más técnica, enfocada en privacidad y entusiastas de redes; no es masiva.
Comunidad radioaficionada activa (sitio, foro, groups.io, apps Android/iOS), aunque menor que Meshtastic.
Soporte de movilidad (nodos en movimiento)
Capacidad de la red de manejar dispositivos en desplazamiento (coches, expediciones, etc.).
Funciona bien con nodos móviles, gracias al flood control y al next-hop para DMs introducido en 2.6. Ideal para expediciones, hiking o vehículos.
El modelo de red favorece repetidores fijos; los clientes en movimiento no enrutan, limitando flexibilidad en escenarios dinámicos.
Diseñado para entornos adversos y movilidad variable. El stack soporta cambios de topología y enlaces intermitentes sin reconfiguración.
Incluye SmartBeaconing, GPS y telemetría móvil; mensajes vía RF y vía gateway según sea necesario.
Herramientas y operación (CLI/Apps)
Disponibilidad de apps oficiales y comunitarias, y facilidad de configuración.
Apps oficiales y comunitarias para Android, iOS y Web, además de CLI completa para configuración y operación.
Configuración limitada vía CLI/serial; apps propias menos maduras. Exige firmwares distintos para cada rol (Repeater, Room Server, etc.).
Ecosistema rico: Sideband, NomadNet, MeshChat (LXMF) y otras herramientas; integración fácil con CLI y APIs.
Apps Android/iOS, Web-installer, WebService, OTA e interfaz UDP JSON; comandos de nodo vía app/serial.
Ritmo de releases / soporte a placas
Actualizaciones de firmware y variedad de hardware soportado.
Evolución continua en GitHub y amplio soporte a boards ESP32, Heltec, LilyGO, etc.
Releases activas, con soporte a T-Lora C6, RP2040, Heltec V3 y otros; foco en placas populares.
Independiente de hardware: funciona en cualquier HW común (LoRa, serial, radio, IP), con soporte flexible vía drivers.
Firmware 4.x en evolución; Web-installer; soporte a Heltec/T-Deck/RAK/ESP32, OTA e imágenes dedicadas (RAK gateway ETH).
Densidad pública / red espontánea
Presencia de nodos públicos y facilidad de formar redes ad-hoc sin planificación previa.
Gran número de nodos públicos en varias regiones, permitiendo formación espontánea de mallas y roaming comunitario.
Menor densidad espontánea; crecimiento más local o específico por país. Requiere planificación y repetidores fijos para buena cobertura.
Puede operar tanto en topologías espontáneas como en redes planificadas; el stack soporta auto-descubrimiento y enlaces intermitentes.
Red comunitaria ham en crecimiento (nodos, gateways y servidores mapeados; integración APRS/HAMNET incentiva densidad regional).

Fuentes

Meshtastic
MeshCore
Reticulum
  • Manual — E2EE, forward secrecy, ACKs, tolerancia a latencias. Manual (PDF)
  • LXMF / Distribution Net — FAQ
MeshCom

Notas: MeshCom está orientado a radioaficionados (APRS/HAMNET). En muchos países, la criptografía no está permitida en bandas de radioaficionado; el sitio MeshCom no documenta E2EE en RF.
Algunas fuentes son documentación oficial; otras son artículos de terceros y discusiones comunitarias (identificadas como tal) — incluidas para registrar comportamientos observados y limitaciones prácticas reportadas.

Casos de uso recomendados (resumen)

Meshtastic

Off-grid Equipos móviles
Expediciones, redes comunitarias, emergencia.

MeshCore

Red planificada Repetidores fijos
Barrios/eventos con repetidores dedicados y rooms.

Reticulum

Resiliencia Entrega diferida
E2EE extremo, LXMF, tolerante a latencia.

MeshCom

APRS/HAMNET Gateways/BBS
Redes ham integradas, telemetría APRS.fi, mailbox vía servidor.

Última actualización: 24/08/2025