[announcement] LoRa Gateway Bridge v3.0.0 - test release

This is the first test release of LoRa Gateway Bridge v3, which adds compatibility with the Semtech Basic Station packet-forwarder. LoRa Server v2.7 will be released shortly, which will be compatible with both LoRa Gateway Bridge v2 and v3 (v2 support will be dropped as soon as LoRa Server v3 is release).


v3.0.0-testing.1

Features

Basic Station packet-forwarder support

The LoRa Gateway Bridge has been refactored to support multiple packet-forwarder backends. Next to the Semtech UDP packet-forwarder, support has been added to support the Basic Station packet-forwarder. This backend implements the Basic Station LNS protocol.

Updated payload formats

The uplink payload contains a context field, used to store gateway specific context data (like the internal counter).

The downlink frame contains a timing field which can be either IMMEDIATELY, DELAY or GPS_EPOCH. Based on the timing value, an additional object must be given with the additional timing information. Refer to Commands for more details.

Upgrading

LoRa Gateway Bridge v3.0.0 include a couple of changes that are not backwards compatible. You need to re-generate the configuration file and update it where needed. LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+. Below a summary:

MQTT topics

The MQTT topic configuration has been updated from:

uplink_topic_template="gateway/{{ .MAC }}/rx"
downlink_topic_template="gateway/{{ .MAC }}/tx"
stats_topic_template="gateway/{{ .MAC }}/stats"
ack_topic_template="gateway/{{ .MAC }}/ack"
config_topic_template="gateway/{{ .MAC }}/config"

To:

event_topic_template="gateway/{{ .GatewayID }}/event/{{ .EventType }}"
command_topic_template="gateway/{{ .GatewayID }}/command/#"

Event types are: up, stats and ack.
Commands are: down and config.

Please note that LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+, but you will need to update the MQTT topics in your loraserver.toml file. Example snippet:

uplink_topic_template="gateway/+/event/up"
stats_topic_template="gateway/+/event/stats"
ack_topic_template="gateway/+/event/ack"
downlink_topic_template="gateway/{{ .MAC }}/command/down"
config_topic_template="gateway/{{ .MAC }}/command/config"

Backends

With LoRa Gateway Bridge v2 you would configure the MQTT backend under the [backend...] section. This has changed and the [backend...] section is now used for selecting and configuring the packet-forwarder backends.

Integrations

The MQTT integration configuration has moved to the new [integration...] section. This allows for adding new integrations in the future besides MQTT.


Debian / Ubuntu users

Please use the 3.x testing repository:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1CE2AFD36DBCCA00

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

Docker users

Please see the available Docker tags: https://cloud.docker.com/u/loraserver/repository/docker/loraserver/lora-gateway-bridge/tags.

Downloads

Please see: https://artifacts.loraserver.io/downloads/lora-gateway-bridge/.

4 Likes

Does this mean that CUPS support (for remote gateway configuration) is also on the way in a future release? :wink:

I’m not sure to be honest :slight_smile: This is targeting the LNS protocol implementation. Potentially it could make sense that each gateway vendor takes care of a CUPS implementation for their gateway models, I’m not sure… What do you think?

But please know that this already uses the gateway-profile to configure the Basic Station channel-plan (thus the gateway-profile is mandatory for Basic Station powered gateways, I still need to document this).

I know that I have a TTN Indoor Gateway from conference that I can’t reconfigure to talk to LoRaServer because I’m not running a CUPS server… :wink:

Vendor interaction on this would be awesome (as would seeing Lora-gateway-os on the devices as we discussed at the Laird stand in Amsterdam!), but I do wonder if they’re going to claim it’s “not our problem, we just make the gateways, it’s up to you to configure them…” :frowning:

Whatever you do, please don’t make CUPS a required dependency for anything. :face_vomiting:

1 Like

Totally agree here, it’s a “nice to have”, not a “you must use”! :slight_smile:

I can give it a spin. Any chance you could build either a Docker image (perhaps this is already available as latest?) or a package for either the Tektelic KONA Micro or MultiTech Conduit (AP)?

I’ve prepared this Compose setup for testing (make sure you are using the v3-test branch):

https://github.com/brocaar/loraserver-docker/tree/v3-test

1 Like

As the MQTT topics have changed and I realise it will be impossible to update all gateways at the same time, I propose a loraserver sub-command which will subscribe to the old gateway to NS topics and will re-publish these on the new topics.

In the opposite direction, it will subscribe to the new NS to gateway topics and will re-publish these message on the old topic.

This will be fully optional to run, but should help the migration :slight_smile:

Example:

