50  Bandwidth Requirements

Key Concepts
  • Collision: The simultaneous transmission of two or more devices on a shared medium, causing signal overlap and data corruption
  • Collision Domain: The set of devices that can cause a collision with each other; reducing collision domains improves network performance
  • CSMA/CD: Carrier Sense Multiple Access with Collision Detection; the Ethernet MAC protocol that detects collisions and schedules retransmissions
  • CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance; used in Wi-Fi and IEEE 802.15.4; avoids collisions rather than detecting them after the fact
  • Bandwidth Utilisation: The fraction of the available channel capacity consumed by successful data transmission; collisions reduce utilisation
  • Backoff Algorithm: A randomised delay strategy used after a collision to reduce the probability of repeated collisions between the same devices
  • Hidden Node Problem: A scenario where two devices cannot hear each other but both can hear a third device; leads to collisions invisible to the senders

50.1 In 60 Seconds

Bandwidth is the maximum data rate a link can carry, but more bandwidth does not reduce latency – they are independent metrics. Most IoT devices transmit small, infrequent payloads, so networks are commonly over-provisioned by 100x or more. Calculating actual bandwidth needs from device count, payload size, and reporting interval prevents costly over-provisioning.

50.2 Learning Objectives

By the end of this chapter, you will be able to:

  • Calculate bandwidth requirements for IoT deployments accurately
  • Identify common bandwidth misconceptions that lead to over-provisioning
  • Right-size network capacity based on actual traffic patterns
  • Select appropriate protocols based on bandwidth needs

Bandwidth is like the width of a highway – a wider highway can carry more cars at once. In networking, bandwidth determines how much data can flow between devices per second. IoT devices usually need very little bandwidth (like a bicycle lane), but when thousands of sensors report at once, those small lanes add up quickly.

“We need a bigger highway for our data!” Sammy the Sensor declared. Max the Microcontroller shook his head. “Hold on, Sammy. Let me ask you something – how much data do you actually send?”

“Well, I send a temperature reading of about 50 bytes every 15 minutes,” Sammy admitted. “That is like tossing a marble down the highway once in a while,” said Max. “You definitely do not need a six-lane motorway! Even with 500 sensors like you, we would only use about 1% of a basic cellular connection.”

Lila the LED added, “And here is a big myth – a wider highway does NOT make your marble arrive faster! Bandwidth is about how much data fits at once, not how quickly it gets there. Latency is what controls speed.”

“The real trick,” said Bella the Battery, “is calculating exactly what you need. Over-provisioning wastes money AND my energy. Multiply your sensor count by payload size and divide by reporting interval – that gives you the actual bandwidth needed. Most IoT networks need way less than people think!”

50.3 Introduction

Time: ~10 min | Difficulty: Intermediate | Unit: P07.C15.U03

Many IoT engineers significantly overestimate bandwidth requirements, leading to costly over-provisioning. Understanding actual traffic patterns and calculating real bandwidth needs is essential for cost-effective IoT network design.

50.4 Common Misconception: “More Bandwidth Always Means Better Performance”

Common Misconception

The Misconception: Many IoT engineers assume that provisioning higher bandwidth (e.g., upgrading from 100 Kbps to 1 Mbps) will automatically improve application performance and reduce latency.

The Reality: Bandwidth and latency are independent metrics. Higher bandwidth increases throughput (data volume per second) but does NOT reduce latency (round-trip time).

Real-World Example: A smart agriculture company deployed 500 soil moisture sensors across a 5 km squared farm:

  • Initial design: Upgraded to 1 Mbps LTE-M cellular ($15/device/month) expecting faster sensor responses
  • Actual traffic: Each sensor sends 50 bytes every 15 minutes = 0.056 bytes/second average
  • Total bandwidth used: 500 sensors x 0.056 bytes/sec = 27.8 bytes/sec = 222 bps (0.02% of provisioned capacity!)
  • Latency: LTE-M latency remained 50-200 ms regardless of bandwidth (limited by radio protocol and tower distance, not throughput)
  • Cost impact: Wasting $7,500/month ($90,000/year) on unused bandwidth

The Fix: Switched to LoRaWAN (unlicensed spectrum, $2/device/month gateway fee):

  • Bandwidth: 0.3-5 Kbps (200x less than LTE-M)
  • Latency: 1-2 seconds (10x worse than LTE-M)
  • Result: Application requirements met perfectly (sensors don’t need sub-1s responses)
  • Savings: $6,500/month ($78,000/year)
  • Battery life: Improved from 2 years (LTE-M) to 10 years (LoRaWAN)

