Offline Fallback for a Mobile LoRaWAN Gateway

Speaker 1 [00:17]

It's okay, you can begin You're alive So do we have a chair here or should I just start? Okay then I start and introduce myself. So I'm Yannis Lübbel. My normal job is working as a sensor developer at the Rosemont.

Speaker 2 [01:56]

Thank you. I'm very sorry. I wasn't here. Yeah. So, Janice. Welcome. Welcome you all here. So, again, fast lightning talks. Please subscribe. Go. Let's do it. And then the questions by the end of the session.

Speaker 1 [02:50]

THW in Germany it's a federal disaster relief organization so my talk is a bit inspired by that work and it is currently more kind of hobby project or feasibility study so at first I would like to mention some typical use cases of LoRaWAN sensors. So imagine a sunny day, you consider to go swimming and it would be nice to know the water temperature. And the lake where you want to go swimming is maybe a bit outside so there's no internet or electricity nearby. Or the opposite, it's raining a lot and you're afraid that the water level of the river is threatening your home, then you might want to observe this water level remotely. Or maybe you arranged a shipment of some valuable assets and you would like to know where they are. So let's take a closer look at some typical sensor nodes. So on the left you see a temperature, so for LoRaWAN the sensors are typically called sensor node. So on the left side you see a typical temperature sensor, in the center it's a water level sensor, on the right side it's the size of a GPS tracking device. um the interesting thing of lower one is the battery lifetime so if you take this water level sensor with one battery it can run several years without interruption the same is valid for the temperature sensor in addition it's hard to see here it has a solar panel so more or less unlimited operation time and on the right side the gps tracker yeah depending on the update rate you selected it may run for maybe a few days or one or two weeks yeah depends on your setup so let's have a look how lower one normally works so you have your sensor nodes somewhere deployed then you have so-called gateways which receive messages from the sensor nodes and they forward them to the so-called network server which is typically yeah the kind of cloud being somewhere in the internet the range between the sensors of the gateway could be under optimum condition several kilometers in densely dense areas of buildings like cities city centers and so on maybe it's just a few hundred meters okay but as you see it depends on the internet and usually this connection is done via mobile networks So there are some dependencies where we will talk about later. So at first, let's talk about what is LORWA. It stands for Long Range Wide Area Network. Well, long range means, as I mentioned before, a few kilometers depending on the environment. In Europe, it's operated at 868 megahertz. the power consumption is really low but so is the data rate. It's message based and all transmissions are encrypted. The data rate of LoRaWAN is up to 5.5 kilobits per second. This is roughly comparable to a fax machine. However, we are not limited by the availability of thermal paper, but by legal requirements. The German Bundesnetzagentur enforces a 1% duty cycle limit, which means maximum of 36 seconds per hour on air. And then, in case of the things network I'm using, there is also a fair use policy, which means maximum 30 seconds airtime per day. That sounds really low. In fact, a typical LoRaWAN data frame has about 200 milliseconds airtimes, which means about 150 messages per day, or one every five minutes. That's something you can live with for many applications let's take a closer look at the gateway it receives data frames from all nearby sensor nodes not only our own but also other sensor nodes being in the area and they are forwarded to the network server here we using the things stack sandbox which is the free tire of the things network it is available for non-commercial use for free but has some limitations for simplicity in the following I will refer just to the things network or TTN the decryption and decoding of the data which is received by the gateways happens in the cloud, which means the network server I mentioned before, and this means our operation relies on a working internet connection. On the network server, the message is matched by its device address to a corresponding session that holds keys to decrypt that message and then each of the devices we have deployed has an individual Javascript decoder which is set up in the cloud. Example of a typical decoder is shown here. You have some input data, do some operation with it, like calculation of the water level from the bytes you receive and then that is returned. So this example here is just returning the bytes it is receiving. We will come back to that later. But now our use case is we have the threat of a flooding. So the water is rising. We have our water level sensor deployed, but the internet is gone, and we don't see any data of the sensor anymore. So, what could we do? This case, my project is based on a Raspberry Pi, which is acting as a lower-band gateway that could receive the data from the nearby sensors and make it available for the user. In the following, I will explain how I'm doing that. My solution is a hybrid approach. So on the one hand, it's great that a large network like the Things Network exists, which is available with many gaps, but more or less all over Europe. And if anywhere in this network we send messages with our devices, we could finally collect them from the cloud. This is a great advantage. The opposite would be that we host the complete network server stack and all that stuff on our Raspberry Pi itself, but that means that our network will always be limited to this, I would say, 500 meters range, however the environment is. My idea is, in this case, normally the Raspberry Pi will act as a standard gateway for the Things Network, but it is also able to decode our own messages locally when the internet is gone. And let's have a look on the setup. So we have, this is the normal operation. So we have our sensors deployed in the field. We have the regular gateways transferring data to the network server. Our Raspberry Pi is doing the same. And we have, yeah, can receive data from the network server or from the Raspberry Pi to the end user. But in addition, the Raspberry Pi is exchanging some data which is required for the decryption of the data from our sensors. And that's what enables this approach. So let's start with the setup. the setup we have our antenna, a so-called LoRaWAN concentrator, that's the gateway electronics. Then there is a software called the LoRa packet forwarder, which is communicating with the hardware and forwarding all the messages to UDP port 1700. Normally that would be directly forwarded to the network server. In my case I built a multiplexer in between which is on the one hand forwarding it to the public network server, on the other hand to a local message collector process which is pre-processing the data then pushes it into a Redis pipeline which is later, where the data is later picked up by the so-called message handler, which processes it. Let's take how a typical LoRaWAN message looked like. So this is an example for an encrypted LoRaWAN frame received on the gateway. It has a message header, device address, frame counter, frame port, frame payload, which is the encrypted payload, and finally the checksum at the end. It may sometimes confusing when you start playing around with LoRaWAN that you have sometimes to enter device addresses in little or big NDN order, so it could be confusing. Each device has its own pair of session keys. It's an application session key and a network session key. Without the keys, the payload is unreadable. And they are stored on the network server. In this case, on the Things Network. I built a script, which is linked here. the request TTN devices that is collecting these session keys, stores them in a local SQLite database and makes them available for us. The little drawback of this solution is that it works only for devices that have been deployed before the disaster happens. So they must have at least once connected to the network server that I could collect the keys. But afterwards it won't work. Yeah, this is an extract from the script, extracting the keys from the things network. So I have to do two API calls for every of my applications and devices. So it could, depending on the number of devices I deployed, that could be several calls. And then you have to keep in mind that the number of API calls you are allowed to do is rate limited. So at some times you may have to put in a pause of several seconds, but there is, it's included in the request that you could consider that, or in the response of the request, yeah. Then one challenge was that as usually the LoRaWAN is being run in a cloud with a network server, most of the available packages are written in JavaScript. And yeah, it could start to be implemented for Python and even the LoRa packet which is being used for decryption, there is a Python port, but for each of these commercial devices there exists a decoder written in Javascript and I don't want to rewrite it for every single device. So the idea was instead just to take the Javascript as it is and create a small HTTP service which is encapsulating the Javascript and make it available to our Python architecture. So this is a short overview how the Node.js HTTP service is built up. So it's based on the Express framework. From the syntax it looks a bit similar to FastAPI you may know in the Python world yeah you have some kind of imports have middleware handling JSON data you include the lower packet framework then which is not shown in detail here the implementation for the message processing and finally we are offer three endpoints the first one is info it's more or less they are creating an overview of the undecoded message I've shown before the example the next one is the decryption to decrypt the payload and the third one is decoding which means applying the individual JavaScript decoder for these devices and finally they will be hosted on local host on port 3000 the typical procedure to decrypt directly in the gateway is that we have a raw frame here written in a raw data frame you wouldn't in hex numbers i split it up a bit so you see it's the same i've shown before Then it will be forwarded via Python requests to the info endpoint. We will get the device address from that, which is most important for us at this moment. Then this method looks up in our SQLite database where we have the device addresses and all the session keys. We get the session. then we do another requests call now to the decryption endpoint where we provide the here it's called payload but it's the full message as it's not just the payload which is decoded but it's also so things like the frame counter considered so yeah you could not just replace the frame counter so it's it's connected with each other yeah then you have the application session key you need to supply it's for the decryption itself the network session key is for verification of the message the result of our example payload here is shown here and i will later show you what's inside yeah now the next step is the decoding so we have the decrypted message we call our third API endpoint we supply the decrypted payload then an application ID in our case it's demo the device ID which is hello world and the frame port which is here just one the information that the application is called demo on the device hello world was also in our SQLite database so the device address was connected to that however for foreign people it is invisible that connection and even they sometimes the mapping may even change when you reconnect the session to the to the lower network server then it will be a different device address but the device itself would stay the same yeah yeah then we have here a bit more individual decoder. It's here stored in our file hierarchy under decoders, demo, and then hello world.js and this is taking the input data and is converting that to UTF-8. Yeah, our data we are receiving is stored in SQLite database. We also collect, I will mention that later, we make it available in port 8080 with FastAPI and the data would stay accessible offline. Here is an overview, so we have the process of the message handler, the database with the messages received at the gateway. In parallel we have the process requesting the messages from the things network, which is stored in the session keys database. And finally we have the storage fetcher. This is collecting messages for all devices that have been received by other gateways are connected to the things network they are stored in another database for our end user the data from these two databases is merged to provide a consistent access to the data we have another process which could when the session keys become available later when we already received the message we have a reprocess messages process yeah but the interesting part is what happens when we finally get our blackout and that's shown here we cannot do the connection to the things network anymore which means no new information in the session keys no new information on the messages received over there so this means these databases are frozen then marked blue because of that but our message handler will still receive data from our own gateway as long as the session keys do not change it could be decoded in the gateway messages supplied via API