~/W/P/L/R/loraserver (master|✚1…1) $ ./build/loraserver mqtt2to3 -c loraserver-eu.toml
INFO[0000] mqtt2to3: connecting to mqtt broker           broker="tcp://localhost:1883"
INFO[0000] mqtt2to3: connected to mqtt broker
INFO[0004] mqtt2to3: message forwarded                   topic_from=gateway/00800000a00016b6/rx topic_to=gateway/00800000a00016b6/event/up
INFO[0004] mqtt2to3: message forwarded                   topic_from=gateway/00800000a00016b6/command/down topic_to=gateway/00800000a00016b6/tx
INFO[0004] mqtt2to3: message forwarded                   topic_from=gateway/00800000a00016b6/ack topic_to=gateway/00800000a00016b6/event/ack
INFO[0028] mqtt2to3: message forwarded                   topic_from=gateway/00800000a00016b6/stats topic_to=gateway/00800000a00016b6/event/stats
INFO[0029] mqtt2to3: message forwarded                   topic_from=gateway/00800000a00016b6/rx topic_to=gateway/00800000a00016b6/event/up
INFO[0029] mqtt2to3: message forwarded                   topic_from=gateway/00800000a00016b6/command/down topic_to=gateway/00800000a00016b6/tx
INFO[0029] mqtt2to3: message forwarded                   topic_from=gateway/00800000a00016b6/ack topic_to=gateway/00800000a00016b6/event/ack
1 Like

I have just released a new LoRa Gateway Bridge test-version:

LoRa Gateway Bridge v3.0.0-test.2

Features

Basic Station packet-forwarder support

The LoRa Gateway Bridge has been refactored to support multiple packet-forwarder backends. Next to the Semtech UDP packet-forwarder, support has been added to support the Basic Station packet-forwarder. This backend implements the Basic Station LNS protocol.

Updated payload formats

The uplink payload contains a context field, used to store gateway specific context data (like the internal counter).

The downlink frame contains a timing field which can be either IMMEDIATELY, DELAY or GPS_EPOCH. Based on the timing value, an additional object must be given with the additional timing information. Refer to Commands for more details.

Fake RX time

