What is "LoRa Frame Buffering" in Product Features?

[Edwin]

Hey all,

The majority of the WisGate Edge devices have features to buffer the LoRa frames.
For clarification, what does that mean?
When the backhaul is available again, does it send the LoRa packets to the LoRa Server?
What happens if the frame counters are out of order? (Ex. Another Gateway (A) is receiving the packets and sends newer frames to the server, while Gateway B is buffering the frames and sends it later)

WisGate Edge Pro (RAK7289)
Buffering of LoRa frames in Packet Forwarder mode in case of NS outage (no data loss)

WisGate Edge Prime (RAK7240)
Buffering of LoRa® frames in case of NS outage (no data loss)

WisGate Edge Lite 2 (RAK7268\RAK7268C)
TF card for log backup and LoRa frame buffering (in case of backhaul failover)

WisGate Edge Max (RAK7249)
Buffering of LoRa® frames in case of NS outage (no data loss)

[cstratton (Chris)]

@Edwin

When the backhaul is available again, does it send the LoRa packets to the LoRa Server?

That’s the idea, yes, but as you note, it’s not exactly in compliance with the LoRaWAN spec

What happens if the frame counters are out of order? (Ex. Another Gateway (A) is receiving the packets and sends newer frames to the server, while Gateway B is buffering the frames and sends it later)

A spec-compliant LoRaWAN server would silently drop the out-of-order frames, including buffered ones submitted only after some other gateway had submitted current ones.

Granted, you could modify one to give them to you and instead mark them as “suspect” - eg, they could be valid data not previouslyl heard, they could be duplicates of packets already reported in by another gateway in real time, they could be replay attacks. In edge cases of rollover of the transmitted 16-bit portion of a standard 32-bit frame count rollover that may take some deeper logic changes in that the logic would also have to try for a MIC match over some rollback distance preceding the rollover[s].

[Edwin]

Thanks for the great answer Chris!

Since this is not compliant with the LoRaWAN spec, I assume Chirpstack or TTN would not have this option/feature of marking these frames as ‘suspect’ and continuing to send these out of order packets to an app server. Or is this something that can be enabled on those platforms?

[Edwin]

Oh, I think I see the option in Chirpstack under Devices. Option is called “Disable frame-counter validation”.

[cstratton (Chris)]

I believe TTN has that too, often for people testing ABP node firmwares they keep cold-starting from uplink 0.

What I don’t know is if either of these mechanisms can see back over bit 15 rolling to bit 16, though you could easily hack a node to try that.

And of course if an OTAA node has for some reason gotten a new session since, data sent in the old one probably can’t be decoded at all anymore.

Backhaul protocols would ideally have a flag for late submitted traffic though, for example, it shouldn’t be factored into an ADR algorithm, and may contain very stale bits of MAC housekeeping.

Presumably if you want to use late-reported historic data like this, you’re collecting the packets as they arrive from the serer into a database where you can check for earlier-reported copies of the same uplink.