Assemble and finely chop the Configuring a LoRaWAN gateway It might seem a little daunting at first: radio parameters, networks, servers, certificates, strange IDs… but in reality, if you understand each piece, it's quite a logical process. In this article, we'll go from the hardware to the LoRaWAN server, including TTN and AWS IoT Core, to give you a complete and practical overview.
We will rely on real-world examples such as RAK gateways (RAK7289, RAK831)Public networks like The Things Network (TTN), cloud solutions like AWS IoT Core for LoRaWAN, and manufacturer configurations like MOKO will all be covered. We'll weave all this content into a coherent guide, including security warnings, tips for finding the gateway's IP address, and detailed network and radio configuration information.
Basic concepts: what a LoRaWAN gateway is and what it does
An LoRaWAN gateway It's the device responsible for listening to the LoRa nodes (sensors, trackers, etc.) and forwarding their messages to a LoRaWAN network server over the internet (Ethernet, Wi-Fi, LTE/4G, 5G, satellite, etc.). You can think of it as a kind of cell phone tower but for very low power devices.
At the physical level, the gateway integrates one or more LoRa concentrators (such as the RAK831) capable of monitoring multiple channels in parallel and different Spreading Factors, a control board (e.g., Raspberry Pi or an embedded SoC), network interfaces (Ethernet, Wi-Fi, LTE), and often, GPS for synchronization and approximate geolocation of the nodes.
In the LoRaWAN ecosystem, the gateway does not interpret the content of application frames: simply encapsulate and forward The packet forwarder sends packets to the LoRaWAN server (LNS: LoRaWAN Network Server) or to the CUPS/LNS cloud infrastructure. Therefore, the key configuration revolves around radio parameters, gateway identifiers, and the address of the server to which the data will be sent.
Depending on the deployment, you will be able to use public gateways (for example, those in the TTN community in urban areas) or set up your own gateway to cover a rural area, a farm, an educational campus or an industrial environment where you need total control of the infrastructure.
Typical hardware of a LoRaWAN gateway
To build or deploy a gateway, you have options ranging from closed commercial devices to Raspberry Pi-based development kitsA fairly representative example is the use of an integrated RAK831 hub with a Raspberry Pi.
A typical LoRa gateway kit of this style usually includes all the necessary hardware components To get started without having to search for individual parts: the LoRaWAN concentrator board itself, the motherboard, antennas, and adapters. This greatly speeds up the setup process and avoids compatibility issues.
In the specific case of some MOKO kits based on RAK831 and Raspberry Pi 3B, the package may include, among other items, a GPS adapter plateGPS antenna, fiberglass LoRa antenna with sufficient gain for mast installations, several meters of RG-58 coaxial cable, heat sink for the concentrator board and even example nodes such as WisNode or LoRa trackers.
The great advantage of these kits is that the Raspberry Pi memory card usually comes preconfigured with gateway software (packet forwarder, configuration scripts, etc.), so you don't have to compile or download anything from GitHub to get started, beyond tweaking a few configuration files.
In commercial gateways such as the RAK7289All the hardware is integrated into an industrial-grade, outdoor-ready enclosure, with a LoRa antenna and, sometimes, an additional antenna for LTE/4G. These models typically offer a fairly guided web configuration interface, so the work focuses on network parameters (IP, DNS, etc.) and pointing the gateway to the correct LoRaWAN server.
Gateway network configuration: Static IP, DHCP, and initial access
Before you can touch the LoRaWAN part, you must make sure that the The gateway is properly connected to the IP network (LAN or WAN). Without internet connectivity (or to your local server), it's pointless for the radio to work properly.
In many gateways (for example, the RAK7289), the administration interface is presented via the web and accessed through its IP address on the networkYou can configure it as a DHCP client (which obtains an IP address automatically from the router) or with a static IP address depending on your network topology.
If the device came from the factory or was configured by another organization, it may be in mode DHCP clientIn that case, you'll need to find out what IP address your router or network's DHCP server has assigned. To do this, you can:
- Consult directly the DHCP client list on the router or server, identifying the gateway by its MAC or by the hostname (for example, “RAK7289”).
- Use tools like Nmap or other IP scanners to discover which devices are responding on your network segment.
Some gateways include a management Wi-Fi access point Open, designed specifically for that initial setup. If you connect to that Wi-Fi network, the gateway acts as a router, and the default gateway IP on your computer will be the device's management IP.
An important safety detail: once you have finished the start-up, it is advisable disable management Wi-Fi unless strictly necessary, since an open, managed Wi-Fi network poses a clear vulnerability in real-world environments.
In the configuration interface (for example, in the Network → WAN Interface menu of a RAK gateway), you can choose between static IP and DHCP, define DNS, subnet mask, gateway, as well as change the access credentials by default (username and password) that you should never leave as they come from the factory.
Gateway setup and configuration in The Things Network (TTN)
Once your gateway has internet access, the next step in many community or lab deployments is integrate it with TTN (The Things Network), a free and public LoRaWAN network ideal for educational projects, testing and small deployments.
The usual process begins by creating an account on the TTN website and accessing the Console From the profile icon. When you log in for the first time, the system will ask you to choose your region (for example, Europe, North America, etc.), and from there you can go to the "Applications" or "Gateways" section. To register the gateway, you will need to go specifically to "Go to Gateways".
On the TTN Console, when you press the button Register gatewayYou will be asked for several pieces of information: a gateway ID, its unique EUI, and the frequency plan for your region. The Gateway EUI is usually available in the device's web interface or firmware, typically in the LoRa network settings section.
It is essential that the The Gateway ID you define in TTN must match the one configured on the device.especially if the manufacturer's documentation requires it. Additionally, you will need to select the appropriate frequency plan (for example, EU868 for Europe), which defines the available channels and radio parameters compatible with your country's regulations.
Once the gateway is registered with TTN, the configuration in the Console is almost complete. TTN will show you the gateway's status (connected or not) when the device starts sending packets to the TTN packet forwarder using the corresponding server address.
Packet forwarder configuration and LoRaWAN parameters
The gateway interface (LoRa Network menu → Network Settings → Packet Forwarder or similar) is where the LoRaWAN server connection parametersThis section is the bridge between the LoRa radio world and the network server.
The packet forwarder is configured by specifying the Server address (for example, the TTN router or a custom router, such as router.us.mokolora.network in MOKO deployments), as well as the upstream and downstream ports (serv_port_up and serv_port_down). Each configured server can also be enabled or disabled using a typical flag such as serv_enabled.
In MOKO and Raspberry Pi-based gateways, many of these parameters are stored in JSON files such as global_config.json y local_config.json, which respectively define the generic region configuration and the specific gateway data (ID, location, servers, etc.).
The global_config.json file usually includes the gateway_conf block with settings for GPS and synchronization, For example:
{"gateway_conf":{"GPS":true,"gps_tty_path":"/dev/ttyAMA0","fake_gps":false}}
While local_config.json stores data such as gateway_ID, coordinates (ref_latitude, ref_longitude, ref_altitude), contact email, description and the list of servers to which the packet forwarder connects, each with its server_address, serv_port_up, serv_port_down and serv_enabled.
Configuration file management and gateway_ID
In Raspberry Pi-type systems with MOKO, an interesting aspect is how it generates and manages the gateway_IDIt is usually calculated from the MAC address of the network interface (e.g., eth0) using a script that transforms it into an EUI64 identifier, inserting "FFFE" in between and capitalizing the result.
This gateway_ID is then used in the local_config.json file to uniquely identify the gateway to the LoRaWAN server. Furthermore, many deployments rely on a scheme of remote configuration based on a GitHub repository where the global_config.json files for each region and the local_config.json files for specific gateways are published.
The mechanism works like this: upon startup, the LoRa concentrator downloads the configuration file corresponding to its gateway_ID from GitHub, checks for changes since the last startup, and if it detects a new version, synchronizes it by creating a symbolic link from bin/local_config.json to the cloned repository file.
If you want to take advantage of this system, you can Upload your own configuration file to the remote repositoryby naming it with the gateway_ID (for example, MFP254862KEF1034.json), fork it, send a pull request to the main repository and, once accepted, your gateway will automatically download that configuration on subsequent startups.
This allows critical parameters (servers, frequencies, description, contact details) to be updated without physically accessing each gateway, provided it has internet connectivity and the synchronization software enabled.
Regional settings, channels, and frequency errors
One aspect that causes many questions when configuring LoRaWAN gateways is the regional frequency configurationEach country or geographical area has specific bands enabled for LoRa (for example, 868 MHz in Europe, 915 MHz in certain regions of America, etc.) and network servers validate that the packets arrive on permitted frequencies.
The global configuration files for gateway (global_config.json) define the radio channels and parameters (frequencies, bandwidth, Spreading Factor, etc.) for each region. Public repositories with predefined configurations for multiple regional plans are available on GitHub, which greatly simplifies deployment.
If your gateway configuration does not match that of the server you are connecting to, you may encounter errors such as: “Packet REJECTED, frequency not compatible”For example, the gateway might send packets on 868.3 MHz while the server is waiting for packets in the 890-975 MHz range, generating errors in the packet forwarder log.
To avoid these errors, make sure you download the global_config.json correct for your regionand that your server (TTN, MOKO, AWS IoT Core) is configured with the same frequency plan. You should also verify that the end nodes (trackers, sensors, etc.) use the same band defined on the gateway and the server.
In countries like China, for example, specific configurations with different bands and channels than those used in Europe are employed, so it's not enough to simply copy any example from the internet; you have to use the specific file associated with your geographical area so that everything fits together.
Connecting LoRaWAN gateways to AWS IoT Core
In more advanced deployments, you can integrate your gateways directly with AWS IoT Core for LoRaWAN, using Amazon's cloud capabilities for device management, data collection, and message processing.
The general flow consists of registering the gateway in AWS IoT Core for LoRaWAN, obtaining the necessary information (certificates, endpoint URLs), and then configuring the gateway device to connect to the CUPS or LNS endpoint from AWS, according to the supported protocol.
Depending on the type of gateway, the vendor's documentation will explain how upload the trust certificates The guide explains how to specify the paths to these certificates in the firmware and how to point them to the CUPS or LNS URLs provided by AWS. It's important to follow this guide precisely, as TLS authentication is mandatory.
On gateways compatible with the CUPS protocol, you will need to specify the CUPS endpoint URL, which will have a format similar to: prefix.cups.lorawan.region.amazonaws.com:443. On gateways compatible with LNS, the URL will be something like: https://prefix.lns.lorawan.region.amazonaws.com:443, always using the 443 port and secure connection.
Once the certificates have been uploaded and the endpoints configured, the gateway will begin communicating with AWS IoT Core for LoRaWAN and you can check its status (connected, last uplink received, etc.) from the web console or via the GetWirelessGatewayStatistics API, which returns information such as ConnectionStatus and LastUplinkReceivedAt in JSON format.
Using the AWS console and API to monitor gateway status
After connecting the gateway to AWS IoT Core for LoRaWAN, the platform offers several ways to verify that everything is working properly.The most immediate option is the AWS IoT web console, where you have a specific Gateways section.
Within the console, when you select your gateway on the Gateways page, a block will appear Specific details of LoRaWANThere you can see the connection status, along with the date and time of the last uplink received, allowing you to check at a glance whether the gateway is active and communicating with the cloud.
If you prefer to automate monitoring, you can use the GetWirelessGatewayStatistics APIThis operation does not require a request body and returns a JSON that indicates, for example, ConnectionStatus (Connected/Disconnected), LastUplinkReceivedAt with timestamp and the WirelessGatewayId corresponding to the device.
An example of a response would be something like: {"ConnectionStatus":"Connected","LastUplinkReceivedAt":"2021-03-24T23:13:08.476015749Z","WirelessGatewayId":"30cbdcf3-86de-4291-bfab-5bfa2b12bad5"}, which you can integrate into your monitoring tools or custom dashboards.
In this way, both from the console and from the API you have very clear ways to detect connectivity failuresprolonged gateway inactivity or configuration problems that prevent uplinks from reaching AWS IoT Core correctly.
Registration of applications and end devices in TTN
Returning to the TTN environment, once you have the gateway operational and registered, there is still one more key step: register the application and the end devices (nodes, trackers, sensors). Just because the gateway appears as connected in TTN doesn't mean you're already receiving data from your nodes.
In the TTN Console, go to the “Applications” section and create a new application, assigning it a name/ID. Within that application, you will use the button of “register end device” To register each LoRaWAN node, you can fill in the data manually or use templates, depending on the type of device.
Key parameters include DevEUI, JoinEUI (APP-EUI) and AppKeySome tools, such as TTN's own console, allow Automatically generate DevEUI and AppKey through generation buttons, simplifying the start-up when using generic nodes or custom developments.
For JoinEUI, in certain cases you can set virtually any value as long as you keep it consistent with the device settings (For example, in the Loko Configuration Tool, the APP-EUI parameter corresponds to JoinEUI in TTN). The remaining keys must match exactly between the console and the node firmware.
Once the final device is registered, you can go to the payload formatters section and choose options such as CayenneLPP for uplink decoding. This allows data to be represented in more user-friendly formats and facilitates integration with dashboards, databases, and visualization systems.
Practical example with trackers and configuration tools
A fairly common real-world example is the use of LoRaWAN GPS trackers to locate people, vehicles, or assets by periodically sending their coordinates over the network. Devices like the Dragino TrackerD or Loko Air units illustrate this process very well.
In an educational setting, for example, several trackers can be registered under the same application in TTN, taking advantage of the fact that each one comes with unique credentials (DevEUI, AppEUI/JoinEUI, AppKey) which are documented in your manual or on the device label. They are all associated with the same application but are individually identified.
To configure advanced tracker parameters (frequency of sending coordinates, duration of the panic alarm, etc.), the device can be connected via USB and a serial interface can be used at 115200 baud, sending predefined AT commandsSome models do not accept "key by key" inputs; instead, the entire command must be typed at once to be interpreted correctly.
In the case of units like Loko Air, the tool Loko Configuration Tool It allows you to read the current configuration, enable LoRaWAN mode, and fill in the three essential parameters (JoinEUI/AppEUI, DevEUI, and AppKey) so that they match the activation information of the end device in The Things Network.
After applying the settings and restarting the device, if the gateway is working correctly and is within range, you should start to see live traffic in the End Devices section of TTN, including messages with decoded payloads and the tracker's location on the map if the format allows it.
Furthermore, the information displayed in the TTN console can be integrated into public dashboards such as Datacakewhich allow converting raw LoRaWAN data into user-friendly visualizations, shareable dashboards, or scoreboards for educational projects and IoT pilots.
With this entire journey, from hardware to the cloud, including TTN, AWS, and fine-tuning the radio configuration, it's clear that a LoRaWAN gateway is not just "an antenna," but the nerve center that connects the physical world of sensors with the data platforms where the project's value is actually generated.
Final paragraph
Once the internal workings are understood—RAK831 or RAK7289 hardware, global_config and local_config files, remote synchronization via GitHub, IP configuration and disabling of management Wi-Fi, TTN setup and parameterization, secure connection with AWS IoT Core, and registration of applications and end devices such as GPS trackers or Loko Air units—it becomes much easier to understand that the Configuring a LoRaWAN gateway It is simply the ordered sum of several logical steps, where the key is to respect the regional frequency plan, align IDs and keys between gateway, server and nodes, and rely on the consoles and APIs of the different services to verify at all times that the uplinks are arriving and that the LoRaWAN infrastructure behaves as you expect in your actual deployment.