Montar y dejar fina la configuraciĆ³n de una puerta de enlace LoRaWAN puede asustar un poco la primera vez: parĆ”metros de radio, redes, servidores, certificados, IDs extraƱosā¦ pero en realidad, si entiendes bien cada pieza, es un proceso bastante lĆ³gico. En este artĆculo vamos a ir desde el hardware hasta el servidor LoRaWAN, pasando por TTN y AWS IoT Core, para que tengas una visiĆ³n completa y prĆ”ctica.
Nos vamos a apoyar en ejemplos reales como gateways RAK (RAK7289, RAK831), redes pĆŗblicas como The Things Network (TTN), soluciones en la nube como AWS IoT Core para LoRaWAN y configuraciones de fabricantes como MOKO. Iremos hilando todos esos contenidos en una guĆa coherente, con advertencias de seguridad, trucos para encontrar la IP del gateway y detalles de configuraciĆ³n tanto de red como de radio.
Conceptos bƔsicos: quƩ es y quƩ hace una puerta de enlace LoRaWAN
Una puerta de enlace LoRaWAN (LoRaWAN gateway) es el dispositivo encargado de escuchar a los nodos LoRa (sensores, trackers, etc.) y reenviar sus mensajes hacia un servidor de red LoRaWAN a travĆ©s de Internet (Ethernet, Wi-Fi, LTE/4G, 5G, satĆ©lite, etc.). Puedes imaginarla como una especie de torre de telefonĆa pero para dispositivos de muy bajo consumo.
A nivel fĆsico, el gateway integra uno o varios concentradores LoRa (como el RAK831) capaces de monitorizar mĆŗltiples canales en paralelo y diferentes Spreading Factors, una placa de control (por ejemplo, Raspberry Pi o un SoC integrado), interfaces de red (Ethernet, Wi-Fi, LTE) y, a menudo, GPS para sincronizaciĆ³n y geolocalizaciĆ³n aproximada de los nodos.
En el ecosistema LoRaWAN, la puerta de enlace no interpreta el contenido de las tramas de aplicaciĆ³n: simplemente encapsula y reenvĆa (packet forwarder) los paquetes al servidor LoRaWAN (LNS: LoRaWAN Network Server) o a la infraestructura CUPS/LNS de la nube. Por eso, la configuraciĆ³n clave gira en torno a parĆ”metros de radio, identificadores del gateway y la direcciĆ³n del servidor al que va a enviar los datos.
Dependiendo del despliegue, podrĆ”s usar gateways pĆŗblicos (por ejemplo, los de la comunidad TTN en zonas urbanas) o montar tu propio gateway para cubrir un Ć”rea rural, una explotaciĆ³n agrĆcola, un campus educativo o un entorno industrial donde necesites control total de la infraestructura.
Hardware tĆpico de una puerta de enlace LoRaWAN
Para construir o desplegar una puerta de enlace dispones de opciones que van desde dispositivos comerciales cerrados hasta kits de desarrollo basados en Raspberry Pi. Un ejemplo bastante representativo es el uso de un concentrador RAK831 integrado con una Raspberry Pi.
Un kit tĆpico de gateway LoRa de este estilo suele incluir todos los elementos de hardware necesarios para empezar sin tener que buscar piezas sueltas: la propia placa concentradora LoRaWAN, la placa base, antenas y adaptadores. Esto acelera muchĆsimo la puesta en marcha y evita problemas de compatibilidad.
En el caso concreto de algunos kits MOKO basados en RAK831 y Raspberry Pi 3B, el paquete puede traer, entre otros elementos, una placa adaptadora de GPS, antena GPS, antena LoRa de fibra de vidrio con ganancia suficiente para instalaciones en mƔstil, cable coaxial RG-58 de varios metros, disipador para la placa concentradora e incluso nodos de ejemplo tipo WisNode o trackers LoRa.
La gran ventaja de estos kits es que la tarjeta de memoria de la Raspberry Pi suele venir preconfigurada con el software de gateway (packet forwarder, scripts de configuraciĆ³n, etc.), de modo que no tienes que compilar ni descargar nada de GitHub para empezar a funcionar, mĆ”s allĆ” de ajustar unos cuantos ficheros de configuraciĆ³n.
En gateways comerciales como el RAK7289, todo el hardware estĆ” integrado en una carcasa industrial ya preparada para exterior, con antena LoRa y, en ocasiones, otra antena adicional para LTE/4G. En estos modelos, el fabricante normalmente ofrece una interfaz web de configuraciĆ³n bastante guiada, por lo que el trabajo se centra en parĆ”metros de red (IP, DNS, etc.) y en apuntar el gateway al servidor LoRaWAN correcto.
ConfiguraciĆ³n de red del gateway: IP estĆ”tica, DHCP y acceso inicial
Antes de poder tocar la parte LoRaWAN, debes asegurarte de que la puerta de enlace estĆ” correctamente conectada a la red IP (LAN o WAN). Sin conectividad hacia Internet (o hacia tu servidor local) no servirĆ” de nada que la radio funcione bien.
En muchos gateways (por ejemplo, el RAK7289), la interfaz de administraciĆ³n se presenta vĆa web y se accede por su direcciĆ³n IP en la red. Puedes configurarlo como cliente DHCP (que obtenga IP automĆ”ticamente del router) o con una IP fija segĆŗn tu topologĆa de red.
Si el dispositivo viene de fĆ”brica o lo ha configurado otra organizaciĆ³n, es posible que estĆ© en modo cliente DHCP. En ese caso, tendrĆ”s que averiguar quĆ© direcciĆ³n IP le ha asignado el servidor DHCP de tu router o de tu red. Para ello, puedes:
- Consultar directamente la lista de clientes DHCP en el router o servidor, identificando el gateway por su MAC o por el hostname (por ejemplo, āRAK7289ā).
- Usar herramientas tipo nmap u otros escƔneres de IP para descubrir quƩ dispositivos responden en tu segmento de red.
Algunos gateways incluyen un punto de acceso Wi-Fi de gestiĆ³n abierto, pensado precisamente para esa configuraciĆ³n inicial. Si te conectas a esa red Wi-Fi, la puerta de enlace actĆŗa como router y la IP de puerta de enlace predeterminada en tu equipo serĆ” la IP de administraciĆ³n del dispositivo.
Un detalle importante de seguridad: una vez hayas terminado la puesta en marcha, conviene desactivar la Wi-Fi de gestiĆ³n si no es estrictamente necesaria, ya que una red Wi-Fi abierta de administraciĆ³n supone una vulnerabilidad clara en entornos reales.
En la interfaz de configuraciĆ³n (por ejemplo, en el menĆŗ Network ā WAN Interface de un gateway RAK), podrĆ”s escoger entre IP estĆ”tica y DHCP, definir DNS, mĆ”scara, puerta de enlace, asĆ como cambiar las credenciales de acceso por defecto (usuario y contraseƱa) que nunca deberĆas dejar tal cual vienen de fĆ”brica.
Alta y configuraciĆ³n del gateway en The Things Network (TTN)
Una vez que tu gateway tiene salida a Internet, el siguiente paso en muchos despliegues comunitarios o de laboratorio es integrarlo con TTN (The Things Network), una red LoRaWAN pĆŗblica y gratuita ideal para proyectos educativos, pruebas y pequeƱos despliegues.
El proceso habitual comienza creando una cuenta en la web de TTN y accediendo a la Consola desde el icono de perfil. Al entrar por primera vez, el sistema te pedirĆ” que elijas tu regiĆ³n (por ejemplo, Europa, NorteamĆ©rica, etc.), y a partir de ahĆ podrĆ”s ir a la secciĆ³n āAplicacionesā o āPuertas de enlaceā. Para dar de alta el gateway, tendrĆ”s que ir especĆficamente a āIr a Puertas de enlaceā.
En la Consola de TTN, al pulsar el botĆ³n de Registrar puerta de enlace, se te solicitarĆ”n varios datos: un identificador para el gateway (Gateway ID), su EUI Ćŗnico (Gateway EUI) y el plan de frecuencias segĆŗn tu regiĆ³n. El Gateway EUI suele estar disponible en la propia interfaz web del dispositivo o en su firmware, normalmente en la secciĆ³n de configuraciĆ³n de la red LoRa.
Es fundamental que el Gateway ID que definas en TTN coincida con el configurado en el equipo, especialmente si la documentaciĆ³n del fabricante asĆ lo exige. AdemĆ”s, tendrĆ”s que seleccionar el plan de frecuencia apropiado (por ejemplo, EU868 para Europa), que define los canales disponibles y parĆ”metros de radio compatibles con la normativa de tu paĆs.
Una vez registrado el gateway en TTN, la parte de configuraciĆ³n en la Consola queda casi lista. TTN te mostrarĆ” el estado del gateway (conectado o no) cuando el dispositivo empiece a enviar paquetes al packet forwarder de TTN usando la direcciĆ³n de servidor correspondiente.
ConfiguraciĆ³n del packet forwarder y parĆ”metros LoRaWAN
En la interfaz del gateway (menĆŗ LoRa Network ā Network Settings ā Packet Forwarder o similar) es donde se especifican los parĆ”metros de conexiĆ³n al servidor LoRaWAN. Esta secciĆ³n es el puente entre el mundo radio LoRa y el servidor de red.
El packet forwarder se configura indicando la direcciĆ³n del servidor (por ejemplo, el router de TTN o un router propio, como router.us.mokolora.network en despliegues de MOKO), asĆ como los puertos de subida y bajada (serv_port_up y serv_port_down). TambiĆ©n se puede activar o desactivar cada servidor configurado mediante un flag tĆpico como serv_enabled.
En gateways basados en MOKO y Raspberry Pi, muchos de estos parĆ”metros se almacenan en ficheros JSON como global_config.json y local_config.json, que definen respectivamente la configuraciĆ³n genĆ©rica de la regiĆ³n y los datos especĆficos de la puerta de enlace (ID, ubicaciĆ³n, servidores, etc.).
El fichero global_config.json suele incluir el bloque gateway_conf con ajustes de GPS y sincronizaciĆ³n, por ejemplo:
{"gateway_conf":{"GPS":true,"gps_tty_path":"/dev/ttyAMA0","fake_gps":false}}
Mientras que en local_config.json se guardan datos como el gateway_ID, coordenadas (ref_latitude, ref_longitude, ref_altitude), email de contacto, descripciĆ³n y el listado de servidores a los que se conecta el packet forwarder, cada uno con su server_address, serv_port_up, serv_port_down y serv_enabled.
GestiĆ³n de ficheros de configuraciĆ³n y gateway_ID
En sistemas tipo Raspberry Pi con MOKO, una parte interesante es cĆ³mo se genera y gestiona el gateway_ID. Normalmente, se calcula a partir de la direcciĆ³n MAC de la interfaz de red (por ejemplo, eth0) mediante un script que la transforma en un identificador EUI64, insertando āFFFEā en medio y elevando a mayĆŗsculas el resultado.
Ese gateway_ID se usa despuĆ©s en el fichero local_config.json para identificar de forma Ćŗnica la puerta de enlace ante el servidor LoRaWAN. AdemĆ”s, muchos despliegues reposan en un esquema de configuraciĆ³n remota basado en un repositorio GitHub donde se publican los global_config.json de cada regiĆ³n y los local_config.json de gateways concretos.
El mecanismo funciona asĆ: al arrancar, el concentrador LoRa descarga desde GitHub el fichero de configuraciĆ³n correspondiente a su gateway_ID, comprueba si hay cambios respecto al Ćŗltimo arranque y, si detecta una nueva versiĆ³n, la sincroniza creando un enlace simbĆ³lico desde bin/local_config.json hacia el archivo clonado del repositorio.
Si quieres aprovechar este sistema, puedes subir tu propio fichero de configuraciĆ³n al repositorio remoto, nombrĆ”ndolo con el gateway_ID (por ejemplo, MFP254862KEF1034.json), hacer un fork, enviar un pull request al repositorio principal y, una vez aceptado, tu gateway descargarĆ” automĆ”ticamente esa configuraciĆ³n en los siguientes arranques.
Esto permite actualizar parĆ”metros crĆticos (servidores, frecuencias, descripciĆ³n, datos de contacto) sin necesidad de acceder fĆsicamente a cada gateway, siempre que tenga conectividad a Internet y el software de sincronizaciĆ³n habilitado.
ConfiguraciĆ³n regional, canales y errores de frecuencia
Una parte que causa muchas dudas al configurar gateways LoRaWAN es la configuraciĆ³n regional de frecuencias. Cada paĆs o zona geogrĆ”fica tiene bandas especĆficas habilitadas para LoRa (por ejemplo, 868 MHz en Europa, 915 MHz en ciertas regiones de AmĆ©rica, etc.) y los servidores de red validan que los paquetes lleguen en frecuencias permitidas.
Los ficheros de configuraciĆ³n global para gateway (global_config.json) definen los canales y parĆ”metros de radio (frecuencias, ancho de banda, Spreading Factor, etc.) para cada regiĆ³n. En GitHub existen repositorios pĆŗblicos con configuraciones predefinidas para mĆŗltiples planes regionales, lo que simplifica mucho el despliegue.
Si la configuraciĆ³n de tu gateway no corresponde con la del servidor al que te conectas, puedes encontrarte errores del tipo: āPaquete RECHAZADO, frecuencia no compatibleā. Por ejemplo, que el gateway envĆe por 868.3 MHz mientras el servidor espera paquetes en un rango de 890-975 MHz, generando errores en el log del packet forwarder.
Para evitar estos fallos, asegĆŗrate de descargar el global_config.json correcto para tu regiĆ³n, y de que tu servidor (TTN, MOKO, AWS IoT Core) estĆ” configurado con el mismo plan de frecuencias. TambiĆ©n debes verificar que los nodos finales (trackers, sensores, etc.) usen la misma banda definida en el gateway y en el servidor.
En paĆses como China, por ejemplo, se emplean configuraciones especĆficas con bandas y canales distintos a los europeos, por lo que no basta con copiar cualquier ejemplo de Internet; hay que usar el fichero concreto asociado a tu Ć”rea geogrĆ”fica para que todo encaje.
ConexiĆ³n de gateways LoRaWAN con AWS IoT Core
En despliegues mĆ”s avanzados, puedes integrar tus gateways directamente con AWS IoT Core para LoRaWAN, utilizando las capacidades de la nube de Amazon para la gestiĆ³n de dispositivos, recolecciĆ³n de datos y procesamiento de mensajes.
El flujo general consiste en dar de alta la puerta de enlace en AWS IoT Core para LoRaWAN, obtener la informaciĆ³n necesaria (certificados, URLs de endpoints) y luego configurar el dispositivo de gateway para que se conecte al endpoint CUPS o LNS de AWS, segĆŗn el protocolo soportado.
SegĆŗn el tipo de gateway, la documentaciĆ³n del proveedor explicarĆ” cĆ³mo subir los certificados de confianza al dispositivo, cĆ³mo indicar las rutas a esos certificados en el firmware y cĆ³mo apuntar a las URLs de CUPS o LNS que te proporciona AWS. Es importante seguir al pie de la letra esa guĆa, puesto que la autenticaciĆ³n TLS es obligatoria.
En gateways compatibles con el protocolo CUPS, deberĆ”s especificar la URL del endpoint CUPS, que tendrĆ” un formato similar a: prefix.cups.lorawan.region.amazonaws.com:443. En gateways compatibles con LNS, la URL serĆ” algo como: https://prefix.lns.lorawan.region.amazonaws.com:443, siempre usando el puerto 443 y conexiĆ³n segura.
Una vez subidos los certificados y configurados los endpoints, el gateway empezarĆ” a comunicarse con AWS IoT Core para LoRaWAN y podrĆ”s comprobar su estado (conectado, Ćŗltimo uplink recibido, etc.) desde la consola web o mediante la API GetWirelessGatewayStatistics, que devuelve informaciĆ³n como ConnectionStatus y LastUplinkReceivedAt en formato JSON.
Uso de la consola y la API de AWS para monitorizar el estado del gateway
Tras conectar el gateway con AWS IoT Core para LoRaWAN, la plataforma ofrece varias formas de verificar que todo va fino. La mĆ”s inmediata es la consola web de AWS IoT, donde tienes una secciĆ³n especĆfica de Puertas de enlace.
Dentro de la consola, al seleccionar tu gateway en la pĆ”gina de Puertas de enlace, aparecerĆ” un bloque de Detalles especĆficos de LoRaWAN. AhĆ se muestra el estado de la conexiĆ³n, junto con la fecha y hora del Ćŗltimo enlace ascendente (uplink) recibido, permitiĆ©ndote comprobar de un vistazo si el gateway estĆ” activo y en comunicaciĆ³n con la nube.
Si prefieres automatizar la supervisiĆ³n, puedes usar la API GetWirelessGatewayStatistics. Esta operaciĆ³n no requiere un cuerpo de solicitud y devuelve un JSON en el que se indica, por ejemplo, ConnectionStatus (Connected/Disconnected), LastUplinkReceivedAt con marca de tiempo y el WirelessGatewayId correspondiente al dispositivo.
Un ejemplo de respuesta serĆa algo como: {"ConnectionStatus":"Connected","LastUplinkReceivedAt":"2021-03-24T23:13:08.476015749Z","WirelessGatewayId":"30cbdcf3-86de-4291-bfab-5bfa2b12bad5"}, que puedes integrar en tus herramientas de monitorizaciĆ³n o paneles personalizados.
De este modo, tanto desde la consola como desde la API dispones de formas muy claras de detectar fallos de conectividad, inactividad prolongada del gateway o problemas de configuraciĆ³n que impidan que los uplinks lleguen correctamente a AWS IoT Core.
Registro de aplicaciones y dispositivos finales en TTN
Volviendo al entorno de TTN, una vez que tienes el gateway operativo y registrado, aĆŗn te falta otro paso clave: dar de alta la aplicaciĆ³n y los dispositivos finales (nodos, trackers, sensores). Que el gateway aparezca como conectado en TTN no significa que ya estĆ©s recibiendo datos de tus nodos.
En la Consola de TTN, debes ir a la secciĆ³n āAplicacionesā y crear una nueva aplicaciĆ³n, asignĆ”ndole un nombre/ID. Dentro de esa aplicaciĆ³n, usarĆ”s el botĆ³n de āregistrar dispositivo finalā para dar de alta cada nodo.LoRaWAN. AllĆ podrĆ”s rellenar los datos de forma manual o basarte en plantillas, segĆŗn el tipo de dispositivo.
Entre los parĆ”metros clave estĆ”n DevEUI, JoinEUI (APP-EUI) y AppKey. Algunas herramientas, como la propia consola de TTN, permiten generar automĆ”ticamente DevEUI y AppKey mediante botones de generaciĆ³n, simplificando la puesta en marcha cuando usas nodos genĆ©ricos o desarrollos propios.
Para JoinEUI, en ciertos casos puedes establecer prĆ”cticamente cualquier valor siempre que lo mantengas coherente con la configuraciĆ³n del dispositivo (por ejemplo, en la herramienta Loko Configuration Tool, el parĆ”metro APP-EUI se corresponde con JoinEUI en TTN). El resto de claves deben coincidir exactamente entre la consola y el firmware del nodo.
Una vez registrado el dispositivo final, podrĆ”s ir a la secciĆ³n de formateadores de carga Ćŗtil y elegir opciones como CayenneLPP para la decodificaciĆ³n de los uplinks. Esto permite representar los datos en formatos mĆ”s amigables y facilitar la integraciĆ³n con dashboards, bases de datos y sistemas de visualizaciĆ³n.
Ejemplo prĆ”ctico con trackers y herramientas de configuraciĆ³n
Un caso real bastante habitual es el uso de trackers GPS LoRaWAN para localizar personas, vehĆculos o activos, enviando sus coordenadas periĆ³dicamente a travĆ©s de la red. Dispositivos como los Dragino TrackerD o unidades Loko Air ilustran muy bien este flujo.
En un entorno educativo, por ejemplo, se pueden registrar varios trackers bajo una misma aplicaciĆ³n en TTN, aprovechando que cada uno viene con credenciales Ćŗnicas (DevEUI, AppEUI/JoinEUI, AppKey) que se documentan en su manual o en la etiqueta del dispositivo. Todos se asocian a la misma aplicaciĆ³n pero se identifican individualmente.
Para configurar parĆ”metros avanzados del tracker (frecuencia de envĆo de coordenadas, duraciĆ³n de la alarma de pĆ”nico, etc.), se puede conectar el dispositivo por USB y usar una interfaz serie a 115200 baudios, enviando comandos AT predefinidos. En algunos modelos no se aceptan entradas ātecla a teclaā, sino que hay que pegar el comando completo de golpe para que sea interpretado correctamente.
En el caso de unidades como Loko Air, la herramienta Loko Configuration Tool permite leer la configuraciĆ³n actual, habilitar el modo LoRaWAN y rellenar los tres parĆ”metros esenciales (JoinEUI/AppEUI, DevEUI y AppKey) de forma que casen con la informaciĆ³n de activaciĆ³n del dispositivo final en The Things Network.
Tras aplicar la configuraciĆ³n y reiniciar el dispositivo, si la puerta de enlace estĆ” funcionando correctamente y se encuentra dentro del alcance, deberĆas empezar a ver trĆ”fico en vivo en la secciĆ³n de End Devices de TTN, incluyendo mensajes con payloads decodificados y la ubicaciĆ³n del tracker en el mapa si el formato lo permite.
AdemĆ”s, la informaciĆ³n que aparece en la consola de TTN puede integrarse en dashboards pĆŗblicos como Datacake, que permiten convertir los datos brutos de LoRaWAN en visualizaciones amigables para usuarios finales, paneles compartibles o cuadros de mando para proyectos educativos y pilotos de IoT.
Con todo este recorrido, desde el hardware hasta la nube, pasando por TTN, AWS y la configuraciĆ³n fina de radio, se puede ver que una puerta de enlace LoRaWAN no es solo āuna antenaā, sino el punto neurĆ”lgico que conecta el mundo fĆsico de los sensores con las plataformas de datos donde realmente se genera el valor del proyecto.
PƔrrafo final
Una vez conocidos los engranajes internos āhardware tipo RAK831 o RAK7289, ficheros global_config y local_config, sincronizaciĆ³n remota vĆa GitHub, configuraciĆ³n IP y desactivaciĆ³n de Wi-Fi de gestiĆ³n, alta y parametrizaciĆ³n en TTN, conexiĆ³n segura con AWS IoT Core y registro de aplicaciones y dispositivos finales como trackers GPS o unidades Loko Airā resulta mucho mĆ”s sencillo entender que la configuraciĆ³n de una puerta de enlace LoRaWAN es solo la suma ordenada de varios pasos lĆ³gicos, donde la clave estĆ” en respetar el plan de frecuencias regional, alinear IDs y claves entre gateway, servidor y nodos, y apoyarse en las consolas y APIs de los distintos servicios para verificar en todo momento que los uplinks estĆ”n llegando y que la infraestructura LoRaWAN se comporta como esperas en tu despliegue real.