I saw that Packet Broker is open, but can it be run on our own infrastructure?
If so, could it be used to connect a bunch of TTN (Things Stacks really) all running locally on the actual gateway?
Here’s why I ask. @xoseperezproject for running a full TTN network server locally on a Raspberry Pi gateway (with Balena) is quite interesting, especially if you consider it could be scaled out to hundreds/thousands of local gateways. If Packet Broker could tie them all together, you’d have a zero point of failure Lora network. If one gateway goes down, no problem. If one network server goes down, also no problem.
I understand that packet broker was really intended to tie network servers running in the cloud, but why not also use it to tie network servers running on the gateway?
Nope, a given LoRaWAN device can only interact with one ultimate server that “owns” the state of its interaction.
Packet broker is a [deployed but] incomplete start to a scheme for sharing gateways, it doesn’t change the basic concept of LoRaWAN as being an end-to-end conversation between a node and the server that maintains the other half of the state for that node.
I am a fan of self healing networks. It will indeed be a very useful feature to have a decentralised system of LoRaWAN network servers that talk with each other. Great idea.
Well, that’s not what either LoRaWAN or packet broker are, so if that’s what you want, you’re going to have to go back to the drawing board and come up with a different architecture. Particularly you’re going to need to figure out how to get data from nodes to a changing variety of consuming servers without a central routing authority, and then you’re going to have to figure out how to figure out which one of those servers currently “owns” the node in the sense of having the right to respond to it; and no, you can’t ask the gateways to arbitrate, because they may not all have all the same uplink reports or chose to same gateway to send the reply, and so the conflicting downlink attempts won’t necessarily route back to the same gateway which could pick one or the other.
The closest I’ve got to some element of extra robustness is holding the last few uplinks on the device and logging the uplinks on the gateway (BUT NOT FOR REPLAY). I have a prototype compressing the uplinks on device to improve capacity.
But overall, if you’ve ensured that there are two or more gateways on different backhauls providing coverage, your main point of failure is the gateway server - which in theory can be clustered. Not sure how feasible it would be to cluster the Network Server processing - I guess that would be down to having a clustered backend. Hmmm.
While I don’t know much about the Things Network implementation, but it does not seem infeasible to make a decentralized system. Today, decentralized networks are all the rage. There is peer to peer file sharing(Torrent), decentralised crypto currencies(Bitcoin), smart contracts that run on block chains(Ethereum). It seems feasible to make many LoRaWAN network servers to talk with each other, without leaking any secret data.
There is another kid on the block, the Helium network, that implements a block chain like system, but this is restricted only to their rewards system(HNT). But the LoRaWAN network sever is completely centralised, maintained entirely by Helium Inc. So if their servers were to go down, no messages will be passed to end-node owners.
Chirpstack takes an interesting approach with their gateway bridge, which will transform the payload to json (or proto-buff ) ON the gateway, before backhauling it to the network server. In theory then you could decouple the Lora payload handling from the cloud, and route those messages to a distributed network server in the cloud.
I get it, the gateway could be hearing tons of messages not intended for the owner of that gateway, especially in crowded airwaves, but if TTS with Basicstation can manage the gateway config from the cloud why couldn’t it tell the gateway which payloads it owns and forward the rest to the appropriate destination.
Imagine this scenario. A freight train moving refrigerated cars wants to keep an eye on its temperatures as it crosses the country. So a bunch of temp sensor nodes on its cars which happily reach a local gateway to the conductors station. It backhauls via LTE, but because its a long trip it passes in and out of LTE range. As it passes through some cities it picks up some unowned lora messages, stores them without decrypting, and passes them on when LTE backhaul is restored to be either de-duped (dropped) or accepted on another network server.
Maybe what I’m actually asking is… How long before mesh LoraWAN?
To repeat what was already explained, LoRaWAN is built around the idea of their being a single server that owns a given node.
The idea of Packet Broker is that you can on a much coarser level route from gateways to the servers that own nodes, but there’s still a SINGLE server that owns a given node, not multiple ones. The only way you get redundancy is to have coordinated state sharing between spares or coordinated load sharing for various pieces in the chain.
This is merely an irrelevant format translation, the payload remains encrypted, unchanged, and unexamined. None of what a server does is happening on the gateway.
Some gateways can run a server onboard, but that’s basically just a “try out LoRaWAN” demo mode that limits the user to a private single-gateway network - pretty much the exact opposite of TTN.
Nope, because you have all the already mentioned problems of LoRaWAN needing a single server to own a given node.
That is done on a network level, doing it on a node level requires too large a “routing table”. Besides, a gateway can’t reliably tell nodes apart, because the 32-bit address space has overlaps. A node can only be uniquely identified by the combination of device address and secret Network Key, and you don’t share Network Keys with gateways or they’d no longer be secret.
A transient gateway submitting stale packets to the server has limited benefit because out of order packets are illegal in LoRaWAN. And, a transient gateway that is in real time communication with a server wrecks havoc on the ADR algorithm.
Never, because what you are describing is incompatible with the fundamental design of LoRaWAN.
If you want to invent something else, you’ll have to invent something else.
But first it would be a good idea to actually understand how LoRaWAN works, and why your ideas are incompatible with that, in order to identify all of the problems you’d have to solve to invent some very different network scheme that could work the way you are thinking.
You have a long path from what you want to having a viable design for how to actually implement it. Something that could do this would be very different from LoRaWAN, with a different, only partially overlapping set of severe compromises and limitations than LoRaWAN’s severe compromises and limitations.
Thanks for educating the group @cslorabox.
But this is a exchange not an argument. Have a glass of wine. Put your feet up. There are people of all levels of understanding in any community. Cheers
) ON the gateway, before backhauling it to the network server. In theory then you could decouple the Lora payload handling from the cloud, and route those messages to a distributed network server in the cloud.
