28 Bandwidth and Channel Capacity
28.1 Start With Capacity as a Shared Resource
Bandwidth is the ceiling, not the useful delivered value. Headers, retries, collisions, scheduling gaps, and weak links all reduce what applications actually receive.
For IoT planning, start with the messages the estate must carry and the deadlines they must meet. Then compare that demand with channel capacity, overhead, and contention so the design has evidence before deployment.
Overview: Capacity Is Not the Same as Useful Delivery
Bandwidth is the nominal amount of data a link can carry per second. Channel capacity is the practical limit set by the medium, radio conditions, modulation, coding, channel access rules, and interference. Throughput is what actually gets delivered after contention, loss, acknowledgements, and retries. Goodput is the useful application payload left after protocol overhead.
IoT design needs all four terms. A sensor that sends a small reading every few minutes may need little average bandwidth, while a shared wireless channel still needs enough airtime margin for bursts, retries, acknowledgements, and neighboring devices using the same medium.
The traffic shape usually matters more than the headline rate. Periodic telemetry is predictable, event bursts are short and concentrated, firmware updates are rare but large, and control loops may care more about delay than volume. A link that looks safe on a daily average can still feel full during an alarm storm, power restoration, shift change, or gateway reconnect.
Use capacity numbers as a filter, not as a final decision. First ask whether the medium can carry the application payload during the busiest credible window. Then ask how much of that capacity is consumed by headers, encryption, channel access, retransmissions, route or join traffic, and return-path messages. The result is a delivery budget, not just a larger number on a datasheet.
That delivery budget also keeps options honest: a low-rate link can be correct for sparse telemetry, while a high-rate link can still fail a synchronized burst if the channel access and retry behavior are ignored.
Bandwidth
The advertised or configured rate of a link. It is a ceiling, not a promise that every payload byte arrives as useful application data.
Throughput
The delivered rate after protocol behavior, channel access, retransmissions, and scheduling have taken their share of the link.
Goodput
The application payload rate after headers, acknowledgements, retries, keepalives, encryption overhead, and management traffic are excluded.
More bandwidth can carry more simultaneous data, but it does not automatically reduce propagation delay, wake-up delay, queueing delay, radio scheduling delay, or application response time.
What Makes a Link Feel Full
Practitioner: Build a Capacity Record Before Selecting a Link
A useful capacity record starts from device behavior. Count devices, payload bytes, reporting interval, event bursts, protocol overhead, acknowledgements, retries, and growth margin. Then compare the result with the link's usable capacity and the medium access rules.
The formula is a starting point, not the whole answer. It estimates average offered load. A release-quality record also asks when messages arrive, whether many devices transmit at once, how much protocol overhead each message carries, whether the return path carries acknowledgements or commands, and how the link behaves under loss.
For example, 300 devices sending a 40-byte application reading every 5 minutes produce 300 x 40 x 8 / 300 = 320 bps of payload average. If the real exchange is closer to 100 bytes after framing, addressing, security, acknowledgement, and supervision overhead, the average carried by the link is about 800 bps before retries. That number is still small, but it is a better starting record than the payload-only estimate.
Now change only the timing. If the same 300 devices reconnect after an outage and send that 100-byte exchange inside a 15-second recovery window, the offered load becomes 300 x 100 x 8 / 15 = 16,000 bps. On a 250 kbps PHY, the raw data portion alone occupies nearly one second of airtime before clear-channel checks, acknowledgements, backoff, and retries. That is why the record must show both the normal interval and the busiest plausible window.
When a value is estimated rather than measured, mark it as an assumption and name the retest trigger. Payload size, firmware batch size, retry rate, and command frequency are common places where early records become stale.
Capacity Record Checklist
Worked Sizing Record
Do not turn a rough traffic estimate into a price or lifetime promise. If costs, subscription tiers, duty-cycle rules, or battery life matter, verify them from the selected vendor, region, radio settings, and measured payload schedule.
Under the Hood: Airtime Turns Average Load into Collision Risk
On a shared medium, a packet does not consume only its payload time. It consumes preamble, headers, inter-frame spacing, acknowledgements, backoff, retransmission opportunities, and sometimes channel-scan time. The practical question is not just "How many bits per second?" It is "How much airtime is occupied when the medium is busiest?"
Collision risk rises when independent transmitters choose overlapping airtime on the same channel and cannot coordinate well enough to avoid each other. Hidden nodes make this worse: two devices may both believe the channel is clear because they cannot hear each other, while the gateway receives overlapping signals.
Airtime math makes the risk visible. At 250 kbps, a 100-byte frame contains 800 raw bits, so the data portion takes about 3.2 ms before turnaround time, acknowledgement handling, contention windows, or retransmission. If 100 devices try to report in the same second, those data portions alone occupy about 320 ms of channel time. Add 20% retries and the raw data time becomes about 384 ms, before the random waits that spread or delay those attempts.
That does not mean the link is automatically overloaded. It means the release check must match the access method. A scheduled link needs slot capacity and clock discipline; a CSMA/CA link needs carrier-sense assumptions, backoff behavior, hidden-node evidence, and retry limits; an ALOHA-like link needs a low enough offered load that collisions remain tolerable. The under-the-hood evidence should explain which of those assumptions protects the busiest window.
A good review therefore records both the physical rate and the access rule. Without both, teams can confuse a raw-data calculation with a channel-availability calculation.
Contention systems
CSMA/CA-style systems listen before transmitting and back off when the channel looks busy. They work well when devices can hear enough of each other and offered load is moderate.
Scheduled systems
TDMA or centrally scheduled links reserve time or frequency resources. Scheduling can reduce collisions, but it adds coordination state and timing discipline.
Low-coordination systems
ALOHA-like access accepts some overlap and relies on sparse traffic, diversity, or retries. It is attractive only while airtime demand remains low enough.
What Reduces Usable Capacity
A capacity check is credible when it measures or models the busy window, not only the quiet average. A narrow-band sensor link can be correct for sparse telemetry, while the same link can fail if all devices report together or retry together after an outage.
28.2 Summary
- Bandwidth is nominal capacity; throughput and goodput are the delivered and useful portions after overhead, contention, and loss.
- The baseline IoT sizing formula is devices x bytes per message x 8 / interval seconds, but release decisions also need burst timing, overhead, return-path traffic, and retry behavior.
- Shared-medium capacity is governed by airtime during the busy window, not only by average payload volume.
- Collision risk rises when devices contend for the same channel, cannot sense each other, or retry together after a busy period.
28.3 Key Takeaway
Right-size IoT links from measured or defensible traffic records: average payload load, burst windows, protocol overhead, airtime, retries, and collision behavior. A high headline data rate is not a substitute for a capacity record.