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.