A Milesight gateway is a packet forwarder, not a network server. The radio receives LoRaWAN frames from sensors in range and forwards the raw bytes to ChirpStack, which handles the join, the MAC layer and the routing. Three things matter for the link to work: the forwarder protocol, the region, and the gateway being registered with the right EUI. The gateway never decodes the sensor payload, that is the job of the ChirpStack payload decoder on the device profile.
Milesight Gateway with ChirpStack: Connect UG65, UG67 and UG56
Connect a Milesight UG65, UG67 or UG56 to ChirpStack v4: Semtech UDP vs embedded MQTT Forwarder vs Basics Station, the Gateway Bridge and EU868.
Architecture
The data flow
A Milesight UG65, UG67 or UG56 forwards raw LoRaWAN frames to your network server. This guide shows the three ways it can reach ChirpStack v4, the role of the Gateway Bridge, the EU868 topic prefix and how to register the gateway so frames actually arrive.
Sensor / controller
Measures or controls in the field and sends LoRaWAN uplinks.
LoRaWAN gateway
Receives the radio packets and forwards them to the server.
ChirpStack
Network server: manages sessions and decodes the payload.
ThingsBoard / Grafana
Dashboards, alarms, rules and reports.
What the gateway actually does
Three ways a Milesight gateway reaches ChirpStack
Milesight UG65, UG67 and UG56 gateways offer the same forwarding options in their web UI:
- Embedded ChirpStack MQTT Forwarder. The gateway publishes frames straight to your MQTT broker over TCP, with TLS and authentication. This is the most robust path and needs no separate Gateway Bridge process. Recommended for self-hosted ChirpStack v4.
- Semtech UDP packet forwarder. The classic protocol: a pseudo-JSON message over UDP to port 1700. Maximum compatibility, but no encryption and no delivery guarantee, so a lost UDP packet is simply gone. It requires a ChirpStack Gateway Bridge to translate UDP into MQTT.
- Basics Station. Semtech's modern LNS protocol over a secured WebSocket. A good middle ground, also handled by the Gateway Bridge.
Where the Gateway Bridge fits
ChirpStack does not ingest Semtech UDP or Basics Station directly. The ChirpStack Gateway Bridge sits between the forwarder and the network server: it converts those protocols into MQTT (Protobuf or JSON) on a known topic structure. In a standard ChirpStack v4 install the Bridge runs alongside the server, so you usually do not deploy it separately. When the gateway uses the embedded MQTT Forwarder it publishes to the broker itself and the Bridge is bypassed entirely.
Sensors ──LoRaWAN RF──> Milesight UG65/UG67/UG56
│
┌─────────────────────┼──────────────────────┐
│ Semtech UDP :1700 │ Basics Station (WSS) │ Embedded MQTT Forwarder
▼ ▼ │
ChirpStack Gateway Bridge ───┘ │
│ MQTT (Protobuf/JSON) │
▼ ▼
MQTT broker ──> ChirpStack v4 Network Server
Semtech UDP: point the gateway at the Bridge
If you use the Semtech UDP packet forwarder, the gateway needs only the server address and the up/down ports. Both default to 1700, the port the Gateway Bridge listens on. On the gateway side (or in the embedded lora-packet-forwarder config) the relevant lines are:
{
"gateway_conf": {
"gateway_ID": "24E124FFFEF54092",
"server_address": "chirpstack.example.eu",
"serv_port_up": 1700,
"serv_port_down": 1700,
"keepalive_interval": 10,
"stat_interval": 30
}
}
The gateway_ID is the Gateway EUI, the same value you register in ChirpStack. Milesight prints it on the label and shows it in the UI; it is also derived from the gateway MAC.
EU868 region and the topic prefix
The gateway band and the ChirpStack region must agree. For Europe that is EU868. ChirpStack v4 prefixes every gateway event topic with the region, which is the single most common reason a freshly connected gateway shows nothing. The topic is:
eu868/gateway/{GatewayEUI}/event/up
eu868/gateway/{GatewayEUI}/event/stats
eu868/gateway/{GatewayEUI}/command/down
If you debug with an MQTT client, subscribe to the prefixed wildcard, not the bare one:
mosquitto_sub -h chirpstack.example.eu -t 'eu868/gateway/+/event/+' -v
A subscription to gateway/# alone returns nothing, because the region prefix is part of the topic.
Register the gateway in ChirpStack
In ChirpStack, go to Gateways, Add gateway and enter the Gateway EUI exactly as shown on the device. Set the same EU868 region. Once the forwarder is running and the EUI matches, the Gateway events tab shows live stats and up frames. From there, uplinks flow into your applications, get decoded on the device profile, and forward onward, for example to ChirpStack to ThingsBoard.
Pitfalls from the field
- Region prefix: ChirpStack v4 prefixes topics with the region (
eu868/...). Subscribing without it means no frames. This trips up almost every first setup. - EUI mismatch: The Gateway EUI in the forwarder config must match the one registered in ChirpStack, character for character. A typo means frames arrive but get dropped as from an unknown gateway.
- UDP has no retries: Semtech UDP silently drops lost packets. On a flaky backhaul, prefer the MQTT Forwarder or Basics Station.
- Firewall: Semtech UDP needs port 1700 reachable; the MQTT Forwarder needs the broker port (commonly 8883 for TLS) open outbound from the gateway.
- Gateway is not a server: A gateway with no network server reachable still powers on and shows green LEDs. Online does not mean connected to ChirpStack.
Hardware pages and managed hosting
The right gateway depends on the site: the indoor Milesight UG65 and the compact UG56 cover offices and buildings, while the outdoor UG67 is built for rooftops and yards. Each page lists the supported forwarder modes and bands. A rooftop gateway feeding ChirpStack is the usual backbone for a smart city deployment, where many sensors share one network server. We register your gateway, set the EU868 region and broker, and operate the network server as ChirpStack managed hosting on European infrastructure.
Frequently asked questions
The embedded ChirpStack MQTT Forwarder is the most robust because it runs over TCP with TLS and authentication. Semtech UDP is the simplest and most compatible but has no encryption and no delivery guarantee. Basics Station is the modern LNS protocol and a good middle ground. For a self-hosted ChirpStack we default to the MQTT Forwarder.
Only if the gateway sends raw Semtech UDP or Basics Station frames. The Gateway Bridge converts those into MQTT for the network server and ships inside the standard ChirpStack v4 deployment. With the embedded MQTT Forwarder the gateway publishes to the broker directly, so no separate Bridge process is needed.
The two usual causes are a region mismatch and the topic prefix. The gateway band must match the ChirpStack region (EU868 here), and ChirpStack v4 prefixes gateway event topics with the region, for example eu868/gateway/+/event/up. A broker subscription on gateway/# alone receives nothing.
No. The gateway only forwards raw LoRaWAN frames. Decoding the binary payload into JSON happens on the device profile codec in ChirpStack, not on the gateway. The two jobs are separate.
Yes. The gateway forwards every frame it hears regardless of application. ChirpStack routes each uplink to the right application by the device session, so a single UG65 can backhaul many applications and tenants at once.
Yes. We run ChirpStack v4 on European infrastructure, register your UG65, UG67 or UG56, set the EU868 region and broker, and confirm frames arrive. You keep ownership of the network and the data.
Let's discuss your infrastructure. Digital and on-site.
Whether it's IoT platform development, hardware selection, managed hosting for ChirpStack, ThingsBoard, Grafana or NetBird VPN, or migration from a self-hosted setup - we'll find the right solution for your use case. Book a free 30-minute consultation, no commitment required.
Your contact
Timo Wevelsiep
Founder, merkaio
15 minutes, no commitment, directly with Timo.
merkaio is an independent integrator and is not affiliated with Milesight.