Key Lesson: Right-size your bandwidth based on actual data volume requirements. For most IoT sensor applications, bandwidth requirements are surprisingly low (measured in bps or Kbps, not Mbps). Focus on matching protocol characteristics to application needs rather than maximizing raw throughput.

50.6 Protocol Bandwidth Comparison

Protocol Typical Bandwidth Best Use Case Cost Considerations
LoRaWAN 0.3-50 Kbps Infrequent sensor data Free spectrum, gateway costs
Sigfox 100 bps Ultra-low data volume Subscription per device
NB-IoT 20-250 Kbps Low-medium data Cellular subscription
LTE-M 375 Kbps-1 Mbps Voice + data Higher cellular cost
Wi-Fi 10-1000 Mbps High data volume Infrastructure cost
Ethernet 100-1000 Mbps Industrial, video Wiring cost

50.7 Bandwidth Sizing Guidelines

Bandwidth Sizing Rule of Thumb

Step 1: Calculate Average Load

Use the same conversion every time: multiply devices by bytes per message, convert bytes to bits, then divide by the reporting interval.

Average bandwidth (bps) = devices x payload bytes x 8 / interval seconds.

The bandwidth calculation converts device behavior into bits per second.

Input Value
Device count 500 sensors
Payload size 50 bytes
Reporting interval 15 minutes = 900 seconds
Calculation 500 x 50 x 8 / 900
Result 222 bps

This reveals why a 1 Mbps LTE-M link would be over-provisioned by 4,500x!

Step 2: Apply Peak Multiplier

For typical IoT burst patterns, estimate peak load as 2x to 3x the average load.

Step 3: Add Headroom

Add growth headroom after peak load: Provisioned bandwidth = Peak bandwidth x 1.5.

Step 4: Select Protocol

  • < 100 Kbps: LPWAN (LoRaWAN, Sigfox)
  • 100 Kbps - 1 Mbps: Cellular IoT (NB-IoT, LTE-M)
  • 1-10 Mbps: Wi-Fi or Ethernet

  • 10 Mbps: Fiber or dedicated links

Try It: IoT Bandwidth Calculator

50.8 Traffic Pattern Analysis

Diagram illustrating common IoT traffic patterns including periodic reporting with fixed intervals, event-driven with irregular bursts on state changes, streaming with continuous high-bandwidth flows, and hybrid patterns combining periodic heartbeats with event-driven updates
Figure 50.1: Traffic patterns determine bandwidth requirements

50.9 Cost Optimization Strategies

50.9.1 Avoid Over-Provisioning

  1. Measure first: Deploy a pilot with monitoring before sizing production
  2. Use actual traffic data: Don’t rely on theoretical maximums
  3. Consider duty cycles: Most IoT sensors are idle 99%+ of the time
  4. Factor in compression: MQTT, CoAP can significantly reduce payload sizes

50.9.2 Protocol Selection for Cost

Scenario Wrong Choice Right Choice Savings
500 farm sensors 1 Mbps LTE-M LoRaWAN $78K/year
10K smart meters Wi-Fi mesh NB-IoT $120K/year
100 security cameras 4G cellular Wi-Fi + fiber $36K/year

50.10 Worked Example: Smart City Multi-Protocol Bandwidth Planning

Scenario: A city deploys a smart infrastructure pilot across a 2 km squared downtown district with four IoT subsystems. The network architect must calculate total bandwidth requirements and select appropriate protocols for each subsystem.

50.10.1 Step 1: Calculate Per-Subsystem Bandwidth

Subsystem Inputs Calculation Result
Environmental monitoring 500 sensors; 32-byte payload; 13-byte LoRaWAN overhead; 15-minute interval Per sensor: (32 + 13) x 8 / 900 seconds = 0.4 bps 500 x 0.4 bps = 0.2 Kbps average
Smart parking 2,000 spaces; 8-byte event payload; 13-byte LoRaWAN overhead; 80% of spaces change in 2 hours during peak Peak: 1,600 events x 21 bytes x 8 / 7,200 seconds 37.3 Kbps peak
Traffic cameras 50 intersections; 4 cameras per intersection; 1080p H.265 video at 2 Mbps per camera 50 x 4 x 2 Mbps 400 Mbps continuous
Street lighting control 800 poles; 16-byte control payload; 20-byte NB-IoT overhead; 5-minute reporting Average: (16 + 20) x 8 / 300 seconds = 0.96 bps per pole 800 x 0.96 bps = 0.77 Kbps average; sunset burst about 23 Kbps

50.10.2 Step 2: Protocol Selection

