Chirpstack on Google IOT Core

Hi All,

Hello, this is my first post.

I’ve been researching a Lora Network solution for a large number of class A devices. Chirpstack looks to meet most requirements, although I do need to confirm some assumptions. Apologies if the following questions have been answered in documentation or the forum, I could not find or interpret a definitive answer. I want to make absolutely sure I am armed with the right information to make the right architectural decisions. Please bare with me…

1/ LoraWan Gateways are provided to us by a 3rd party and do not allow for the gateway bridge to be installed. This means running a server side bridge. The relationship between each gateway and gateway bridge appears to be one-to-one, so if there are 50 gateways there would need to be 50 gateway bridge instances.

2/ To avoid hosting multiple instances of the gateway bridge, the code can be modified to allow for:
(a) a many-to-one relationship between gateways and the device in Google IOT core.
(b) a sync mechanism to check & create devices in IOT core.

a snippet from ‘internal/integration/mqtt/backend.go’ looks to contain the current logic, has anyone tried to do either (a) or (b)?:

            conf.Integration.MQTT.EventTopicTemplate = "/devices/gw-{{ .GatewayID }}/events/{{ .EventType }}"
            conf.Integration.MQTT.CommandTopicTemplate = "/devices/gw-{{ .GatewayID }}/commands/#"

3/ Currently we are testing Chirpstack using the docker-compose package. The longer term design will be to host two Kubernetes clusters behind a load balancer. Some posts claim Kompose can convert the Docker-compose setup without much involvement, any insights on this would be extremely helpful.

All information to allow me to make an informed decision would be extremely helpful and appreciated.

Kind regards,

you’re not need to make multiple instances of gateway bridge.
only one is enough

  1. You need a Cloud hosting provider that supports UDP “LoadBalancers” or use NodePorts to be able to host the GWB. You need one or more for HA, but they “just translate”.
  2. We started with Kompose, but as the compose-file is host-mounting some configuration it will not work as intended out of the box. Have a look at our Helm-chart: - The GWB needs some love - a basic template is included, I cannot test it fully thou, as I have no cloud with UDP LoadBalancer.

Thanks @eugenev, this gives me hope for a single instance.

The documentation specifies creating a device in Google IOT Core in the format ‘gw-’ suggesting each bridge instance is assigned to a single gateway. Testing so far shows no matter what device_id is specified in the gateway-bridge config, it will always try to publish an event to a topic derived from the gateway EUI (e.g. /devices/gw-3273121652378126/events/up).

Could you provide more details of how you configured a single gateway-bridge instance with multiple gateways?

Example config:

# MQTT server.

# Google Cloud IoT Core Device id.

# Google Cloud project id.

# Google Cloud region.

# Google Cloud IoT registry id.

Log output:

chirpstack-gateway-bridge_1 | time=“2020-08-14T15:26:19Z” level=info msg=“integration/mqtt: publishing event” event=up qos=0 topic=/devices/gw-3273121652378126/events/up uplink_id=315a9f10-p47f-3id8-96r8-86953de82drb

@chopmann, Thanks for your advice - it sounds like the voice of experience!

As you’ve said it’s important to get a load balancer to manage UDP traffic (or in our case Basic Station protocols), the Ingress load balancer for GKE does only HTTP/HTTPS, Nodeport is listed as an available service so I’ll look into that.

The Helm chart project is just whats needed! That’s my week ahead taken care of. Thanks again, happy to input on the GWB if you feel its worthwhile. As you may have seen above, I’m still unsure how the GWB can be configured as an entrypoint for a network of gateways.

Kind regards,

1 Like

I’ll be offline until September 3. After that ill test and add the GWB properly.