V4 Multi Region

Hi,
I have a server up and running Basic Station AU915 with gateways and sensors.
I now run a new instance using -c us915.toml.
I see in the instance data is receive but nothing in the GUI.
I see join request keep looping.
here is my us915.toml Please advise

# This configuration provides a Semtech UDP packet-forwarder backend and
# integrates with a MQTT broker. Many options and defaults have been omitted
# for simplicity.
#
# See https://www.chirpstack.io/gateway-bridge/install/config/ for a full
# configuration example and documentation.


# Gateway backend configuration.
[backend]
# Backend type.
type="basic_station"

  # Semtech UDP packet-forwarder backend.
  [backend.semtech_udp]

  # ip:port to bind the UDP listener to
  #
  # Example: 0.0.0.0:1700 to listen on port 1700 for all network interfaces.
  # This is the listener to which the packet-forwarder forwards its data
  # so make sure the 'serv_port_up' and 'serv_port_down' from your
  # packet-forwarder matches this port.
  udp_bind = "0.0.0.0:1701"


#Amir

# Basic Station backend.
  [backend.basic_station]

  # ip:port to bind the Websocket listener to.
  bind=":3002"

  # TLS certificate and key files.
  #
  # When set, the websocket listener will use TLS to secure the connections
  # between the gateways and ChirpStack Gateway Bridge (optional).
  tls_cert=""
  tls_key=""

  # TLS CA certificate.
  #
  # When configured, ChirpStack Gateway Bridge will validate that the client
  # certificate of the gateway has been signed by this CA certificate.
  ca_cert=""

  # Stats interval.
  #
  # This defines the interval in which the ChirpStack Gateway Bridge forwards
  # the uplink / downlink statistics.
  stats_interval="30s"

  # Ping interval.
  ping_interval="1m0s"

  # Timesync interval.
  #
  # This defines the interval in which the ChirpStack Gateway Bridge sends
  # a timesync request to the gateway. Setting this to 0 disables sending
  # timesync requests.
  timesync_interval="1h0m0s"

  # Read timeout.
  #
  # This interval must be greater than the configured ping interval.
  read_timeout="1m5s"

  # Write timeout.
  write_timeout="1s"


####################   Amir

  # Region.
  #
  # Please refer to the LoRaWAN Regional Parameters specification
  # for the complete list of common region names.
  region="US915"

  # Minimal frequency (Hz).
  frequency_min=902000000

  # Maximum frequency (Hz).
  frequency_max=928000000

  # Concentrator configuration.
  #
  # This section contains the configuration for the SX1301 concentrator chips.
  
  [[backend.basic_station.concentrators]]
     # Multi-SF channel configuration.
     [backend.basic_station.concentrators.multi_sf]

     # Frequencies (Hz).
     frequencies=[902300000,902500000,902700000,902900000,903100000,903300000,903500000,903700000,]

     # LoRa STD channel.
     [backend.basic_station.concentrators.lora_std]

     # Frequency (Hz).
     frequency=903000000

     # Bandwidth (Hz).
     bandwidth=500000
  
     # Spreading factor.
     spreading_factor=8
  
     # FSK channel.
     [backend.basic_station.concentrators.fsk]
  
     # Frequency (Hz).
     frequency=903000000

####################################

# Integration configuration.
[integration]
# Payload marshaler.
#
# This defines how the MQTT payloads are encoded. Valid options are:
# * protobuf:  Protobuf encoding
# * json:      JSON encoding (easier for debugging, but less compact than 'protobuf')
marshaler="protobuf"

  # MQTT integration configuration.
  [integration.mqtt]
  # Event topic template.
  event_topic_template="us915/gateway/{{ .GatewayID }}/event/{{ .EventType }}"

  # Command topic template.
  command_topic_template="us915/gateway/{{ .GatewayID }}/command/#"

  state_topic_tamplate="us915/gateway/{{ .GatewayID }}/state/{{ .StateType }}"
  # MQTT authentication.
  [integration.mqtt.auth]
  # Type defines the MQTT authentication type to use.
  #
  # Set this to the name of one of the sections below.
  type="generic"

    # Generic MQTT authentication.
    [integration.mqtt.auth.generic]
    # MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
    server="tcp://127.0.0.1:1883"

    # Connect with the given username (optional)
    username=""

    # Connect with the given password (optional)
    password=""

Au915 and us915 are different frequency plans.

I have some gateways configured as AU915 - working fine with my V4 server (first server)
I have a gateway and a sensor configured as US915 - working fine with my V3 server (2nd server)
Trying to migrate US915 gateway which is working fine with 2nd server to 3rd server V4.

Yah, may be you are in luck.
AU915 and US915 are different. And they both have different subbands.
May be you need to double check the frequency plans of the gateway, old and new server.
Join requests keep looping means

  1. The server either does not receving the join requests due to mismatch frequencies.
  2. The server does not send back Join-Accept due to wrong DevEUI and AppKey
  3. The server sends back Join-Accept but the device doesnt receive it or the device crash during the operation (esp for DIY devices)

You may need to check the console / GUI to see if the traffic comes to gateway and comes to devices.

For example, AU915_1 and US915_1 are different.
This is AU915_1

This is US915_1

@Amir_Frenkel you might find these configuration examples helpful: https://github.com/chirpstack/chirpstack-docker/tree/master/configuration/chirpstack-gateway-bridge.

1 Like

@brocaar Thanks !!
Got it working with US915
Got another server working on AU915
Next step, next week, building multi region server.

Thanks.
Got it all to work.
Multi region.

I want to run Chirpstack as multi-region. It is already configured and running with a EU868 gateway with no problem.

I want to add an AS923-2 gateway and can see in the dashboard this region is available. However when I add the AS923-2 gateway it gets put in the EU868 region.

I am obviously missing something here and my dumb question is… I have my chirpstack-gateway-bridge.toml file that just has the eu868 frequencies. I see the chirpstack-gateway-bridge-basicstation-as923_2.toml and chirpstack-gateway-bridge-basicstation-eu868.toml but how do I enable them to run together?

Each gateway-bridge only supports a single frequency plan, you must add more gateway bridges each configured to a different region.

Thanks. I built a second chirpstack server so I could play around. Strange thing is that my rak gateway connects to the eu868 chirpstack server no issues (other than it is configured for eu868) but cannot get it to connect to the as923-2 chirpstack server.

Have you configured as923-2 for your gateway?

Yes I believe I have configured the config correctly …see attached gateway-bridge.toml file.

# This configuration provides a Semtech UDP packet-forwarder backend and
# integrates with a MQTT broker. Many options and defaults have been omitted
# for simplicity.
#
# See https://www.chirpstack.io/gateway-bridge/install/config/ for a full
# configuration example and documentation.


# Gateway backend configuration.
[backend]
# Backend type.
type="basic_station"

  # Semtech UDP packet-forwarder backend.
  [backend.basic_station]

  # ip:port to bind the UDP listener to
  #
  # Example: 0.0.0.0:1700 to listen on port 1700 for all network interfaces.
  # This is the listener to which the packet-forwarder forwards its data
  # so make sure the 'serv_port_up' and 'serv_port_down' from your
  # packet-forwarder matches this port.
  bind = ":3001"

[integration]
# Payload marshaler.
#
# This defines how the MQTT payloads are encoded. Valid options are:
# * protobuf:  Protobuf encoding
# * json:      JSON encoding (easier for debugging, but less compact than 'protobuf')
marshaler="json"

  # MQTT integration configuration.
  [integration.mqtt]
  # Event topic template.
  event_topic_template="as923-2/gateway/{{ .GatewayID }}/event/{{ .EventType }}"

  # Command topic template.
  command_topic_template="as923-2/gateway/{{ .GatewayID }}/command/#"

  # Event topic template.
  event_topic="application/{{application_id}}/device/{{dev_eui}}/event/{{event}}"

  # Command topic.
  #
  # This is the topic on which the MQTT subscribes for receiving (enqueue) commands.
  command_topic="application/{{application_id}}/device/{{dev_eui}}/command/{{command}}"



  # MQTT authentication.
  [integration.mqtt.auth]
  # Type defines the MQTT authentication type to use.
  #
  # Set this to the name of one of the sections below.
  type="generic"

    # Generic MQTT authentication.
    [integration.mqtt.auth.generic]
    # MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
    server="tcp://127.0.0.1:1883"

    # Connect with the given username (optional)
    username=""

    # Connect with the given password (optional)
    password=""

