26 Bandwidth and Channel Capacity

26.2 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.

Pause at Figure 26.1 before carrying overview: capacity is not the same as useful delivery forward. Its visual vocabulary joins Traffic Patterns Determine Bandwidth Requirements to Periodic telemetry, which frames capacity planning starts by classifying traffic shape, because peaks, latency-sensitive control, and rare bulk transfers stress different parts of.

At Traffic Patterns Determine Bandwidth Requirements in Figure 26.1, compare the diagram with Periodic telemetry; then locate small, predictable messages. That labelled check bounds capacity planning starts by classifying traffic shape, because peaks, latency-sensitive control, and rare bulk transfers stress different parts of. For overview: capacity is not the same as useful delivery, retain small, predictable messages as evidence for the resulting choice.

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.

Pause at Figure 26.2 before carrying overview: capacity is not the same as useful delivery forward. Its visual vocabulary joins Bandwidth Needs vs Protocol Capacity to lower rate, which frames nominal capacity should be checked against the traffic pattern, not selected as a substitute for the traffic calculation.

At Bandwidth Needs vs Protocol Capacity in Figure 26.2, compare the diagram with lower rate; then locate higher capacity. That labelled check bounds nominal capacity should be checked against the traffic pattern, not selected as a substitute for the traffic calculation. For overview: capacity is not the same as useful delivery, retain higher capacity as evidence for the resulting choice.

26.3 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.

Ground practitioner: build a capacity record before selecting a link with the visual at Figure 26.3. Start from Bandwidth vs Throughput vs Goodput, but keep From theoretical capacity to usable application data visible while evaluating goodput is smaller than throughput, and throughput is smaller than nominal bandwidth whenever overhead, contention, or loss consumes capacity.

Begin Figure 26.3 with Bandwidth vs Throughput vs Goodput, then distinguish From theoretical capacity to usable application data and Bandwidth. The diagram separates Bandwidth vs Throughput vs Goodput from From theoretical capacity to usable application data within goodput is smaller than throughput, and throughput is smaller than nominal bandwidth whenever overhead, contention, or loss consumes capacity. In practitioner: build a capacity record before selecting a link, record Bandwidth as the deciding distinction.

26.4 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.