How to add multiple SenseCAP M2 gateways to a Chirpstack LNS

Products & Technology SenseCAP
1

Hello,

I am wondering what is the best method for adding multiple remote SenseCAP M2 gateways to a Chirpstack LNS that is running on my primary SenseCAP M2 gateway. My understanding is that the remote gateways should be configured as a LoRa Basics station, and then they would forward their data to the LNS once they query and receive the LNS/CUPS server URL. Based on the documentation:

“First, the Station queries the LNS for the URI of the actual connection endpoint of the LNS. Second, it establishes a data connection with that endpoint to receive setup information. From then on, LoRa® uplink and downlink frames are exchanged through that connection.”

My question is, how can I make the initial query to the LNS? does the LNS need to have a static IP address if not on the same local network? Apologies if these are basic questions, I am still new to LoRaWAN network topology and just purchased my second SenseCAP M2 gateway with the intent of creating a larger mesh style network.

Thanks, any suggestions or help on this topic is greatly appreciated.

2

Great questions, You’re thinking along the right lines, and it’s entirely reasonable to want a “mesh-style” network of multiple SenseCAP M2 gateways all feeding into a central ChirpStack LNS.

Here is a walk through how the multiple-gateway setup works (and where the “LNS query” fits) along with the static vs dynamic IP question, plus some practical tips and caveats (especially given the M2 hardware/firmware status).

1. How Basics Station / LNS connections work

You already quoted the key part of the protocol:

“First, the Station queries the LNS for the URI of the actual connection endpoint … Second, it establishes a data connection with that endpoint to receive setup information. From then on, LoRa uplink and downlink frames are exchanged through that connection.”

This describes how a gateway operating in Basics Station mode (i.e., the protocol defined by LoRa Basics Station) connects to the network server (LNS). The logic is:

  • The gateway contacts the LNS (or a CUPS server) to get its configuration (endpoint, TLS certs, etc.).
  • It then opens a WebSocket (or other defined link) to send frames (uplinks) and receive downlinks.
  • The network server side (ChirpStack in your case) must support the Basics Station backend.

So for each “remote” gateway you’d configure it in Basics Station mode, tell it how to find the LNS (or CUPS) URL, and once connected, it behaves like any other gateway: forwarding uplinks & downlinks to ChirpStack.

2. How this fits your topology of “multiple remote gateways → central gateway with ChirpStack running”

Here’s how you can map it out:

  • Your “primary” SenseCAP M2 gateway is running ChirpStack (or you’ve installed ChirpStack or Gateway Bridge on it) — so it acts as your LNS / Network Server.
  • The remote M2 gateway(s) act as gateways in Basics Station mode, and they connect over IP (internet or LAN) to the “primary” gateway’s LNS endpoint.
  • Each remote gateway is configured with the URL of the LNS (or a CUPS + LNS combo) pointing to your central server.
  • They then forward any LoRaWAN end-device traffic they receive to your central server, which treats them as real gateways.

In other words: yes, you can have a fleet of M2 gateways forwarding into one ChimStack LNS – as long as each remote gateway can reach the server and you set them up accordingly.

3. Making the “initial query” to the LNS

Your question: “How can I make the initial query to the LNS? Does the LNS need to have a static IP address if not on the same local network?”

  • The “initial query” is built into the Basics Station protocol. The remote gateway, when booting/configured, will be given the CUPS or LNS URL. The gateway will connect to that, authenticate (TLS + token etc.), and request the endpoint. You don’t manually send a separate “query” – you configure the gateway with the URL and credentials and it handles it. For example, in a forum someone describes:

“In LORA tab: put SenseCAP on Basics Station mode … LNS URI: wss://eu1.cloud.thethings.network:8887 … Authentication mode TLS … trust field … token field…”

  • The key point: the gateway needs to know where to connect (URL / hostname). So from the server side you must have a reachable URL. That means:
    • If your central LNS is inside your LAN only, remote gateways outside cannot connect unless you expose it (port forwarding, VPN, etc.).
    • If your LNS is reachable from the public internet (or accessible via private WAN/VPN) then remote gateways can reach it.
    • A static IP or at least a stable hostname (DNS) helps—they don’t necessarily need a fixed static IP if you use a DNS name that resolves to wherever the LNS is. But it must be reliably reachable.
  • So, yes: if any remote gateway is not on the same LAN, then the LNS endpoint must be reachable over network (internet or secure tunnel). A static IP or a domain name with dynamic DNS would ensure that your remote gateways can always find it.

4. Practical steps for your setup

