[release] ChirpStack Network Server v3.12

Announcements
#1

ChirpStack Network Server v3.12.0

Features

Private gateways

This adds the option to add a service-profile to a gateway and a service-profile flag to make all gateways under that service-profile private. It also adds a global configuration option to make all gateways private. When a gateway is private, only devices under the same service-profile will be able to use the gateway.

Pluggable ADR algorithms

This adds the option to configure custom ADR algorithms through a plugin system. See the examples/adr-plugin directory for an example plugin skeleton.

Improvements

  • Implement uplink frame counter for Prometheus. (#507)
4 Likes
#2

Pluggable ADR algorithms sounds really nice!

1 Like
#3

ChirpStack Network Server v3.12.1

Improvements

  • Don’t run Docker container as root. (#520)
  • Extend ADR HandleRequest with Region, MACVersion and RegParamsRevision fields.

Bugfixes

  • Clear UplinkHistory table for ADR on DR change.
1 Like
#4

I hope this resolves the issue I was seeing after update on 3.12.0:

Devices started to slowly decrease their DR (devices internal ADR engine I guess), but server seemed to not send new ADR commands, so they would end up on DR0 after some time.

Edit: OK, didn’t help. Has default ADR algorithm changed? Seems like I will have to reactivate the devices every day to keep them on higher datarate.

#5

Alright, I’m seeing this troublesome behaviour:

  • First I re-activate ABP device and wait for device to send uplink.
  • Server sends downlink answer with LinkADRReq parameters: DR, power, channel settings…
  • Device changes its DR accordingly and acks the LinkADRReq command in next uplink:

true

  • Depending on situation this repeats few times while server tries to lower the devices power, which is OK as the device is nearby so it has good RF conditions.
  • This is OK untill server tries to send LinkADRReq with DR:5 / txPower:7 for which the device does not ack the power settings:

false

  • Server then keeps repeating same LinkADRReq for every uplink until “max_mac_command_error_count” is reached.
  • After that it does not send any other LinkADRReq command.

Main problem seems to me that it does not send new LinkADRReq even if the RF conditions changes.
That seems weird to me and also different than older versions (can not exactly confirm this unfortunatelly).

After some time device lowers its DR because of “network hiccups” (confirmed uplink not acked). Server seems to not send any new ADR setting even if the device has good SNR, so it ends up on DR0 with +10dB SNR for example. That does not seem right to me.

I have no idea what else I can do to mitigate this behaviour other than reactivatin all devies which forces the server to send new LinkADRReq, which is terrible workaround.

2 Likes
#6

@martin thanks for your feedback. I think I know what the cause is and I’m working on a fix :slight_smile:

Edit: This is fixed by https://github.com/brocaar/chirpstack-network-server/commit/8d1bae71263d85a09ae159f6d832d493ac0260c2.

3 Likes
#7

Glad to see that, thanks :slight_smile:

Edit: Seems to be working on test server. I’m gona deploy the fix on main server too and see how it looks tomorrow.

2 Likes
#8

ChirpStack Network Server v3.12.2

Improvements

  • Update LinkADRAns handling for devices with ADR disabled to align with 4.3.1.1 of LoRaWAN 1.0.4 specs.

Bugfixes

  • Fix max. supported TxPower index which was introduced after ADR refactor.
  • Fix counting uplink history so that only items with same TxPowerIndex are counted.
2 Likes