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:
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).