# This file contains an example AS923_2 configuration.
[[regions]]

  # ID is an user-defined identifier for this region.
  id="as923_2"

  # Description is a short description for this region.
  description="AS923-2"

  # Common-name refers to the common-name of this region as defined by
  # the LoRa Alliance.
  common_name="AS923_2"


  # Gateway configuration.
  [regions.gateway]

    # Force gateways as private.
    #
    # If enabled, gateways can only be used by devices under the same tenant.
    force_gws_private=false


    # Gateway backend configuration.
    [regions.gateway.backend]

      # The enabled backend type.
      enabled="mqtt"

      # MQTT configuration.
      [regions.gateway.backend.mqtt]

        # Topic prefix.
        #
        # The topic prefix can be used to define the region of the gateway.
        # Note, there is no need to add a trailing '/' to the prefix. The trailing
        # '/' is automatically added to the prefix if it is configured.
        topic_prefix="as923_2"

        # MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
        server="tcp://$MQTT_BROKER_HOST:1883"

        # Connect with the given username (optional)
        username=""

        # Connect with the given password (optional)
        password=""

        # Quality of service level
        #
        # 0: at most once
        # 1: at least once
        # 2: exactly once
        #
        # Note: an increase of this value will decrease the performance.
        # For more information: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels
        qos=0

        # Clean session
        #
        # Set the "clean session" flag in the connect message when this client
        # connects to an MQTT broker. By setting this flag you are indicating
        # that no messages saved by the broker for this client should be delivered.
        clean_session=false

        # Client ID
        #
        # Set the client id to be used by this client when connecting to the MQTT
        # broker. A client id must be no longer than 23 characters. If left blank,
        # a random id will be generated by ChirpStack.
        client_id=""

        # Keep alive interval.
        #
        # This defines the maximum time that that should pass without communication
        # between the client and server.
        keep_alive_interval="30s"

        # CA certificate file (optional)
        #
        # Use this when setting up a secure connection (when server uses ssl://...)
        # but the certificate used by the server is not trusted by any CA certificate
        # on the server (e.g. when self generated).
        ca_cert=""

        # TLS certificate file (optional)
        tls_cert=""

        # TLS key file (optional)
        tls_key=""


    # Gateway channel configuration.
    #
    # Note: this configuration is only used in case the gateway is using the
    # ChirpStack Concentratord daemon. In any other case, this configuration 
    # is ignored.
    [[regions.gateway.channels]]
      frequency=921400000
      bandwidth=125000
      modulation="LORA"
      spreading_factors=[7, 8, 9, 10, 11, 12]

    [[regions.gateway.channels]]
      frequency=921600000
      bandwidth=125000
      modulation="LORA"
      spreading_factors=[7, 8, 9, 10, 11, 12]

    [[regions.gateway.channels]]
      frequency=921200000
      bandwidth=125000
      modulation="LORA"
      spreading_factors=[7, 8, 9, 10, 11, 12]

    [[regions.gateway.channels]]
      frequency=921800000
      bandwidth=125000
      modulation="LORA"
      spreading_factors=[7, 8, 9, 10, 11, 12]

    [[regions.gateway.channels]]
      frequency=922000000
      bandwidth=125000
      modulation="LORA"
      spreading_factors=[7, 8, 9, 10, 11, 12]

    [[regions.gateway.channels]]
      frequency=922200000
      bandwidth=125000
      modulation="LORA"
      spreading_factors=[7, 8, 9, 10, 11, 12]

    [[regions.gateway.channels]]
      frequency=922400000
      bandwidth=125000
      modulation="LORA"
      spreading_factors=[7, 8, 9, 10, 11, 12]

    [[regions.gateway.channels]]
      frequency=922200000
      bandwidth=250000
      modulation="LORA"
      spreading_factors=[7]

    [[regions.gateway.channels]]
      frequency=922600000
      bandwidth=125000
      modulation="FSK"
      datarate=50000



  # Region specific network configuration.
  [regions.network]
    
    # Installation margin (dB) used by the ADR engine.
    #
    # A higher number means that the network-server will keep more margin,
    # resulting in a lower data-rate but decreasing the chance that the
    # device gets disconnected because it is unable to reach one of the
    # surrounded gateways.
    installation_margin=10

    # RX window (Class-A).
    #
    # Set this to:
    # 0: RX1 / RX2
    # 1: RX1 only
    # 2: RX2 only
    rx_window=0

    # RX1 delay (1 - 15 seconds).
    rx1_delay=1

    # RX1 data-rate offset
    rx1_dr_offset=0

    # RX2 data-rate
    rx2_dr=0

    # RX2 frequency (Hz)
    rx2_frequency=921400000

    # Prefer RX2 on RX1 data-rate less than.
    #
    # Prefer RX2 over RX1 based on the RX1 data-rate. When the RX1 data-rate
    # is smaller than the configured value, then the Network Server will
    # first try to schedule the downlink for RX2, failing that (e.g. the gateway
    # has already a payload scheduled at the RX2 timing) it will try RX1.
    rx2_prefer_on_rx1_dr_lt=0

    # Prefer RX2 on link budget.
    #
    # When the link-budget is better for RX2 than for RX1, the Network Server will first
    # try to schedule the downlink in RX2, failing that it will try RX1.
    rx2_prefer_on_link_budget=false

    # Downlink TX Power (dBm)
    #
    # When set to -1, the downlink TX Power from the configured band will
    # be used.
    #
    # Please consult the LoRaWAN Regional Parameters and local regulations
    # for valid and legal options. Note that the configured TX Power must be
    # supported by your gateway(s).
    downlink_tx_power=-1

    # ADR is disabled.
    adr_disabled=false

    # Minimum data-rate.
    min_dr=0

    # Maximum data-rate.
    max_dr=5
    enabled_uplink_channels=[]
    # enabled_uplink_channels=[0 ,1, 2, 3, 4, 5, 6]

    # Rejoin-request configuration (LoRaWAN 1.1)
    [regions.network.rejoin_request]

      # Request devices to periodically send rejoin-requests.
      enabled=false

      # The device must send a rejoin-request type 0 at least every 2^(max_count_n + 4)
      # uplink messages. Valid values are 0 to 15.
      max_count_n=0

      # The device must send a rejoin-request type 0 at least every 2^(max_time_n + 10)
      # seconds. Valid values are 0 to 15.
      #
      # 0  = roughly 17 minutes
      # 15 = about 1 year
      max_time_n=0
    

    # Class-B configuration.
    [regions.network.class_b]

      # Ping-slot data-rate. 
      ping_slot_dr=3

      # Ping-slot frequency (Hz)
      #
      # set this to 0 to use the default frequency plan for the configured region
      # (which could be frequency hopping).
      ping_slot_frequency=0

 #
  # This section contains the configuration for the SX1301 concentrator chips.
  # Example:
  [[backend.basic_station.concentrators]]
  #
  #   # Multi-SF channel configuration.
     [backend.basic_station.concentrators.multi_sf]
  #
  #   # Frequencies (Hz).
     frequencies=[
       921400000,
       921600000,
       921200000,
       921800000,
       922000000,
       922200000,
       922400000,
       
     ]
  #
  #   # LoRa STD channel.
     [backend.basic_station.concentrators.lora_std]
  #
  #   # Frequency (Hz).
     frequency=921400000
  #
  #   # Bandwidth (Hz).
     bandwidth=125000
  #
  #   # Spreading factor.
     spreading_factor=7
  #
  #   # FSK channel.
     [backend.basic_station.concentrators.fsk]
  #
  #   # Frequency (Hz).
     frequency=921400000

