Applying Logic on LoRaWAN Packets at the Gateway level (edge)

[Tom Z]

Hi

We are building a LoRaWAN end-device and a SaaS portal (for agritech and smart-cities).

We would like to offer our customers the ability to run the end device on a public network. But we also want have edge logic functionality in our gateway. In my agritech use-cases we cannot relay on constant connection to a network or app server via cellular link, so we want the gateway to apply logic on incoming packets, and when needed, communicate to nodes accordingly.

For example: a sensor node detects a water leak, the gateway communicates to the valve switch to shutdown the pipe.

From my understanding, in typical LoRaWAN configuration, where has just packet forwarding functionality, the communicate will have to go all the way to the application server, and then back to the end-device via the gateway.

So we are looking to have the logic happen on the gateway level but still use LoRaWAN so that we can have just one firmware across all of our end devices.

With the Multitech Network Server, I guess the gateway can decode the packets, and then run a node-red flow for example, to apply the logic. Is that correct? Can I still use a hosted network server solution as well (such as TheThingsNetwork), if I run the network server locally?

Our end-device will run as a Class A device.

Thanks in advance

[Jason Reiss]

The end-device will join to a single network server. This means the frame counters and session keys used for integrity checks and encryption/decryption will be known to only one network server.

[Tom Z]

Thanks for the clarification @jason, can we run both a network server and a network packet forwarder on the gateway? This way perhaps in the firmware of the device, we can send 2 messages on alerts, one to be decoded by the local network server, and the other to be picked by the main network server?

do you have any other suggestions here?

[Jason Reiss]

The ttn mp_pkt_fwd can be configured to report to multiple network servers.
https://github.com/kersing/packet_forwarder

I am not sure how the downlinks will be handled if both network servers are connected. An uplink requesting ACK would be responded by both network servers. Both network servers could attempt to send MAC commands for ADR.

Using a custom application, written in node-red, python, etc., the packets received at the Conduit could be forwarded to a remote back-end after being decrypted locally. This could be your back-end and TTN would not be needed.

The application can also detect loss of connectivity and store packets locally until connection is restored.

[Tom Z]

Great, so I could have a logic in place that if network connectivity is down, the packet will be forwarded to the locally ran network server, where it will be decoded and some action will be triggered. Otherwise it will go uplink to TTN. For that though the keys from TTN will have to be known to the locally hosted network server, is there a way to sync those?

[Jason Reiss]

No there is not support to synchronize or use two network servers effectively. Using both could be problematic if they both author downlinks. Or if only one sends a downlink then the frame counters would be out of sync and the end-device will reject packets with previous counters.

I am not understanding what need there is for TTN if the Conduit network server is being used. TTN is used to decrypt the data for your back-end which could be done on Conduit.

I suggest using only one network server.

[Tom Z]

Hi Jason

So if we go with the Conduit network server, on each gateway, is there a way to configure the network server remotely? Will it just be a script that updates the config files and resets it?

The idea here is to handle device provisioning on each gateway remotely, and also to update keys if needed.

Can we use AEP to do so?

[Jason Reiss]

With AEP our device management portal devicehq.com is available for remote upgrades and config updates.

[Author]

Posts