Speaker 2 [24:25]

extend existing gateways for offline storage rather than introducing a new device in the ecosystem

Speaker 1 [24:43]

just to another device and then you could maybe put a Raspberry Pi just for as a storage device in the same network like the gateway and do the same with that approach that is possible maybe some gateways even have a small computer on board where you could maybe implement the same approach.

Speaker 2 [25:07]

Thank you. Are there limits per node or gateway? Limits.

Speaker 1 [25:41]

It's usually made for a very large number of devices like electricity meters in every house and then maybe a gateway in the street. That's maybe what electricity suppliers operate in some regions.

Speaker 2 [25:56]

The gateway needs power, so you must have a space location with power to place your gateway within the Lora Ridge.

Speaker 1 [26:16]

Raspberry Pi with some additional electronics so it would be a kind of power bank maybe a bit larger one and then it could be run maybe one or two days

Speaker 2 [26:32]

Thank you. If there are more than one Raspberry Pi connected to the same sensor, is there a risk of message duplication?

Speaker 1 [26:47]

to the network server would normally be deduplicated so it's no problem as you have could have many gateways in the city as well if you are operating the Raspberry Pi independently they don't have a connection to each other and then they will record independently the messages in their range then you could have duplicates if you take a look at both of them but for the messages I have locally, stored locally, I do a deduplication if I request them as client.

