Core Networking · Study deck

Bandwidth and Channel Capacity

Firmware is the software stored on a device.

Packet Pete is your guide for this deck.

collisionbandwidth

After studying this chapter

Learning objectives

You will be able to:

Explain: In this illustrative case, at 250 kbps a 100-byte frame contains 800 bits, so its data portion takes about 3.2 ms before preamble, turnaround time, acknowledgement handling, contention windows, or retransmission.
Explain: 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.
Explain: Those need traffic traces and radio tests.

Major section

Start With Capacity as a Shared Resource

Firmware is the software stored on a device.

Modulation is the way data changes a radio signal.
A payload is the useful data inside a message.
A protocol is a shared set of message rules.
A high stated rate can still deliver little useful data when devices wait or resend.

Major section

Start With Capacity as a Shared Resource (continued)

A lower rate may reach farther, but it keeps the channel busy for longer.

This meter story cannot prove useful delivery from a rate label.
Those need traffic traces and radio tests.
The deeper work qualifies the headline rate; it does not replace the busy-window check.
Spread routine sends.

Major section

Overview: Capacity Is Not the Same as Useful Delivery

Here, bandwidth means the link's nominal data rate in bits per second; radio-frequency bandwidth is instead measured in hertz.

Usable channel capacity is limited by radio conditions, modulation, coding, channel access rules, and interference.
Throughput is what actually gets delivered after contention, loss, acknowledgements, and retries.

Capacity planning starts by classifying traffic shape, because peaks, latency-sensitive control, and rare bulk transfers stress different parts of the link.

Major section

Overview: Capacity Is Not the Same as Useful Delivery (continued)

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.

Goodput is the useful application payload left after protocol overhead.
IoT design needs all four terms.
That difference is potential headroom, not guaranteed application capacity.

Nominal capacity should be checked against the traffic pattern, not selected as a substitute for the traffic calculation.

Major section

Overview: Capacity Is Not the Same as Useful Delivery (continued)

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.

A link that looks safe on a daily average can still feel full during an alarm storm, power restoration, shift change, or gateway reconnect.
Periodic telemetry sends small, predictable messages, and a daily average describes its volume well when reports are staggered.
Event bursts are different: alarms arrive together and create a short peak.
Many devices send on a fixed interval.

Major section

Overview: Capacity Is Not the Same as Useful Delivery (continued)

A firmware update is rare, but it moves a lot of data at once.

A control loop may send very little and still fail if the message waits too long.
The result is a delivery budget, not just a larger number on a datasheet.
Stagger reporting times and batch when latency allows.

Major section

Overview: Capacity Is Not the Same as Useful Delivery (continued)

Core distinction: 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.

The closing line in Figure: Nominal capacity should be checked against the traffic is the warning to keep: rate is one test out of five.
The delivered rate after protocol behavior, channel access, retransmissions, and scheduling have taken their share of the link.
The application payload rate after headers, acknowledgements, retries, keepalives, encryption overhead, and management traffic are excluded.
Alarms, occupancy changes, motion, or power restoration.

Major section

Practitioner: Build a Capacity Record Before Selecting a Link

A useful capacity record starts from device behavior.

The formula is a starting point, not the whole answer.
That number is still small, but it is a better starting record than the payload-only estimate.
When a value is estimated rather than measured, mark it as an assumption and name the retest trigger.

Goodput is smaller than throughput, and throughput is smaller than nominal bandwidth whenever overhead, contention, or loss consumes capacity.

Major section

Practitioner: Build a Capacity Record Before Selecting a Link (continued)

Preserve load, node count, loss rate, packet size, and time window so the comparison explains the deployment rather than only the data sheet.

Payload size, firmware batch size, retry rate, and command frequency are common places where early records become stale.
Average payload demand is small.
Burst capacity may drive the design.

Major section

Practitioner: Build a Capacity Record Before Selecting a Link (continued)

If costs, subscription tiers, duty-cycle rules, or battery life matter, verify them from the selected vendor, region, radio settings, and measured payload schedule.

Goodput must be checked, not only payload bytes.
Some reports align after wake or outage.
Deployment can fail if only averages are tested.