Subsystem Bandwidth Latency Need Protocol Choice Rationale
Environmental 0.2 Kbps Minutes OK LoRaWAN SF10 Ultra-low power, 10-year battery
Parking 37.3 Kbps peak 30s OK LoRaWAN SF7 Event-driven, low duty cycle
Cameras 400 Mbps Real-time Fiber + Wi-Fi 6 Only viable option at this rate
Lighting 0.77 Kbps 10s for dimming NB-IoT Bidirectional needed for commands

50.10.3 Step 3: Cost-Per-Bit Comparison

Network slice Cost components Year-1 cost Effective monthly cost
LoRaWAN for environmental + parking 8 gateways x $1,500 = $12,000; backhaul 8 x $50/month = $4,800; no per-device spectrum subscription $16,800 for 2,500 devices $0.56 per device/month
NB-IoT for lighting 800 poles x $1.50/month x 12 months $14,400/year $1.50 per device/month
Fiber + Wi-Fi 6 for cameras Fiber to 50 intersections = $250,000; access points = $20,000; bandwidth = 50 x $200/month $390,000 for 200 cameras $162.50 per device/month

50.10.4 Step 4: Over-Provisioning Analysis

Approach Sensor-connectivity cost Camera cost Why it matters
Common mistake: use NB-IoT for all 3,300 non-camera devices 3,300 x $1.50/month = $59,400/year Cameras still need fiber/Wi-Fi Pays cellular fees for sensors that only need Kbps
Right-sized protocols LoRaWAN $16,800/year + NB-IoT $14,400/year = $31,200/year $390,000/year for cameras is unavoidable Matches each subsystem to its real bandwidth and latency need
Savings from right-sizing sensors $59,400 - $31,200 = $28,200/year No camera savings Sensor protocol choice saves money even though cameras dominate total bandwidth

Key Insight: In this smart city deployment, 99.98% of the bandwidth demand comes from 200 cameras (400 Mbps), while 3,300 sensors collectively need only 38 Kbps. Right-sizing protocols by subsystem saves $28,200/year on sensor connectivity alone. The bandwidth calculation also reveals that upgrading sensor protocols to higher-bandwidth options provides zero benefit – the sensors genuinely need only Kbps, not Mbps.

50.11 Data Compression Impact on Bandwidth Requirements

Protocol-level compression can dramatically reduce bandwidth needs, but the benefit depends on payload type:

Data Type Raw Size Compressed Ratio Protocol Support
JSON sensor reading 120 bytes 45 bytes 2.7x MQTT 5.0 (content type), HTTP gzip
CBOR sensor reading 48 bytes 38 bytes 1.3x CoAP (native CBOR support)
CSV batch (100 readings) 5,000 bytes 800 bytes 6.3x Any protocol with payload compression
Protobuf telemetry 35 bytes 32 bytes 1.1x gRPC, custom MQTT
Base64 image thumbnail 4,096 bytes 3,200 bytes 1.3x MQTT, HTTP

Worked Example: Compression Savings for 1,000-Sensor Deployment

A building management system sends 1,000 temperature sensors at 4 messages per minute. The same information can require very different bandwidth depending on encoding and batching:

Encoding strategy Per-message calculation Deployment bandwidth Practical meaning
Individual JSON over MQTT 65-byte JSON payload + 13-byte MQTT overhead = 78 bytes/message 1,000 x 78 bytes x 4/min = 312,000 bytes/min = 41.6 Kbps Easy to read, but expensive on constrained links
Individual CBOR over CoAP 28-byte CBOR payload + 4-byte CoAP overhead = 32 bytes/message 1,000 x 32 bytes x 4/min = 128,000 bytes/min = 17.1 Kbps Same data, less text overhead
Batched CSV + gzip 100 readings x 50 bytes = 5,000 bytes raw; gzip to about 800 bytes + 50 bytes TCP/HTTP overhead 10 batches/min x 850 bytes = 8,500 bytes/min = 1.1 Kbps Best for periodic telemetry where seconds of delay are acceptable

Result: Switching from individual JSON messages to batched compressed CSV reduces bandwidth from 41.6 Kbps to 1.1 Kbps – a 38x reduction. This shifts the protocol requirement from NB-IoT ($1.50/device/month) to LoRaWAN ($0.56/device/month), saving $11,280/year for 1,000 sensors.

When NOT to compress: Compression adds latency (1-5 ms for gzip) and CPU overhead. For real-time control loops requiring sub-10 ms latency, send raw binary payloads. For periodic telemetry with seconds-to-minutes tolerance, always compress.

Try It: Compression Savings Calculator

