Discussion: Recover data after network outage

TTN Network and Services
21

In the device firmware

22

From my experience and the work I do I can only give the following comments (not naming providers or can I?)

There are the 3 GSM/LTE - Mr V, Mr M, Mr C and MR T (in SA)

Mr C are piggy backing on Mr. V and M

3 of them have essentially their own infrastructure and sharing some recourses.

Very often Mr V, M and T will site share (Mast and fenced land, own container and power).

Mr V have all their own back haul and nearly at all sites have batteries (in KZN).

MR M have mostly their own back haul and try to have batteries at all sites. They use at certain points MR T to supply additional back haul backup.

Mr T have all their own back haul and batteries disappear before the site is commissioned.

Conclusion try and use min 2 gateways and try to see if they fall in different load shedding areas. (_sePush app).

For the backhaul I will also try and get the gateways to connect to GSM sites that fall in different load shedding areas although MR V most probably are you best bet with battery backup. ( Not saying MR M or T does not have)ā€¦ Also a duel SIM card router might be a option.

23

I meant the code that sends the downlink. it seems like a custom downlink is required to make this work.

24

The stack / servers have no knowledge of what a downlink does - it takes the byte array and organises its transmission to the device. The message formatting is up to you.

If by custom downlink you mean the firmware has to respond to a particular downlink, then yes, it is a function of the firmware, just in the same way that many many devices have different firmware from each other for uplinks.

The main point is that itā€™s nothing to do with TTS or any other LoRaWAN server code, its all about the firmware. No gateways need be involved either.

25

I guess I donā€™t see how what he proposed will work without some sort of downlink message being generated to tell the node what something about the last ā€œnā€ number of transmissions received. The node somehow has to know what the server had last received since the outage if you arenā€™t going to do confirmed uplinks. Excuse my ignorance on this, but I guess Iā€™m trying to figure out how does one automate this downlink generation from the server end so an appropriate downlink message could be sent automatically to the node periodically as he described? The node firmware is trivial, but something must compliment it on the other end to tell the node something in a automated fashion.

26

A device will never know there has been an outage - it should be fat, dumb & happy sending out std uplinks in to the void and every so often, depending on the regional settings, the MAC will send the uplink as confirmed to check connectivity.

All the action is on your server (note, not the TTS server, YOUR server). Your data store will (or should) have the the uplink count (f_cnt), seeing which uplinks are missing should be simple enough.

Then there is a world of possibilities for sending a request to the device - either to get some decimated (summarised) copies or interleaved copies (like an old fashioned JPEG - you get the rough detail and then it comes in to focus) or cherry pick certain ones or just replay them - these have to be packaged so they arenā€™t misinterpreted as live uplinks and need some sort of sequence counter if the f_cnt isnā€™t directly available.

To aid this there are compression libraries that allow you to stuff payloads in and get compressed data out without worrying about sleeping. Iā€™ve been getting around half size so with a bit of RAM or even using some flash or external flash/fram you can have quite a history stored in a circular buffer.

27

TTN is just a (very very limited) pipe.

To build something like this, your firmware and your server infrastructure need a scheme to interact through the very limited channel TTN provides in between, keeping in mind that:

  • it is uplink mostly, downlinks need to be rare

  • uplink volume is also very limited

  • packets are lost and confirmation not affordable; you can only see in the eventual behaviour of the other side if something got through.

So, eg, your server consuming the data sees a gap and then the flow resumes. It sends a summary request, but doesnā€™t see any summary response. Half a day later it sends a summary request again, and in the following hours starts seeing summary data in addition to live data.

1 Like