LoRaWAN backhaul overheads over satellite or cellular

Question

LoRaWAN is optimized for the constrained LoRa physical layer, however the gateways add their own overheads when relaying LoRaWAN frames to/from the network servers, and there is also trafic related to the operations and maintenance of the gateway.

What kind of overheads can we expect per LoRaWAN packet (i.e. on top of the LoRaWAN over the air frame size), and also how much monthly trafic is related to maintenance of the gateway ? Is this tunable for constrained/expensive backhaul like satellite or cellular ?

Answer 1

Indeed, having a Gateway-LNS backhaul with optimized signaling overhead is key for OPEX saving in case of cellular backhaul. It is even essential for backhaul connectivity over satellite.

Actility's ThingPark LRR (LRR stands for Long Range Relay, which is the name of the packet forwarder in the ThingPark platform) has been designed to optimize GW-NS backhaul traffic. Here are the main related features:

• Gateway filtering of uplink frames by NwkID, thus forwarding to NS only frames from whitelisted NwkID/NetIDs (for home devices or roaming partners): field feedback from a tier-1 Telecom Operator in France shows 80% reduction of GW-NS traffic thanks to this feature.
• Use of binary encoding instead of text-based message format (such as JSON for Semtech packet forwarder / Basic Station) --> This binary encoding is far more efficient, from compactness standpoint. It is the same reason why the LoRa Alliance has already disqualified text-based message formats (e.g. JSON) from the candidate IDL message formats for the ongoing standardization of the GW-NS protocol.
• Use of grouped acknowledgment, with IEC-104 protocol.
• Fully-configurable reporting periodicities for the different RF/WAN/System statistics, adaptable for each backhaul type.

For sake of minimizing the backhaul overhead for satellite connections, with optimized settings of the keep alive periodicity and other application-specific timers - we measured a monthly house-keeping traffic reduced to 50 MB/month (including secure IPSec tunneling overhead, but excluding LoRaWAN traffic). Combining the compact binary encoding + NwkID filtering to this optimized house-keeping overhead should yield less than 400MB of monthly volume, but the exact volume of course depends on the LoRaWAN traffic volume.

Expect a 30x reduction compared to GW to LNS backhaul protocols using JSON or similar text format.

Answer 2

Beyond the traffic generated by the devices of your network there are several other traffic components that generate load on the backhaul connectivity of your gateway. The complete list is the following:

• Device Traffic:
  • Traffic generated by your network's LoRaWAN devices
  • Traffic generated by foreign network's devices you have roaming agreement with
  • Traffic generated by foreign LoRaWAN devices, that is not filtered out based on NetID by your gateway
• OSS Traffic
  • The Gateway's regular heartbeat messages
  • Alarms (e.g.: SNMP Traps)
  • Configuration messages
  • Statistics, reports, etc.
• Software Upgades

The practical maximum number of LoRaWAN frames that an 8 chgannel gateway can forward in a day is ~100k. If we assume that every UL frame triggers a ~0.5kByte backhaul message, it results in 1.5Gbyte/Month traffic and ~5kBit/s avarage data rate.

The OSS traffic (heartbeat, alarms, configuration) will add additional ~50 Mbyte/Month uplink traffic, while remote software updates could require ~100Mbytes downlink data.

In my experience I could hardly see gateways that generated more then 1 Gbyte traffic in a month. Most of the gateways with 3G/4G backhaul are OK with being connected by a 1Gbit/Month data plan. The only exception is when we perform multiple software updates in a month.

If backhaul is an expensive resource or a real bottleneck, (e.g.: a satellite bachaul) then, we need to configure our gateway so that it does not generate any traffic that is not absolutely necessary:

• The gateway should filter out all messages that are sent by foreign LoRaWAN sensors. These messages can be identified based on DevAddr prefixes that correspond to your NetID.
• Hartbeat messages should be sent less frequently.
• The Gw shall send only critical alarms.
• Remote software updates should be disabled.

Answer 3

This will probably depend on the protocol used for the backhaul. I have never looked into the details, but I most definitely wouldn't be surprised if some were a lot chattier than others.

Taking the example shown on the TTN website for a frame sent via the original Semtech UDP protocol which sends JSON-like data:

{
  "rxpk": {
    "tmst":20900514000,
    "chan":2,
    "rfch":0,
    "freq":866.349812,
    "stat":1,
    "modu":"LORA",
    "datr":"SF7BW125",
    "codr":"4/6",
    "rssi":-35,
    "lsnr":5,
    "size":23,
    "data":"AMy7qgAAAAAATYMmmnj6AADl6YP1Jrw"
  }
}

The raw data (once base64-decoded) is 21 bytes. The overall JSON data is 258 bytes. Even if you strip whitespace that's still 191 bytes. Add to that a bit of IP and UDP headers, and you're probably very close to a x10 factor.

Other protocols are less verbose (and less readable), using protocol buffers, which probably reduce the factor a lot (x2 maybe?). But on the other hand, they may introduce additional overhead, due to the carrier protocol (gRPC or MQTT), use of encryption (TLS). TLS alone can be a killer if not properly configured.

It also probably depends on a number of network settings (including use of ADR for instance) as well as network density (which should have an influence on the number of gateways relaying each uplink).

And that's of course not counting:

• monitoring of the gateway (highly variable depending on protocols, values monitored, frequency, use of polling and/or notifications...)
• upgrades of the gateway firmware, if any
• timekeeping (e.g. NTP, if the gateway does not have GPS)

All of those will happen even you don't have any traffic. But they can be tuned quite bit. For instance, an Ethernet-connected gateway could be polled every 5 minutes while a satellite-connected one could be polled every few hours (or even rely purely on observation of traffic received from the gateway, but that really only gives you an on/off status).