Basic Station Integration: router_config should not include hardware-specific configuration

[beitler]

Summary

In the Basic Station protocol, the LNS sends a configuration structure router_config down to the gateway. Upon reception, Station merges the received configuration with the local station.conf file where the server-side router_config has precedence. TTN servers include configuration inside the LNS-side router_config structure which is highly hardware specific:
clksrc
radio_x.rssi_offset
radio_x.tx_enable

This breaks the configuration on platforms, which don't comply with these assumptions.

Steps to Reproduce

1. Connect a Basic Station gateway.
2. Send the version message.
3. Check the returned JSON.

What do you see now?

Example JSON:

{"msgtype":"router_config","NetID":null,"JoinEui":null,"region":"EU863","hwspec":"sx1301/1","freq_range":[863000000,870000000],"DRs":[[12,125,0],[11,125,0],[10,125,0],[9,125,0],[8,125,0],[7,125,0],[7,250,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0]],"sx1301_conf":[{"lorawan_public":true,"clksrc":1,"antenna_gain":0,"radio_0":{"enable":true,"freq":867500000,"rssi_offset":-166,"tx_enable":true},"radio_1":{"enable":true,"freq":868500000,"rssi_offset":-166,"tx_enable":false},"chan_multiSF_0":{"enable":true,"radio":1,"if":-400000},"chan_multiSF_1":{"enable":true,"radio":1,"if":-200000},"chan_multiSF_2":{"enable":true,"radio":1,"if":0},"chan_multiSF_3":{"enable":true,"radio":0,"if":-400000},"chan_multiSF_4":{"enable":true,"radio":0,"if":-200000},"chan_multiSF_5":{"enable":true,"radio":0,"if":0},"chan_multiSF_6":{"enable":true,"radio":0,"if":200000},"chan_multiSF_7":{"enable":true,"radio":0,"if":400000},"chan_Lora_std":{"enable":true,"radio":1,"if":-200000,"bandwidth":250000,"spread_factor":7},"chan_FSK":{"enable":true,"radio":1,"if":300000,"bandwidth":125000,"datarate":50000}}],"nocca":true,"nodc":true,"nodwell":true,"MuxTime":1586337434.8006055}

What do you want to see instead?

• clksrc, radio_x.rssi_offset, radio_x.tx_enable should not be present in the returned config.
• antenna_gainshould only be returned when explicitly set by the user. Moved here; Support user defined Antenna Gain in LBS router config #4191

Environment

v3.7.0

How do you propose to implement this?

This required modification of the frequency plans repository.

Can you do this yourself and submit a Pull Request?

@KrishnaIyer will take this.

[reissjason]

Will the LUT values be sent by default? They are unique to GW hardware.

[KrishnaIyer]

@reissjason : TxLut values are not sent for Basic Station gateways.

[KrishnaIyer]

blocked on https://github.com/TheThingsIndustries/lorawan-stack/issues/2018 unless this is critical enough that we want to hardcode these fields.

[Oliv4945]

Hello @KrishnaIyer,

It seems that TheThingsIndustries/lorawan-stack#2018 is private. Do you have any update on this issue ?

Thanks

[KrishnaIyer]

This item is in backlog so it's not on my list for this milestone. Please upvote if this is important to you. If there's enough demand, we can definitely look at it.

[KrishnaIyer]

TTN servers include configuration inside the LNS-side router_config structure which is highly hardware specific:
clksrc
radio_x.rssi_offset
radio_x.tx_enable
This breaks the configuration on platforms, which don't comply with these assumptions.

@beitler
I went through the LBS spec; https://doc.sm.tc/station/gw_v1.5.html and the following is the example configuration file;

   "radio_conf": {                  /* Actual channel plan is controlled by the server */
       "lorawan_public": true,      /* is default */
       "clksrc": 1,                 /* radio_1 provides clock to concentrator */
       "device": "spidev",          /* default SPI device is platform specific */
       "radio_0": {
           /* freq/enable provided by LNS - only hardware-specific settings are listed here */
           "type": "SX1257",
           "rssi_offset": -166.0,
           "tx_enable": true,
           "antenna_gain": 0
       },
       "radio_1": {
           "type": "SX1257",
           "rssi_offset": -166.0,
           "tx_enable": false
       }
       /* chan_multiSF_X, chan_Lora_std, chan_FSK provided by LNS */
   }

So for LBS, the fields listed in this example should not be sent down by the LNS as they would be present in the local station.conf. Is that correct?

• how about if the server could choose these fields based on the particular gateway/model? Or should the server assume that the gateway should have the base station.conf embedded in it when it's released?
• Are there other such fields that the LNS should not override?

[beitler]

The LNS has the power to set all low level radio configuration parameters. However, the LNS should make use of that power only when it is absolutely necessary and it knows exactly what it is doing.
Historically, the LNS would send down the channel plan via the hardware specific radio_conf structure. Since 2.0.5 this is not necessary since the channel plan can be described in a hardware agnostic way using the upchannels and DRs fields of the router_config message.
Therefore, the recommendation is that pre-2.0.5 the LNS specifies inside radio_conf only those fields that are necessary to describe the channel plan. Since 2.0.5 there should not be any need for the LNS to specify any radio_conf parameters except for some low-level tuning.

[kristokj]

Hi @beitler and @KrishnaIyer,
Could you please comment on the progress for this matter?

We are working on deploying several MultiTech Conduit AEPs with basic station on TTNv3, but have so far not been able to get it running correctly due to this issue of override coming down from the LNS server.
See these forum posts for details:
https://www.thethingsnetwork.org/forum/t/any-way-to-edit-the-ttnv3-gateway-global-conf-json/44847
https://www.thethingsnetwork.org/forum/t/unable-to-connect-multitech-conduit-aep-to-ttn-v3/44257
https://www.thethingsnetwork.org/forum/t/multitech-conduit-ap-v3-basic-station/39612