[release] ChirpStack Network Server v3.13 test releases

ChirpStack Network Server v3.13.0-test.1

Features

Uplink / downlink logging to Redis Stream

This implements the (optional) logging of uplink and downlink frames for gateways and devices to a Redis Stream for external logging and monitoring purposes. By default this option is disabled, it can be enabled in the Configuration.

Improvements

Refactor downlink scheduling

This includes the following changes:

txack / removing of queue items

A downlink queue-item will only be deleted when it has been successfully acknowledged for transmission by the gateway. In case the gateway was unable to transmit the downlink, then the downlink will stay in the queue and the downlink frame-counter is not incremented. Note that the multicast frame-counter is incremented on scheduling, not after a txack, as a multicast downlink can be transmitted by multiple gateways in order to reach all devices in the multicast-group.

re-encrypt queue-items

As per LoRaWAN 1.0.4 specifications, mac-commands must be prioritized over application payloads, this mean than when there is an application payload in the queue with frame-counter N, but the downlink with frame-counter N will be a mac-command only downlink (because of max. payload-size restrictions), the NS will request the AS to re-encrypt the application payload using frame-counter N+1 so that it can be sent to the device at the next downlink opportunity.

Schema migrations

Refactor SQL schema migrations from sql-migrate
to golang-migrate. (#525)

Update Go import path

This updates the Go import path to github.com/brocaar/chirpstack-network-server/v3. This fixes the go get issue, when importing github.com/brocaar/chirpstack-network-server/v3/adr when implementing a custom ADR algorithm.

Log timestamp precision

This adds ns precision to the log timestamp.


Testing

Debian

Use the testing channel instead of stable:

sudo echo "deb https://artifacts.chirpstack.io/packages/3.x/deb testing main" | sudo tee /etc/apt/sources.list.d/chirpstack.list

Docker

Use the chirpstack/chirpstack-network-server:3.13.0-test.1 image and tag.

Does anything need to be done manually to support the change in migration tooling on existing database schemas?

Interesting about the txack/queue feature, this might greatly help some of our current problems. A few questions:

  1. Lets say the gateway does not receive a downlink in time to schedule it in the RX1 window (network lag or similar issue), so no TXACK is received from the gateway. How will this feature work for a class-C device? I would think that LNS can immediately re-send the failed packet, now with ClassC/RX2 params?
  2. Is there an eventual timeout/packet drop on these re-queued downlinks? Or will they stay in the queue forever until a txack is received from the gateway? (concerned about GW being offline for some time, and thousands of packets filling up the queue)
  3. What is the “timeout” waiting for txack before it decides to re-queue the downlink.

thanks!

Nope, the current state is automatically migrated :slight_smile:

When no positive txack is received, the payload stays in the queue for unicast. This indeed means that for Class-C devices, that in case a Class-A downlink fails, the Class-C scheduler will re-schedule it for transmission.

Or will they stay in the queue forever until a txack is received from the gateway? (concerned about GW being offline for some time, and thousands of packets filling up the queue)

It stays in the queue forever until a positive txack. I don’t think this is a bad thing, as dropping the downlink for an offline gateway would mean data gets dropped. Note that unicast queue items are not associated with a gateway. Thus when a gateway is offline and a Class-C downlink fails because of this, all that is needed is a Class-A uplink to update the downlink path :slight_smile:

1 Like

It stays in the queue forever until a positive txack. I don’t think this is a bad thing, as dropping the downlink for an offline gateway would mean data gets dropped.

Does that mean that if a gateway was turned off, the queue grows infinitely (if a server keeps pushing downstream messages) and when the gateway will be turned on all these messages will be received by the devices? If so, I think that there is should be a way to configure an expiration timeout for the queue messages.

ChirpStack Network Server v3.13.0-test.2

Features

Uplink / downlink logging to Redis Stream

This implements the (optional) logging of uplink and downlink frames for gateways and devices to a Redis Stream for external logging and monitoring purposes. By default this option is disabled, it can be enabled in the Configuration.

Improvements

Refactor downlink scheduling

This includes the following changes:

txack / removing of queue items

A downlink queue-item will only be deleted when it has been successfully acknowledged for transmission by the gateway. In case the gateway was unable to transmit the downlink, then the downlink will stay in the queue and the downlink frame-counter is not incremented. Note that the multicast frame-counter is incremented on scheduling, not after a txack, as a multicast downlink can be transmitted by multiple gateways in order to reach all devices in the multicast-group.

re-encrypt queue-items

As per LoRaWAN 1.0.4 specifications, mac-commands must be prioritized
over application payloads, this mean than when there is an
application payload in the queue with frame-counter N, but the
downlink with frame-counter N will be a mac-command only downlink
(because of max. payload-size restrictions), the NS will request the
AS to re-encrypt the application payload using frame-counter N+1 so
that it can be sent to the device at the next downlink opportunity.

Schema migrations

Refactor SQL schema migrations from sql-migrate to golang-migrate. (#525)

Update Go import path

This updates the Go import path to github.com/brocaar/chirpstack-network-server/v3. This fixes the go get issue, when importing github.com/brocaar/chirpstack-network-server/v3/adr when implementing a custom ADR algorithm.

Log timestamp precision

This adds ns precision to the log timestamp.

Custom authorization for roaming

This adds a configurable HTTP authorization header for roaming. (#528)

Class-C scheduling improvements

  • Lock Class-C downlink scheduling for device when a Class-A uplink is received,
    to avoid that the Class-C scheduler schedules a downlink within Class-A receive-window.
  • Add config option to lock gateway for a given time after a Class-C downlink, to avoid
    continuously sending Class-C downlinks and therefore not being able to receive any
    uplink (responses).

Bugfixes

  • Do not try to lookup NetID of unknown devices when roaming is disabled.

ChirpStack Network Server v3.13.0-test.3

Features

Uplink / downlink logging to Redis Stream

This implements the (optional) logging of uplink and downlink frames for gateways and devices to a Redis Stream for external logging and monitoring purposes. By default this option is disabled, it can be enabled in the Configuration.

LoRaWAN 2.4 GHz

This adds the ISM2400 band to ChirpStack for LoRaWAN 2.4 GHz support.

Improvements

Refactor downlink scheduling

This includes the following changes:

txack / removing of queue items

A downlink queue-item will only be deleted when it has been successfully acknowledged for transmission by the gateway. In case the gateway was unable to transmit the downlink, then the downlink will stay in the queue and the downlink frame-counter is not incremented. Note that the multicast frame-counter is incremented on scheduling, not after a txack, as a multicast downlink can be transmitted by multiple gateways in order to reach all devices in the multicast-group.

re-encrypt queue-items

As per LoRaWAN 1.0.4 specifications, mac-commands must be prioritized over application payloads, this mean than when there is an application payload in the queue with frame-counter N, but the downlink with frame-counter N will be a mac-command only downlink (because of max. payload-size restrictions), the NS will request the AS to re-encrypt the application payload using frame-counter N+1 so that it can be sent to the device at the next downlink opportunity.

Schema migrations

Refactor SQL schema migrations from sql-migrate to golang-migrate. (#525)

Update Go import path

This updates the Go import path to github.com/brocaar/chirpstack-network-server/v3. This fixes the go get issue, when importing github.com/brocaar/chirpstack-network-server/v3/adr when implementing a custom ADR algorithm.

Log timestamp precision

This adds ns precision to the log timestamp.

Custom authorization for roaming

This adds a configurable HTTP authorization header for roaming. (#528)

Class-C scheduling improvements

  • Lock Class-C downlink scheduling for device when a Class-A uplink is received, to avoid that the Class-C scheduler schedules a downlink within Class-A receive-window.
  • Add config option to lock gateway for a given time after a Class-C downlink, to avoid continuously sending Class-C downlinks and therefore not being able to receive any uplink (responses).

Bugfixes

  • Do not try to lookup NetID of unknown devices when roaming is disabled.