LoRa privada frente a LoRaWAN: no son la misma arquitectura
Compartir una tecnología de radio no significa compartir protocolo, servidor de red o compatibilidad entre dispositivos.
LoRa es radio; LoRaWAN define una red
LoRa es una tecnología de radio; LoRaWAN define un protocolo de red y su arquitectura. Una red privada puede usar un protocolo propietario sobre LoRa o implementar LoRaWAN. Lux AITHA LoRa utiliza una red privada propia a 868 MHz en la UE, coordinada por Router LoRa: no es un dispositivo LoRaWAN.
La distinción evita un error frecuente en los pliegos: pedir un nodo LoRa y asumir que funcionará con cualquier infraestructura LoRaWAN existente. Dos equipos pueden compartir banda y modulación sin interpretar los mismos mensajes. La interoperabilidad depende del protocolo, la identificación de dispositivos, el formato de datos y la integración de la aplicación, además de las características de radio.
La palabra privada describe quién controla una red, no qué protocolo utiliza. LoRaWAN admite despliegues privados, públicos y otros modelos de operación. Por eso, comparar privada frente a LoRaWAN exige aclarar si privada significa propietaria. En este artículo, red LoRa privada propia se refiere al caso publicado de Lux AITHA, no a todas las redes privadas posibles.
La LoRa Alliance explica la diferencia entre LoRa y LoRaWAN y describe una topología de nodos, gateways y servidores. Esa referencia establece el funcionamiento general del estándar; no demuestra que un producto concreto implemente LoRaWAN. Para comprar o integrar un dispositivo se necesita una declaración específica del fabricante y la documentación de la versión propuesta.
Qué cambia en el recorrido del mensaje
En una arquitectura LoRaWAN habitual, los dispositivos transmiten hacia gateways que transportan los mensajes por IP a un servidor de red. El servidor participa en la gestión de la comunicación y entrega los datos hacia la aplicación. El proyecto debe decidir quién opera esos componentes, cómo se aprovisionan los dispositivos y cómo se obtiene acceso a los datos.
Una arquitectura propietaria sobre LoRa puede organizar la comunicación de otra manera. En el caso de Lux AITHA LoRa, Router LoRa concentra la red de dispositivos y enlaza con AITHANEX o el sistema acordado mediante 4G, Ethernet o WiFi. La ficha no exige servidor de red LoRaWAN. El router es independiente de la luminaria, no parte de su controlador.
Esta diferencia afecta al inventario y al mantenimiento. Se deben conocer las configuraciones de nodos y router, la salida a Internet y la persona responsable de cada tramo. Una comunicación de radio correcta no basta si el enlace del router falla. Del mismo modo, disponer de Internet en el gateway no demuestra que todos los puntos tengan comunicación suficiente.
Interoperabilidad, seguridad y banda regional
LoRaWAN aporta un marco común de comunicación, pero integrar la información de negocio sigue siendo necesario. La aplicación necesita interpretar los datos y relacionarlos con activos reales. En un protocolo propietario, la documentación de interfaces y las responsabilidades del proveedor adquieren especial importancia. Ninguna opción elimina por sí sola el trabajo de modelar datos, permisos y mantenimiento.
La modulación LoRa no constituye un sistema de seguridad completo. La protección depende del protocolo y de su implementación: identidad, credenciales, permisos y tratamiento de mensajes. No se debe deducir cifrado o autenticación específicos de un producto únicamente porque use LoRa. En la evaluación conviene solicitar evidencias de esos mecanismos y establecer cómo se gestionan durante su vida útil.
En la UE, la configuración de 868 MHz debe respetar las condiciones regulatorias aplicables a la subbanda utilizada. Potencia, ocupación y tiempo de transmisión no se eligen libremente por buscar más alcance. Obstáculos, antenas, emplazamiento e interferencias influyen en el enlace. Una cifra de distancia en condiciones favorables no sustituye mediciones en las calles o recintos del proyecto.
Cómo elegir sin confundir requisitos
Si el requisito contractual es interoperar con una red LoRaWAN, se debe comprobar soporte LoRaWAN explícito antes de seleccionar el equipo. No basta con la etiqueta LoRa. Si el proyecto acepta una red propietaria, debe evaluar la infraestructura, la documentación de integración y la continuidad del proveedor. La elección depende de responsabilidades y restricciones reales, no de cuál nombre resulte más familiar.
Un piloto útil verifica el recorrido completo: evento en el nodo, recepción en la infraestructura, entrega a la aplicación y orden de retorno cuando proceda. También prueba la pérdida de cada enlace y su recuperación. Registrar tiempos, estados y errores permite separar problemas de radio, backhaul y aplicación en lugar de atribuir cualquier fallo al mismo componente.
La ficha técnica de Lux AITHA documenta su red propia y las variantes. Mantener la expresión no LoRaWAN en la especificación evita que una capacidad ajena se dé por supuesta. Si un proyecto necesita otra arquitectura, debe revisarla como requisito de integración separado, sin convertir una posibilidad general de la tecnología en una función ya publicada del producto.