Major section

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.
Collision risk rises when independent transmitters choose overlapping airtime on the same channel and cannot coordinate well enough to avoid each other.
The under-the-hood evidence should explain which of those assumptions protects the busiest window.

Major section

Under the Hood: Airtime Turns Average Load into Collision Risk (continued)

The practical question is not just "How many bits per second?" It is "How much airtime is occupied when the medium is busiest?".

Airtime math makes the risk visible.
A good review therefore records both the physical rate and the access rule.
Devices wait before trying again.

Major section

Under the Hood: Airtime Turns Average Load into Collision Risk (continued)

Without both, teams can confuse a raw-data calculation with a channel-availability calculation.

In this illustrative case, at 250 kbps a 100-byte frame contains 800 bits, so its data portion takes about 3.2 ms before preamble, turnaround time, acknowledgement handling, contention windows, or retransmission.
They work well when devices can hear enough of each other and offered load is moderate.
Latency rises even when payload size is small.

Major section

Under the Hood: Airtime Turns Average Load into Collision Risk (continued)

If retries add 20 more full-frame transmissions, the data-portion total becomes about 384 ms, before the random waits that spread or delay those attempts.

Scheduling can reduce collisions, but it adds coordination state and timing discipline.
Stagger transmissions and reduce synchronized bursts.
Transmitters cannot sense each other.

Major section

Under the Hood: Airtime Turns Average Load into Collision Risk (continued)

ALOHA-like access accepts some overlap and relies on sparse traffic, diversity, or retries.

Gateway sees collisions that senders did not predict.
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.
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.

Major section

Summary · Key Takeaway

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.
Right-size IoT links from measured or defensible traffic records: average payload load, burst windows, protocol overhead, airtime, retries, and collision behavior.

Deck summary

Key takeaways

Firmware is the software stored on a device.

A lower rate may reach farther, but it keeps the channel busy for longer.
Here, bandwidth means the link's nominal data rate in bits per second; radio-frequency bandwidth is instead measured in hertz.
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 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.

Retrieval practice

Recall check 1 of 3

Packet Pete says: answer from memory, then check your reasoning.

Q1A sensor link has enough nominal bandwidth for the average payload calculation, but users still see delayed readings during shift changes. What should be checked next?

AOnly the advertised maximum link speed, because bandwidth and latency are the same design variable

BOnly the payload size of one device, because collisions do not affect useful delivery

COnly the monthly connectivity price, because cost proves whether the link is adequate

DBurst timing, shared-channel contention, and retries during the shift-change window

Show answer

Answer: D Average bandwidth can look safe while synchronized bursts, contention, and retransmissions create queues and radio delay.

Retrieval practice

Recall check 2 of 3

Packet Pete says: answer from memory, then check your reasoning.

Q2A team calculates average offered load as devices x bytes x 8 / interval seconds. Which additional item must be added before treating the number as a release-ready capacity record?

AA larger headline bandwidth number, even when traffic measurements do not require it

BA fixed global price per device copied across all regions and operators

CBurst timing, overhead, acknowledgements, retries, and usable medium capacity

DA decision to ignore return-path messages because sensors only send small payloads

Show answer

Answer: C The average formula is only the baseline.

Retrieval practice

Recall check 3 of 3

Packet Pete says: answer from memory, then check your reasoning.

Q3Why can a shared wireless IoT channel fail even when the average payload bandwidth is below the nominal link rate?

AAverage payload bandwidth always equals goodput, so the failure must be unrelated to the channel

BCollisions only happen on old wired Ethernet and cannot happen in wireless IoT channels

CIncreasing payload size always reduces airtime because fewer messages are sent

DAirtime can be consumed by overhead, synchronized bursts, retries, backoff, and hidden-node collisions

Show answer

Answer: D The nominal link rate does not capture when airtime is occupied or how much useful goodput remains after contention and recovery.

Print reference

Answers

Answer key.

D · Average bandwidth can look safe while synchronized bursts, contention, and retransmissions create queues and radio delay.
C · The average formula is only the baseline.
D · The nominal link rate does not capture when airtime is occupied or how much useful goodput remains after contention and recovery.