By making this opt-in, we can reduce the overhead of supporting both v3
and v4 gateway messages. In case of v3 to v4 migration, one would
upgrade all ChirpStack Gateway Bridge instances to the latest v3
version, migrate ChirpStack as described here + enable this config flag:
https://www.chirpstack.io/docs/v3-v4-migration.html
Then upgrade ChirpStack Gateway Bridge to the latest v4 version followed
by disabling / removing this config flag (`v4_migrate`) again.
This lets serde use default values in case a field is missing.
Specifically, this fixes the 'missing field `forward_f_ports`'
if migrating from an older LoRa Cloud configuration where the
`forward_f_ports` field was not yet present.
In case the region description was missing, EU868 was set as default. As
well the default configuration (in case no regions were set) would
always fallback to EU868 which was used for testing. This removes the
default EU868 configuration and moves this configuration to tests.
This updates the region API methods to use the region id as description,
in case the description is not configured.
Closes#120.
The error would occur when the uplink was also received by an unknown
gateway. In this case fetching the metadata for this gateway would fail,
causing the gateway_private_up and _down not to be populated with the
gateway_id.
This makes it possible to add gateways to a multicast-group, which in
case configured will always be used for transmitting the multicast
downlinks.
This also moves the multicast class-c scheduling to the multicast-group
configuration. Options are delay between multiple gateways, or GPS time
synchronized transmission.
This config option was present in v3 to set a delay before starting the
downlink flow (Class-A) so that an end-application can enqueue a
downlink to be used within the same uplink / downlink transaction.
However, this option was still missing in v4.
As part of the ADR back-off, the device will eventually revert to the
default channel-plan but there is no explicit signalling if this
happened.
This might cause some small overhead in case the device did not (yet)
revert to the default channel-mask, but it avoids scenarios where the
device and NS are out-of-sync.
This makes the configuration easier, as well if new topics are added in
the future, there is no need to update all the configuration files
again to add the missing topic configuration.
The device might not always send its periodicity to the network-server
(using mac-commands). As well there is some ambiguity about the default
ping-slot data-rates. While the Regional Parameters Specification
defines the default beacon data-rates, it only defines the default
ping-slot frequency for Class-B.
This also changes the API field from class_b_ping_slot_period to
class_b_ping_slot_nb_k, where ..._k must be between 0 - 7 as defined by
the LoRaWAN Specification. This removes some ambiguity as 'period' could
mean different things in different contexts.
