No, it all depends on how many packets need to be sent by the gateway, and how much air time each packet needs.
How did you come up with 50%? It seems you might be mistaking duty cycle for something else?
It’s not a daily total, it needs to be taken into account each time you send:
The LoRaWAN enforces a per sub-band duty-cycle limitation. Each time a frame is transmitted in a given sub-band, the time of emission and the on-air duration of the frame are recorded for this sub-band. The same sub-band cannot be used again during the next Toff seconds where:
Toffsubband = (TimeOnAir / DutyCyclesubbband) - TimeOnAir
As for your example with one node and one gateway:
-
Assuming a node needs to keep below a maximum duty cycle of 1%, and assuming that the acknowledgement packet is smaller than the node’s original packet and that it’s using the same data rate†, then a gateway that’s only responding to that one node could never exceed the 1% duty cycle either.
-
If the node sends once per hour, then in your example the gateway needs to transmit an acknowledgement once per hour too. If that message takes, say, 165 milliseconds, after which the gateway does not need to do anything for the next hour, then you could say its actual duty cycle is something like 165 / (60 × 60 × 1000) = 0.0046%. Still then, after sending for 165 ms, it needs to keep quiet for about 16 seconds if its maximum duty cycle is 1%.
So, the backends need to know when each gateway has sent last. If multiple backends give the gateways messages to send, then how can a backend know if a gateway is available?
† For the sake of completeness: in real life, TTN prefers RX2 with SF9, so may need more air time than the node. But it can also use a higher maximum duty cycle of 10% in RX2.