Is it possible to save data on the gateway before sending it to the TTN server?
Use a Raspberry PI3 + LoraBee as a gateway with the tftelkamp / single_chan_pkt_fwd library
Currently except for data, only after receiving them from the TTN server, using Node-Red and the InfluxDB database
To avoid the possible lack of the wifi network, I would like to be able to save the data on the GW (InfluxDB database), even before sending the package to the TTN server.
This is sure I do not lose any data
In this way I will have two database tables, with redundant data, but Iâm sure I have not lost any transmission in case of wifi malfunction.
When downlinks are involved, timing might be tight, so Iâd first hand off the packet and only then do any local processing.
âŚwhich assumes that all your own packets are received by your own gateway, which you should never expect for LoRaWAN. Youâd better change your application to not rely on receiving all packets.
Also, as yours is a single-channel test gateway, I surely hope some day one or more full gateways connected to TTN will be set up in your neighbourhood. Those will be listening to all channels, and this would allow you to enable ADR, which might tell the node to limit its transmission power after which your own gateway might not receive the packets anymore.
Also note that in the gateway the packets are still encrypted, so saving locally also implies youâll have to decrypt them. If the node uses OTAA, then after each activation the DevAddr and the secrets will be different as well.
Youâre right, this is a problem, I did not remember it
I accept that not all packets can be received from the gateway âŚ
but I want all the packets that the gateway receives to be sent to the TTN server.
I try to reformulate the question
If, for some reason, the WIFI to which the gateway is connected, has a problem for a few hours, I lose all the packages or is there a method that when WIFI restart, are the packets retransmitted ?
The normal telecom approach is diversity, redundancy, resilience, 1+1, A/B - call it what you want.
Have two gateways on separate backhauls.
LoRaWAN is entirely set up to deliver reliable service based on multiple gateways.
I donât know of any gateway doing that, but it wouldnât be hard to implement. However, again that will be troublesome when downlinks are involved. Say the node requests a confirmed uplink, or TTN decides to send some ADR command, then the (Class A) node will only be listening for such downlink at a specific time after sending the uplink.
(As far as I know, TTN does not really use any time that the gateway might include in its messages to see if itâs an old message. The LoRaWAN protocol just expects real-time data.)
Also, if other gateways were able to forward some of the packets to TTN, then due to the frame counters TTN will reject any older packets it receives later, even if it has not received them from any gateway before.
This can be done in the city, redundant wifi with different networks, but trying to inform me and get to know Lorawan, I read about projects of control of large agricultural areas, in this case I see it difficult to have redundant gateways on different wifi networks.
May-be gateways use 3G/4G or fixed internet in rural areas?
None of the packet forwarders I know implement this and given the issues it will cause with OTAA responses, downlinks and MAC commands I donât think it will be implemented soon. (Murphy will prove me wrong ) As suggested by others on this thread, multiple gateways are the solution.
I like the idea of queuing and delayed (re)transmission as a fault-tolerant measure for calamities like network outage where the gateway is (âtemporarilyâ) unable to contact the backbone.
This will of course only benefit upstream messages (not downstream as LoRaWAN would need to support that, and would not make sense for OTAA join requests).
Multiple gateways is the solution
Multiple gateways alone will not always suffice and will also not help in cases of TTN infrastructure outages.
Two aspects are of importance why queuing and delayed (re)transmission from gateway to backend may be useful:
Lack of gateway coverage (e.g. rural areas).
The severe restriction on allowed downstream messages per day. For this reason in many/most cases use of message acknowledgements is not an option.
From functional perspective queuing and delayed (re)transmission of upstream messages may proof useful in certain use cases and is a feature that could be implemented on a gateway.
This feature could lower the risk of losing useful information.
Or you could take that into account in your application(s). For instance send the last X measurements in each transmission. That will add airtime, but with buffering you will need to add timestamps for the measurements as you canât rely on the network timestamp anymore.
BTW, if someone implements buffering, make sure the back-end knows the packets are âstaleâ and does not attempt to transmit any response. Also I would want my application to know the data is stale without having to add timestamps to the data, I can currently rely on data being delivered near real time (required to be able to schedule downlinks) so I can ârelyâ on the network timestamps.
âŚwhich also solves the problem that, say, one gateway may have received and forwarded only the 10th packet, after which any earlier buffered packets 1 thru 9 from another gateway will be rejected due to the frame counters.
At the conference, some work on a protocol using CRC/recovery/parity error correction was announced.
If the resilience that comes using multiple gateways is not adequate for your purposes then I think that you should look to deploy The Things Network Stack V3 which should be released soon. This will enable you to run both a LoRaWAN gateway and a complete LoRaWAN server core at the gateway site. Then you can store, buffer and queue the traffic in any way that you want.
Iâm looking forward to trying to run a gateway and TTN network stack V3 core on an RPi3.
If you are looking for solution that guarantees that your data will always arrive, donât use LoRaWAN.
LoRaWAN is and will always be a best effort communication technology, running on top of best effort internet technology, and in this case also using the best effort TTN application stack.
In your case I wouldnât put my effort in hacking together a probably non-compliant store-and-forward gateway, but just build a regular wireless sensor network that stores data locally and uploads it whenever a connection is available (so a central datalogger that captures and stores data from the sensors). You can use regular LoRa for the sensor-to-datalogger connection, or any other RF technology.
Hi @Batigolle,
That is what I understand. Please see Johan Stokking video on youtube dated about 6 weeks ago called âAnnouncing The Things Network Stack V3â. https://www.youtube.com/watch?v=dvYREtWc1lA&t=81s
I have worked a lot on 4G/LTE networks and they are going the same way - you can run an entire 4G/LTE network core on an RPi using OpenEPC.
I think the TTN tech leaders are very smart and understand that the future will be a large number of small LoRaWAN network cores in a peering network, just like 4G/LTE cellular.
) As suggested by others on this thread, multiple gateways are the solution.