Hi,
I am very interested in fog computing, and I am studying how to combine LoRaWAN with it. The basic idea of fog computing is to do the calculations close to where the data is generated, reducing the pressure on the cloud.
As for LoRaWAN, one way is to add a server down next to the gateway.I’m thinking about the feasibility of this approach, and I have some questions I’d like to ask you guys.
How do you determine the workload of a gateway, CPU? Memory? Number of network requests?
Are there data sets for real-world gateway workloads?
How do I get workload logging of the gateway through simulation?
Implementing a LoRaWAN server next to a gateway results in a private LoRaWAN implementation, TTN is about a community network, not private implementations. So while fog computing might be a nice concept, it does not match the TTN goals.
The very design of a LoRaWAN is fundamentally incompatible with fog computing at gateway level for purposes of networking management.
The whole point is that multiple gateways comprising a network dynamically cooperate, so an individual gateway has no way of knowing if it should respond to a particular node transmission, or if another gateway is going to do that - two trying to do so at once would be an absolute failure. Only a server managing all of the gateways reachable from a particular geographic location has the necessary visibility to implement the network side of the protocol.
Further, LoRaWAN is designed for the gateway not to need to be trusted with any encryption secrets - which makes collaborative networks like TTN possible, as the owner of a gateway literally cannot decode traffic flowing through it from other users nodes.
The amount of computation that needs to be done to handle a gateway’s worth of traffic is fairly low in modern terms, so there are indeed gateways sold which can run an on-board LoRaWAN server. But such an installation does not scale as it only works for a single-gateway network, it’s really a “demo” of the idea for possible private network installations which would need to move the server to the cloud before they could expand to multiple gateways.
And the lack of scalability means that it is entirely incompatible with a distributed, shared network like TTN.
I disagree that there is a fundamental incompatability issue with private networks. LoRaWAN is simply an over the air protocol for secure end to end encryption and end-device radio management. Nothing mandates the network infrastructure model.
One model is the central network server where all gateways at as a single virtual antenna.
It is not impossible to run the network server at the edge and provide a scalable solution for cloud computing. There are trade-offs that make it more complicated than a centralized model. That will be the case for nearly all fog computing. How do you handle shared session state at the edge?
Isn’t this in line with packet broker and private TTN?
The other trade-off is regarding ISM medium access. Seperated networks will create more RF traffic so wide area private networks in the open will create more traffic. However, adding end devices in any area creates more traffic regardless of network affiliation, it just does not fit the business model for some companies.
That is certainty not impossible, however as I stated before that will result in a private LoRaWAN implementation. While packet broker enables uplink ‘roaming’ for nodes but is not optimized for downlink traffic due to the small response windows of LoRaWAN, if downlink traffic is possible at all.
For the community network this won’t contribute anything at all, for a private TTI instance it will work if you use a single gateway for a small network.
Fog computing is not the right model for a LoRaWAN deployment with multiple gateways that have overlapping coverage, in that case a single back-end needs to coordinate all the gateways. I’m not saying it is impossible to make it work, someone might well invest a lot of time and create a working solution, however there is no gain compared to a centralized back-end. Fog computing for multiple gateways requires processing power at several locations where a single back-end (for a reasonable private LoRaWAN deployment) would be sufficient.
The other aspect of fog computing is the ability to push different compute functions to the edge. The amount of information that the LoRaWAN sensors can sent to the gateway is very small and tend to have very low informational content. So edge computing to transform the information can be done with very small micro-controllers. Normally, Smart IoT gateways have higher informational streams, such as video, and need to fuse information across these streams, and edge computing is a better mouse trap in that use case.
Can somebody point me to research that measures the data ingress/egress of a LoRaWAN gateway.
Not without being able to read that information, which needs the secrets that would then need to be synchronized to all gateways that might ever receive a packet for a node. So, @kersing is right:
A spec-compliant LoRaWAN network server cannot do its job without timely information from all locally participating gateways, hence it cannot run on a gateway unless the gateway is receiving input from all other local gateways - at which point it is no longer “fog computing” but an elected master - with the additional problem that routing traffic between peers on typical backhaul service plans is quite inefficient.
To anyone who actually understands how LoRaWAN works, trying to apply “fog computing” is a fundamentally bad and unworkable idea from start to finish.
For nodes which don’t move much, you could design some other sort of LoRa network which would assign nodes to a specific gateway such that it could autonomously interact with them until factors indicated another might be a better choice, and there might be sound reasons to do that - but it would no longer be LoRaWAN.
LoRaWAN is far from perfect, but it is what it is.
And in the alternate network topologies you describe, compliant LoRaWAN devices will be compatible. So it is still LoRaWAN, just not “true” LoRaWAN as you choose to define.
Indeed there are additional challenges, but also reduced cost in lower back-haul traffic and local network functionality during a back-haul outage.
It is one thing to say that traditional LoRaWAN, as envisioned/designed/supported, does not support this. It is another thing to write off an idea as bad, unworkable, or has no gain over the centralized model.
Are these topologies compliant with the LoRaWAN specification?
LoRaWAN is anything that complies with with the specifications as provided with the LoRa alliance. (If you want to be pedantic, anything that has successfully passed the testsuite and is accepted by the Lora alliance) Anything else is not LoRaWAN.