40000 sub-GHz sensors sit under 60 gateways in the European 868 MHz band. A 24-byte configuration change must reach every device. Gateway transmission is bounded by the ETSI EN 300 220 duty cycle - 1% on the sub-band in use - and one downlink frame at the spreading factor in use occupies roughly 150 ms of airtime. Roughly how long does the fleet-wide change take and which assumption would you attack first?

The assumptions, stated

• 1% duty cycle means 36 seconds of transmit time per hour, per transmitter, per sub-band (ETSI EN 300 220-2; 1% is also quoted as about 864 seconds per day). The limit applies to the gateway's transmitter, not only the device's, which is the fact most capacity plans miss.
• One downlink frame costs about 150 ms of airtime. Airtime is dominated by the spreading factor: the slowest settings are roughly an order of magnitude more expensive per frame than the fastest.
• 1.4 frames per device on average, allowing for retries and acknowledgements.
• The same 1% budget also carries join accepts and routine acknowledgements, so assume only 30% of it is available for the campaign.

The arithmetic

Airtime per gateway per hour      36 s
Frames per gateway per hour       36 / 0.15        = 240
Frames per hour  (60 gateways)    240 x 60         = 14,400
Frames needed    (40,000 x 1.4)                    = 56,000
At 100% of the budget             56,000 / 14,400  ≈ 3.9 hours
At 30% of the budget                               ≈ 13 hours

Call it half a day to a day, and that is the optimistic version, because the figure assumes every device is reachable and every frame lands first time.

The constraint the arithmetic does not show

In a Class A device the gateway may only transmit in the short receive windows that follow an uplink. A device that uplinks every 30 minutes cannot be told anything for up to 30 minutes, no matter how much airtime is free. So the campaign's duration is the maximum of the airtime figure and the uplink interval times the number of retry rounds, and for a daily-reporting device the answer is days.

Which assumption dominates the error

Airtime per frame. Moving devices to a faster spreading factor where link budget allows cuts frame airtime by close to an order of magnitude and turns 13 hours into under 2. The second lever is payload: a 24-byte delta may fit in a frame that a 60-byte full-config write would not, and frame size steps are discrete, so shrinking the payload can remove a whole frame per device.

Attack the assumption that every device needs a push at all. If the device pulls desired state on its next scheduled uplink, the campaign costs one extra short downlink per device at a time the radio is already awake, and it is paced by physics rather than by a scheduler.

What the number rules out

• Any synchronous fleet command. There is no "stop all units now" on this link. If a safety stop is required, it must be a local decision the device makes from its own sensing, with a fail-safe default.
• Confirmed delivery to the whole fleet inside an hour, which means dashboards must show a version distribution over days rather than a progress bar.
• Full-configuration writes. Send deltas against a version the device reports, and treat configuration as reported-versus-desired state reconciled over the device's own schedule.

When this is the wrong model

On a cellular or Wi-Fi fleet there is no duty-cycle ceiling, and the binding constraint moves to the platform side: concurrent connections, per-device data plan cost and the reconnection behaviour of your own ingest tier. Carrying the sub-GHz instinct ("never push, always pull") into that environment is usually still right, but for a different reason, and the sizing arithmetic is a different one.