Gateway Backhaul Bandwidth Calculation

Hi
I want to calculate the required backhaul bandwidth for the 16-channel 7249 Gateway. Assume it is working in full capacity. The traffic is forwarded to AWS.
Is there an equation for estimating the bandwidth? Assume the sensor payload 5 Bytes.

Thanks

This is very use case dependent - how many sensors, how often they transmit …

But overall, it’s just multiplying them out.

So, 10,000 sensors transmitting every 30 minutes with a payload of 5KB:

10000 x 2 x 5120 = 102,400,000 bytes per hour = ~290,000bps + gateway <-> network server housekeeping + Cat videos …

The most important issue is network latency between gateway & network server.

Also consider, it is likely to be better to have three or more gateways, one of which is on a different backhaul than the other two.

That’s not really very compatible with LoRaWAN. It’s not impossible but would require fragmenting each message into many packets, and LoRaWAN doesn’t really offer any mechanism for re-assembly so you’d have to do that yourself. Nor is there any good retry mechanism you could use to get just the missing fragments of a message.

There is some possibility that a (probably custom) non-LoRaWAN LoRa scheme might work, but even then the radio utilization would be atypically high and you may run into regulatory limits depending on your location. Also you’d be churning through a lot of battery.

The ultimate answer is that you may have chosen the wrong technology for your purpose, and may need to look into something like LTE-M instead.

Doh! Good spot @cstratton

Sorry, this is a typo, I meant 5 Bytes. I know LoRaWAN maximum payload is 64 Bytes.
But I am assuming the the 16-channel are fully utilised.

That’s better. But there’s overhead in the protocol (about 13 bytes). And then the gateway<>server protocol adds more overhead. I think last I looked a brief node uplink turned into maybe something like 300 bytes of binary header + JSON in the UDP protocol. Guess maybe 512 for budgeting. If you use the chirpstack MQTT protocol that will add overhead and housekeeping too, but 512 is probably still safely an overestimate.

Actually it depends on the spreading factor and applicable regulations in your area

That simply won’t happen in LoRaWAN.

Nodes are supposed to select uplink frequencies with fair randomness; but that inevitably means collision. The busier your network, the less likely packets are to get through. It’s also not just a matter of frequency; in theory a gateway can demodulate packets on the same frequency at different spreading factors, but there are only so many demodulators in the chip available to assign. Additionally a node close to the gateway may manage to block out distant nodes on all frequencies.

People have written papers with models of capacity, in reality you probably have to try it in a possible usage and see how it works and scales.

But in terms of figuring out what Internet plan you need, I’d probably take the number of nodes and their interval and multiple by 512 (or simply divide by 2 to get kilobytes) and then compare against cost tiers.

Remember also that someone else’s node traffic may get reported in, too. In theory you could add some filtering in the gateway to drop the obviously irrelevant stuff there. You may even want to build some “alarms” if you start using a lot of backhaul bandwidth so that you can investigate why before you get cut off or hit with overage charges.

1 Like

Thanks Chris, I will consider your points.