50.12 Concept Relationships

Understanding how bandwidth-related concepts interconnect helps prevent design mistakes:

Concept Relates To Key Insight
Bandwidth Throughput, Goodput Theoretical maximum, not achieved rate
Throughput Protocol Overhead, Congestion Actual achieved rate after losses
Goodput Application Data Useful payload excluding all overhead
Latency Bandwidth (independent) Round-trip time NOT reduced by more bandwidth
Protocol Overhead Efficiency, Cost Headers reduce bandwidth utilization
Compression Bandwidth Savings 2-38x reduction but adds CPU/latency cost
Over-provisioning Cost, Waste Common mistake from ignoring duty cycles
Duty Cycle Average Usage Most IoT sensors idle 99%+ of time

Common Pitfalls

CSMA/CD detects collisions after they happen (wired Ethernet). CSMA/CA tries to avoid collisions before they happen (Wi-Fi, 802.15.4). Fix: note that collision detection requires being able to hear your own signal while transmitting — impossible in half-duplex wireless.

A switch creates one collision domain per port, eliminating collisions between ports. But a half-duplex device on a switch port still has a collision domain with its upstream port. Fix: verify that all devices and switch ports operate in full-duplex mode to truly eliminate collisions.

Two sensors at opposite ends of a warehouse may both transmit to a central gateway simultaneously, causing collisions at the gateway that neither sensor detects. Fix: use RTS/CTS mechanisms or time-slotted MAC protocols (TDMA) to handle hidden nodes.

50.13 Summary

  • Bandwidth and latency are independent – more bandwidth does not reduce latency
  • Most IoT sensors need Kbps, not Mbps – calculate actual requirements before provisioning
  • Over-provisioning wastes money – the smart agriculture example saved $78K/year by right-sizing
  • Match protocol to requirements – LPWAN for low data, cellular for medium, Wi-Fi for high
  • Data compression reduces bandwidth 2-38x depending on encoding format and batching strategy
  • Use the bandwidth calculator to estimate needs before deployment

50.14 See Also

50.15 Try It Yourself

Scenario: You are deploying smart parking sensors for a 500-space parking garage. Design the network bandwidth requirements.

Given:

  • 500 parking sensors
  • Each sensor sends: occupied/vacant status + battery level + timestamp
  • Reporting: on state change + hourly heartbeat
  • Average: 4 state changes per space per day
  • Peak hour: 80% of spaces change state in 2 hours

Tasks:

  1. Calculate payload size (hint: 1 byte status + 1 byte battery + 4 bytes timestamp = 6 bytes)
  2. Add LoRaWAN protocol overhead (13 bytes header + MAC)
  3. Calculate average bandwidth (events per day / seconds per day)
  4. Calculate peak bandwidth (peak events / peak duration)
  5. Apply 1.5x headroom for growth
  6. Select protocol: LoRa SF7 (5.5 Kbps), LoRa SF10 (980 bps), NB-IoT (20 Kbps)

Hint:

Average events per day = (500 spaces x 4 events) + (500 x 24 heartbeats) = 14,000 events/day.

Average rate = 14,000 x (6 + 13) bytes x 8 bits / 86,400 seconds = 24.7 bps.

Solution:

  • Average: 24.7 bps (any protocol works)
  • Peak: 80% of 500 = 400 spaces change in 2 hours = 200 events/hour
  • Peak bandwidth: 200 x 19 bytes x 8 bits / 3,600 sec = 8.4 bps
  • With 1.5x headroom on peak: 12.7 bps required
  • Recommendation: LoRa SF10 (980 bps) provides massive headroom at under 3% utilization
  • NB-IoT would waste $750/month ($1.50/sensor x 500 sensors) for bandwidth you don’t need

Key Lesson: Calculate actual usage, not theoretical maximums. Don’t over-provision!

50.16 What’s Next

Topic Chapter Description
Free Space Path Loss Free Space Path Loss Calculate signal attenuation over distance using the Friis transmission equation
Radio Propagation Radio Propagation Fundamentals Analyze wireless signal behavior, multipath effects, and coverage planning
MAC Protocols MAC Layer Protocols Compare CSMA/CA, TDMA, and ALOHA collision-avoidance strategies that directly affect throughput
Network Performance Lab Network Performance Lab Measure and differentiate bandwidth, throughput, and goodput in live network experiments
Collision Domains Collision Domain Design Design network segments to minimize contention and maximize effective bandwidth utilization
Birthday Paradox in Networks Birthday Paradox and Collision Probability Apply the birthday paradox to predict collision rates as device density increases