There have been a lot of questions related to the Gateway Profiles. Although I tried my best to document it, this feature does not seem to be well communicated and therefore understood. Many questions are related to people not actually using the Gateway Profiles, but pointing to it when things do not work as expected.
To summarize: The purpose is to re-configure gateways (e.g. update the Packet Forwarder configuration and restart it in case of change). It does not affect the LoRa Server behavior / device configuration at all. The only things it does is send configuration messages to the LoRa Gateway Bridge. When the LoRa Gateway Bridge is not configured to handle these configuration messages, the Gateway Profile does not add any value.
My question is: Are there any users that use the Gateway Profiles to re-configure their Packet Forwarder configuration? If this is not the case, then I propose we remove the Gateway Profile as this removes some unneeded complexity from the LoRa Gateway Bridge, LoRa Server and LoRa App Server.
Personally I would favor this, as maybe the management of LoRa gateways should not be the task of the LoRa Gateway Bridge. Its primary task is to work with different backends (e.g. Semtech UDP packet-forwarder and the Basic Station) and “bridge” this to LoRa Server message sent over (currently) MQTT.
It also simplifies the Basic Station configuration as the channel-plan configuration would move to the LoRa Gateway Bridge lora-gateway-bridge.toml file. This would make it possible to use the Basic Station without LoRa Server (and a Gateway Profile) as dependency.
I am concerned about the increasing number of backwards incompatible/breaking changes
Could you mention to which increase you are referring? I believe this has only be v2 to v3 (and one year ago v1 to v2)? We are trying really hard to keep things backwards compatible and as you mentioned we provided a way to already deploy LoRa Gateway Bridge v3 instances (next to LoRa Gateway Bridge v2 instances) while using LoRa Server v2, to ease the migration from v2 to v3.
The reason to deprecate the gateway-profiles is to remove complexity from the code-base Currently this feature supports only the Semtech UDP packet-forwarder, and more logic is needed for the re-configuration of Tektelic, Kerlink iBTS and the iFemtoCell (latest firmware) gateways (they either have a different configuration format, support multiple concentrator chips and / or multiple antennas).
As the LoRa Gateway Bridge is the most difficult component to deploy (when it is installed on the gateway), I would prefer to keep this as simple as possible and thus potentially deprecate this feature if it is not used as it is raising a lot of questions.
We are using Gateway profile on LoRa-App-Server to monitor traffic coming from Gateway which includes all sensor data which helps to monitor multiple applications/Sensors to monitor.
We have previously designed and produced 250-gateways with 8 channels. Using in Turkey. We did 1 year of management and maintenance and we had field experience. We used “Gateway Profiles” to install the first 50 devices in the field. But since the frequency change was never made, we never used it again.
This was our first production. Then Semtech executives visited us and examined the products. They suggested a multi-radio version. We designed and produced in 2018. We have a nice product with 8-64 channel support. We first started to use this product in Istanbul together with the state. We decided to use 16-channel and we needed to change the frequency again. We tried to use gateway profiles again, but it was necessary to install separate lora-gateway-bridge for each radio. This caused a lot of confusion on the server management screens.
Instead of gateway profiles, we created an application by ourselves. The application checks the inventory management database and sets up the channels and other necessary needs on the gateway.
I don’t see any reason why you shouldn’t remove Gateway Profiles.
@jayesh.patel you can still do this without the Gateway Profiles As mentioned in the OP, these profiles are only to configure the gateway channel-plan (= Packet Forwarder configuration).
Without these profiles, the gateway overview with Live LoRaWAN frame-logs still exists and you can still log the frames sent and received.
We don’t use Gateway Profiles. I’ve always felt that this feature had limited use, since gateway configuration changes are extremely rare and would tend to be done via remote management, often along with some other update (which will vary greatly by gateway vendor/type). I’m in favor of removing it.
I concur. Once configured and in production, gateway changes are rare.
Go for it brocaar. It will simplify the config files and if it simplifies code maintenance - all the better.
@brocaar
I have just recently installed the latest version of loraserver and lora-app-server, I tried setting up gateway without assigning any Gateway profile and it actually worked. The gateway is Laird 868 and uses Semtech Forwarder, it shows as connected. So I guess the gateway profiles seems redundant
But my question is : where do we define valid band for the gateway? Like for my Laird RG186 is for EU 868. Or is the loraserver just agnostic about the gateways? it just communicates by MAC address? Sorry if my question if so basic
Thanks
I was planning to fully remove this feature, because it was not clear to many how to use this + it turned out to be complex to support all gateways in a generic way, due to different configuration files. However, with the introduction of the Concentratord, I believe it makes sense to keep this (with better documentation).
With the Concentratord component (https://github.com/brocaar/chirpstack-concentratord), which will support different kind of gateways, it becomes easier to re-configure gateways in a generic way. The ChirpStack Gateway Bridge no longer has to know how to update the Packet Forwarder configuration, it simply passes the new configuration to the Concentratord, which then will interpret the configuration update. For the SX1301, this has been implemented in:
To clarify what exactly the Gateway Profile is doing, I have added the following help dialog:
I find gateway profiles useful, as long as the available channels may vary with different gateway models, and the statistics interval affect bandwith, relevant if they operate under LTE.
However, at first glance is a bit confusing differentiate between gateway-profile and service-profile. I understand that gateway-profile are parameters that only concern to the behavior of the gateway.
It may be easier to understand and configure if gateway-profile was a subsection of the service-profile: either way they are both related with bandwidth, in the phisical layer and in the internet connection, although service-profiles provide some other configuration as private gateways (the only one which doesn’t affect bandwidth as far as I know).
This would make it easier to keep track of the gateways functionality (you only have to choose one profile), and I think it is usual that the same gateway-profile go along the same service-profile.
I discovered ChirpStack a few months ago and I find it very interesting, congratulations.
Best regards
Currently this feature supports only the Semtech UDP packet-forwarder, and more logic is needed for the re-configuration of Tektelic, Kerlink iBTS and the iFemtoCell (latest firmware) gateways (they either have a different configuration format, support multiple concentrator chips and / or multiple antennas).
As mentioned in the OP, these profiles are only to configure the gateway channel-plan (= Packet Forwarder configuration).