After your reply, I believe you havent configured your gateway.

I feel I am going in circles so hopefully you can help.
I have Chirpstack and Chirpstack gateway bridge configured as eu868 talking with a rak7268 gateway - no issues all working OK.

I have installed another chirpstack gateway bridge on a separate server configured as as923_2 with a rak 7268v2 gateway

My issue is that I see all chirpstack services active and I can see both chirpstack gateway bridges sending mqtt status messages. No errors appear that I can see in the logs.

However when i look at the chirpstack gui i see both gateways active but they are both showing as eu868.

When I look at the lora frames for the as923_2 gateway I see frames being received but within the frame i see metadata stating the region is eu868.

My chirpstack-gateway-bridge.toml region is set to AS923_2

My rak 7268v2 is configured as basic station and pointing to the ip address of the as823_2 chirpstack gateway bridge

What am I doing wrong?

see below lora frame as seen in chirpstack gui…
{ "phy_payload": { "mhdr": { "m_type": "UnconfirmedDataUp", "major": "LoRaWANR1" }, "mic": [ 63, 239, 208, 217 ], "payload": { "f_port": 2, "fhdr": { "devaddr": "01ffd6f5", "f_cnt": 443, "f_ctrl": { "ack": false, "adr": true, "adr_ack_req": false, "class_b": false, "f_opts_len": 0, "f_pending": false }, "f_opts": [] }, "frm_payload": "a1d4c9d157e34d2db3de20" } }, "rx_info": [ { "context": "AAAAAAAAAAAAWAAAaN9Fnw==", "crcStatus": "CRC_OK", "gatewayId": "ac1f09fffe10af77", "gwTime": "2024-05-13T17:38:13+00:00", "location": {}, "metadata": { "region_common_name": "EU868", "region_config_id": "eu868" }, "nsTime": "2024-05-13T17:38:13.498828055+00:00", "rssi": -108, "snr": 7.75, "uplinkId": 3832331033 } ], "tx_info": { "frequency": 868500000, "modulation": { "lora": { "bandwidth": 125000, "codeRate": "CR_4_5", "spreadingFactor": 7 } } } },

It is either the ChirpStack Gateway Bridge / ChirpStack MQTT Forwarder forwarding to the wrong MQTT topic prefix, or in your region configuration an overlap in MQTT topic prefixes. Each region config should have an unique topic prefix.