Speaker 2 [27:24]

is nice, but I guess you build apps on your data via the TTN API. Does your offline storage push an underdelivered message to TTN later on? If so, can you re-date the message in TTM to the initial send-out.

Speaker 1 [27:53]

but there is another limitation so TTN is storing the messages but only for 24 hours or 48, I don't know exactly so that means if you're really interested for the long term you also have to collect the data from TTN and maybe put it on a virtual machine in the internet or wherever if you want to further process it so even if you don't have a blackout this solution with the Raspberry Pi might be a nice extension to your DDN.

Speaker 2 [28:32]

about using reticulum via LoRa as the centralized network it could bypass the problem of local unavailability. I don't I don't know that stuff. How sure are we that the LLM is deciding for actually the better path in the middle of the whole run maybe it's from another thank you maybe it was a they won't be a second all right Would the offline fallback just flood the gateway when internet come back?

Speaker 1 [29:38]

To the cloud so it's just storing that locally and then when the internet comes back the gateway will collect some Messages that have been received by the things network Yeah, but that it would also do under normal connection Autonomic conditions and acting as a gateway for TTN. It's just doing when there is internet connection Otherwise, it's just processing the messages locally

Speaker 2 [30:06]

Yeah, I hear that the main concerns are about duplicates and loss of data points.

Speaker 1 [30:32]

And then the sensors are also jumping between, I think, eight different frequencies, message for message. So when you have a disturbing signal on one of the frequencies, maybe the next one will

Speaker 2 [30:47]

Thank you very much. Big applause for her. Thank you, you too, for staying here. So, have a great evening.