Given your scenario (two M2 gateways, one central server + possibly more later), here are steps and tips:

A. Ensure ChirpStack on your primary gateway is properly configured

  • Confirm that the LNS (ChirpStack Network Server) is up and accessible from the network (LAN or WAN).
  • You’ll have to open or forward the needed ports (depending on Basics Station, usually WebSocket port e.g. 8887 or as configured).
  • Use a stable hostname or IP for your LNS URL. If your gateway is on dynamic IP, use a DDNS.
  • In ChirpStack, ensure the Basics Station backend is enabled. The docs: “The Semtech Basics Station backend implements the LNS protocol. It exposes a websocket handler to which Basic Station powered gateways can connect.”

B. Configure each remote M2 gateway

  • In the web UI of the remote M2 (SenseCAP), go to LoRa → LoRa network (or Basics Station settings) and set mode = Basics Station.
  • Enter the LNS URI (wss://yourhostname:port) and any token credentials, TLS trust etc. (The M2 supports this, see docs: “put SenseCAP on Basics Station mode … LNS URI … trust field … token field …” )
  • Make sure the region / frequency plan / channel plan matches your network and end-devices.
  • Save and apply. Watch the status in ChirpStack: in Gateways → “Last seen” timestamp should update when remote gateway connects.

C. Check connectivity & firewall

  • If remote gateway won’t connect: check that the gateway can reach your LNS hostname/port (e.g., from the remote site ping / curl / log).
  • Ensure firewalls / NAT / port forwarding permit websockets / TLS connections inbound on your server.
  • If you use a domain name, ensure certificates/trust are correct (gateway may reject if TLS certificate chain invalid).
  • On the server side, verify logs for Basics Station gateway connections (see docs: under “Connecting a Gateway” there is guidance).

D. Scaling up / future gateways

  • Use the same configuration template for each new gateway (just change Gateway ID / EUI).
  • In ChirpStack, add each gateway under Gateways so you can monitor them.
  • Ensure end-devices know which gateway IDs to expect (the network server sees which gateway forwarded which data).
  • Consider using VLANs or secure tunnels (VPN) if your remote gateways are in different physical locations for security.

5. Some caveats specific to SenseCAP M2 and reality check

  • The SenseCAP M2 documentation says it supports multiple LNS (AWS, TTN, ChirpStack) via Packet Forwarder / Basics Station mode.
  • However, some users report limitations depending on the firmware variant. For example:

“The SenseCAP M2 Data Only gateway only supports Helium… so at the moment you can’t configure your gateway to connect to the ChirpStack server.”
So you’ll want to check exactly which firmware your M2 has and whether the Basics Station mode/LNS support is fully enabled.

  • There’s an alternate path: you can flash the device with the open-source firmware (like “ChirpStack Gateway OS”) if you want full control.
  • Because you’re planning a “mesh-style” network, you might consider whether each remote gateway is simply acting as a forwarder or you want them to do some kind of “relay” or “router” behaviour. Usually gateways are dumb forwarders and don’t pass data gateway-to-gateway — the mesh topology is “multiple gateways → single server” not “gateway-1 → gateway-2 → server”.
  • Ensure that you have proper coverage planning: remote gateways must not interfere (channel overlap etc) and your central server must handle the traffic load (multiple gateways, many end-devices).

6. Summary answer to your direct questions

  • How do you make the initial query to the LNS?
    You configure the remote gateway with the LNS (or CUPS) URL and credentials; the Basics Station protocol takes care of querying the server for endpoint info. You don’t manually send a separate query outside what the gateway firmware does.
  • Does the LNS need to have a static IP if not on the same network?
    You don’t strictly need a static IP, but you do need a reachable, stable address (IP or DNS hostname) for the remote gateways to connect to. If the server’s public IP changes frequently then yes, you’d better use a DNS name or dynamic DNS. If the server is behind NAT/firewall you’ll need port forwarding or VPN.
  • Can you add multiple remote gateways?
    Yes — each remote M2 gateway can connect in Basics Station mode to the central ChirpStack LNS, and you treat each as a separate gateway in ChirpStack.
  • Anything special for your SenseCAP M2 setup?
    Make sure the firmware supports Basics Station (LNS) mode, confirm TLS/trust and token configuration, ensure frequency/region matches, and verify network reachability (ports open etc).

BTW :grin: :ok_hand:
AI can make you a ready-to-use configuration checklist for SenseCAP M2 → ChirpStack (covering LNS URI, token, firewall settings, region settings) — just ask it to.

HTH
GL :grin: PJ :v: