A bit late (but maybe useful for future readers), your formula:
…is giving you the wrong idea due to the rounded numbers I used, and is not taking into account the (example) assumption that each node only sends once per 5 minutes:
-
When using the exact numbers, you’ll see that the airtime for 10 bytes at SF8 is 113.152 ms. Hence, for a 1% maximum duty cycle, the minimum time between subsequent transmission starts for the same node in the same sub-band is 11.3152 s.
(So, after transmitting for 113.152 ms, a node needs to wait at least 11.3152 − 0.113152 = 11.202048 seconds to not exceed a maximum 1% duty cycle.)
-
So, my “you could send 10 bytes at SF8 every 12 seconds” should read “every 11.3152 seconds”. (With “every” referring to transmission starts, not to the time between the end of one transmission and the start of the next one.)
-
With those exacts numbers, your 12 / 0.114 should read: 11.3152 / 0.113152 = 100.
This is the number of nodes that would be supported per channel per gateway if all nodes have the same time on air, all (ab)use the maximum 1% duty cycle, and by sheer luck would never transmit at the same time (at that channel, and using the same SF).
Of course, you won’t be that lucky. That’s why it’s important to interpret the duty cycle as a maximum: if during some short period in time a node needs to send rapidly after its last transmission, then it should not exceed that maximum. But it should not use the maximum all day long unless its transmission power is low and many gateways have been deployed. And that’s why TTN also defines a 30 seconds maximum airtime for uplinks, per node, per day for the public network.
-
So, you’re basically only proving that the math for the duty cycle confirms to the specification like for EU868:
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 / DutyCyclesubband) - TimeOnAir
…which is (0.113152 / 0.01 ) − 0.113152 = 11.202048 seconds
My (5 × 60) / 12 = 25 was based on: if a node’s maximum duty cycle allows for sending at most every 12 seconds, then when only sending once per 5 minutes (300 seconds), then the node is only using 12 / 300 = 1/25th of its maximum duty cycle. (Good!) Hence, when also dimensioning the network to 1%, another 24 nodes could also send at a random time once every 5 minutes while the number of collisions would then be acceptable. If, say, a 5% duty cycle for the network would be fine, that would allow for 5 times as many nodes.
Some more things to take into account:
-
All of the above numbers assume a single frequency and spreading factor. While (in EU868) for a node the duty cycle is indeed defined “per sub-band”, nodes should also adhere to frequency hopping. Like for EU868 nodes should use 8 different frequencies within the same sub-band. So, if a network supports 8 frequencies and all nodes perform perfect frequency hopping then, even if all nodes are using the same spreading factor, the network capacity might be 8 times as large.
-
In theory simultaneous transmissions using different spreading factors do not cause collisions, but apparently:
Also, it’s hard to guess how many nodes will use which spreading factor.
-
Gateways might not be able to decode all they receive. Like for the Semtech SX1301:
Several packet[s] using different data rates may be demodulated simultaneously even on the same channel.
[…]
The SX1301 can detect simultaneously preambles corresponding to all data rates on all IF0 to IF7 channels. However it cannot demodulate more than 8 packets simultaneously. This is because the SX1301 architecture separates the preamble detection and acquisition task from the demodulation process. The number of simultaneous demodulation (in this case 8) is an arbitrary system parameter and may be set to any value for a customer specific circuit.
-
Uplinks and downlink use “inverted IQ”, hence should not interfere. But as today most (if not all) gateways are half-duplex, hence cannot listen for any incoming uplink when transmitting a downlink, downlinks decrease the capacity of a gateway. (But still a downlink of one gateway should not interfere with uplinks received by other gateways.)
In short: it’s hard to give definitive numbers. (And I’m still not an expert!)