chirpstack / chirpstack-gateway-bridge

ChirpStack Gateway Bridge abstracts Packet Forwarder protocols into Protobuf or JSON over MQTT.
https://www.chirpstack.io
MIT License
425 stars 273 forks source link

Add support for unlimited channels and radios. #89

Closed amrbekhit closed 6 years ago

amrbekhit commented 6 years ago

This commit removes the restriction of 2 radios and 8 channels and allows any number of channels (and subsequently any number of radios) to be be configured by the gateway bridge. The code automatically adds and configures the necessary number of radios required in order to support the channels.

The two loops in getGatewayConfig have been merged into one, which determines the radio to use for the channel (creating a new one if necessary) and the configures and adds the channel.

As was previously the case, the global_conf.json file needs to already contain entries for the radios and channels in order for the new configuration to be successfully merged. The limit on one Lora_std channel and one FSK channel remains.

amrbekhit commented 6 years ago

@brocaar the tests are failing even on the master branch - it doesn't seem related to this pull request.

brocaar commented 6 years ago

Do you have an example which gateways would support his? As the default Semtech packet-forwarder does not support this afaik. Alternative packet-forwarders (e.g. for the iBTS which supports up to 64 channels) use a different configuration format where you would have to specify the board and antenna to use. This will be something which will be supported in the future, but needs more work (also from LoRa App Server / LoRa Server).

amrbekhit commented 6 years ago

@brocaar The reason for this change is because I'm working on a utility to combine multiple standard 8-channel packet forwarders into one single multi-channel packet forwarder. There are quite a lot of 8-channel Lora Concentrator boards out there and the default open source packet forwarder is designed to work with them. If you need more channels you need to purchase more expensive hardware and their software solutions. I've written a "virtual packet forwarder" that communicates with 2 or more individual standard packet forwarders on one hand and with the loraserver/lora-gateway-bridge on the other. Uplinks received from the packet forwarders are assigned the correct brd property and then forwarded on to the loraserver. Downlinks are routed to the correct packet forwarder based on their brd property.

The above works fine without this pull request, but I also wanted to take advantage of the gateway configuration feature, which means being able to define and send more than 8-channels. When the lora-gateway-bridge receives the config message, it generates the local_conf.json file containing all the channels and then restarts my utility. My utility then reads the the local_conf.json file and distributes the channel and radio configs amongst the individual packet forwarders and then restarting them.

Modifying the lora-gateway-bridge to simply not have a radio or channel limit seemed the most logical way to do this - existing configurations would still work as normal, but you could also define larger numbers of channels.

brocaar commented 6 years ago

I believe some of the errors are related to this pull-request:

Failures:
  * /home/travis/gopath/src/github.com/brocaar/lora-gateway-bridge/internal/gateway/backend_test.go 
  Line 821:
  Expected: 'false'
  Actual:   'true'
  (Should be equal)
  * /home/travis/gopath/src/github.com/brocaar/lora-gateway-bridge/internal/gateway/backend_test.go 
  Line 845:
  Expected: 'false'
  Actual:   'true'
  (Should be equal)

https://github.com/brocaar/lora-gateway-bridge/blob/2.4.1/internal/gateway/backend_test.go#L821 https://github.com/brocaar/lora-gateway-bridge/blob/2.4.1/internal/gateway/backend_test.go#L845

Note that I'm interested in supporting > 8 (multi SF) channels. But I'm not sure if this is the way to go as this is not compatible with the Semtech packet-forwarder configuration file. I do understand however that this can be interested for your own project, but I'm not sure if this should be merged into this branch.

Note also that for example the Kerlink iBTS gateway (which supports up to 64 multi-SF channels) has a different configuration layout than the standard packet-forwarder for 8 channel gateways. It has a definition of up to 4 x 16 channel modules, each with two antenna connectors. I'm not sure yet how other vendors (Cisco, Tektelic, ...) configure their > 8 channel gateways.