In case the gateway does not have a GPS module, the RX time would would be left blank. This feature makes it possible to use the system time as a fallback. (#109)

Custom gateway meta-data

This feature makes it possible to expose additional meta-data in the gateway stats. Meta-data can either be static or dynamic (executing external commands). The latter option allows to for example read and expose the gateway temperature, humidity, …

Upgrading

LoRa Gateway Bridge v3.0.0 include a couple of changes that are not backwards compatible. You need to re-generate the configuration file and update it where needed. LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+. Below a summary:

MQTT topics

The MQTT topic configuration has been updated from:

uplink_topic_template="gateway/{{ .MAC }}/rx"
downlink_topic_template="gateway/{{ .MAC }}/tx"
stats_topic_template="gateway/{{ .MAC }}/stats"
ack_topic_template="gateway/{{ .MAC }}/ack"
config_topic_template="gateway/{{ .MAC }}/config"

To:

event_topic_template="gateway/{{ .GatewayID }}/event/{{ .EventType }}"
command_topic_template="gateway/{{ .GatewayID }}/command/#"

Event types are: up, stats and ack. Commands are: down and config.

Please note that LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+, but you will need to update the MQTT topics in your loraserver.toml file. Example snippet:

uplink_topic_template="gateway/+/event/up"
stats_topic_template="gateway/+/event/stats"
ack_topic_template="gateway/+/event/ack"
downlink_topic_template="gateway/{{ .MAC }}/command/down"
config_topic_template="gateway/{{ .MAC }}/command/config"

Backends

With LoRa Gateway Bridge v2 you would configure the MQTT backend under the [backend...] section. This has changed and the [backend...] section is now used for selecting and configuring the packet-forwarder backends.

Integrations

The MQTT integration configuration has moved to the new [integration...] section. This allows for adding new integrations in the future besides MQTT.

4 Likes

Hi Orne,
V3 of the Gateway Bridge code is really great achievement. The new features in both Basic Station and the Gateway Bridge look exciting. Is there any documentation available on the custom Meta Data?

Regards, Tony

Hi Orne,

Do I need to copy my previous lora-gateway-bridge.toml file as its not included in the .deb or the tar files I downloaded. I downloaded the arm7 version from https://artifacts.loraserver.io/downloads/lora-gateway-bridge/ and neither include the toml file.

Regards
Tony

The .deb file does not overwrite an old config file, however on a clean install it should generate one. Else lora-gateway-bridge -c old-config.toml configfile > new-config.toml :slight_smile:

thanks, most appreciated

Regards
Tony

Hi Orne,

Is there any documentation currently available on sending Custom Gateway meta data?

There isn’t more documentation yet than the configuration template. Stay tuned as this is still a test release :slight_smile:

No worries. Thanks for the update.

LoRa Gateway Bridge v3.0.0-test.3

Features

Basic Station packet-forwarder support

The LoRa Gateway Bridge has been refactored to support multiple packet-forwarder backends. Next to the Semtech UDP packet-forwarder, support has been added to support the Basic Station packet-forwarder. This backend implements the Basic Station LNS protocol.

Updated payload formats

The uplink payload contains a context field, used to store gateway specific context data (like the internal counter).https://www.loraserver.io/lora-gateway-bridge/gateway/multitech/

The downlink frame contains a timing field which can be either IMMEDIATELY, DELAY or GPS_EPOCH. Based on the timing value, an additional object must be given with the additional timing information. Refer to Commands
for more details.

Fhttps://www.loraserver.io/lora-gateway-bridge/gateway/multitech/ake RX time

In case the gateway does not have a GPS module, the RX time would would be left blank. This feature makes it possible to use the system time as a fallback. (#109)

Custom gateway meta-data

This feature makes it possible to expose additional meta-data in the gateway stats. Meta-data can either be static or dynamic (executing external commands). The latter option allows to for example read and expose the gateway temperature, humidity, …

Upgrading

LoRa Gateway Bridge v3.0.0 include a couple of changes that are not backwards compatible. You need to re-generate the configuration file and update it where needed. LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+. Below a summary:

MQTT topics

The MQTT topic configuration has been updated from:

uplink_topic_template="gateway/{{ .MAC }}/rx"
downlink_topic_template="gateway/{{ .MAC }}/tx"
stats_topic_template="gateway/{{ .MAC }}/stats"
ack_topic_template="gateway/{{ .MAC }}/ack"
config_topic_template="gateway/{{ .MAC }}/config"

To:

event_topic_template="gateway/{{ .GatewayID }}/event/{{ .EventType }}"
command_topic_template="gateway/{{ .GatewayID }}/command/#"

Event types are: up, stats and ack.
Commands are: down and config.

Please note that LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+,
but you will need to update the MQTT topics in your loraserver.toml file.
Example snippet:

uplink_topic_template="gateway/+/event/up"
stats_topic_template="gateway/+/event/stats"
ack_topic_template="gateway/+/event/ack"
downlink_topic_template="gateway/{{ .MAC }}/command/down"
config_topic_template="gateway/{{ .MAC }}/command/config"

Backends

With LoRa Gateway Bridge v2 you would configure the MQTT backend under the [backend...] section. This has changed and the [backend...] section is now used for selecting and configuring the packet-forwarder backends.

Integrations

The MQTT integration configuration has moved to the new [integration...] section. This allows for adding new integrations in the future besides MQTT.

Prometheus metrics

The Prometheus metrics have been updated / cleaned up.


I’ve also added vendor specific gateway .ipk packages to https://artifacts.loraserver.io/vendor/ for testing :slight_smile:

3 Likes

LoRa Gateway Bridge v3.0.0-test.4

Features

Basic Station packet-forwarder support

The LoRa Gateway Bridge has been refactored to support multiple packet-forwarder backends. Next to the Semtech UDP packet-forwarder, support has been added to support the Basic Station packet-forwarder. This backend implements the Basic Station LNS protocol.

Updated payload formats

The uplink payload contains a context field, used to store gateway specific context data (like the internal counter).

The downlink frame contains a timing field which can be either IMMEDIATELY, DELAY or GPS_EPOCH. Based on the timing value, an additional object must be given with the additional timing information. Refer to Commands for more details.

Azure IoT Hub integration

LoRa Gateway Bridge now has support to connect the Azure IoT Hub MQTT interface. Like with the Google Cloud Platform IoT Core integration this
makes it easier to scale up and manage gateway credentials using the IoT Hub console (or API).

Fake RX time

In case the gateway does not have a GPS module, the RX time would would be left blank. This feature makes it possible to use the system time as a fallback. (#109)

Custom gateway meta-data

This feature makes it possible to expose additional meta-data in the gateway stats. Meta-data can either be static or dynamic (executing external commands). The latter option allows to for example read and expose the gateway temperature, humidity, …

Upgrading

LoRa Gateway Bridge v3.0.0 include a couple of changes that are not backwards compatible. You need to re-generate the configuration file and update it where needed. LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+. Below a summary:

MQTT topics

The MQTT topic configuration has been updated from:

{{}}
uplink_topic_template=“gateway/{{ .MAC }}/rx”
downlink_topic_template=“gateway/{{ .MAC }}/tx”
stats_topic_template=“gateway/{{ .MAC }}/stats”
ack_topic_template=“gateway/{{ .MAC }}/ack”
config_topic_template=“gateway/{{ .MAC }}/config”
{{}}

To:

{{}}
event_topic_template=“gateway/{{ .GatewayID }}/event/{{ .EventType }}”
command_topic_template=“gateway/{{ .GatewayID }}/command/#”
{{}}

Event types are: up, stats and ack.
Commands are: down and config.

Please note that LoRa Gateway Bridge v3 is compatible with LoRa Server v2.7+, but you will need to update the MQTT topics in your loraserver.toml file. Example snippet:

{{}}
uplink_topic_template=“gateway/+/event/up”
stats_topic_template=“gateway/+/event/stats”
ack_topic_template=“gateway/+/event/ack”
downlink_topic_template=“gateway/{{ .MAC }}/command/down”
config_topic_template=“gateway/{{ .MAC }}/command/config”
{{}}

Backends

With LoRa Gateway Bridge v2 you would configure the MQTT backend under the [backend...] section. This has changed and the [backend...] section is now used for selecting and configuring the packet-forwarder backends.

Integrations

The MQTT integration configuration has moved to the new [integration...] section. This allows for adding new integrations in the future besides MQTT.

Prometheus metrics

The Prometheus metrics have been updated / cleaned up.

3 Likes

Is there a particular branch that we should be using from Github in order to build/test this if we are running with additional Yocto layers for our devices?

Thanks :slight_smile: