Understand TCP congestion control and its impact on IoT over lossy links
Explain IPv4 exhaustion and NAT challenges for IoT deployments
Compare MAC protocols (CSMA, TDMA, ALOHA) for different use cases
Identify and solve hidden and exposed terminal problems
Implement QoS for prioritizing critical IoT traffic
Handle MTU and fragmentation issues in constrained networks
618.2 Deep Dive: Advanced Networking Concepts for IoT
This section covers advanced networking topics for engineers implementing production IoT systems. Beginners can skip and return when deploying large-scale networks.
618.2.1 TCP Congestion Control and IoT Implications
TCPβs congestion control algorithms (originally designed for traditional networks) can cause problems in IoT environments.
How TCP Congestion Control Works:
TCP Congestion Window (CWND) states:
1. Slow Start: CWND doubles each RTT until threshold
- Start: 1 MSS (Maximum Segment Size β 1460 bytes)
- After 1 RTT: 2 MSS
- After 2 RTT: 4 MSS
- After 3 RTT: 8 MSS
- ...until ssthresh (slow start threshold) reached
2. Congestion Avoidance: CWND increases linearly
- +1 MSS per RTT
- Continue until packet loss detected
3. Fast Recovery: On packet loss
- Cut CWND in half
- Resume from there (not back to 1)
IoT Problem: Lossy wireless links trigger congestion control unnecessarily.
Example: LoRaWAN TCP connection
- Packet loss rate: 5% (normal for LoRa due to interference/collisions)
- TCP interprets ALL losses as congestion
- CWND repeatedly halved β Poor throughput
Measured performance:
- Wi-Fi (0.1% loss): 80 Mbps throughput (94% of capacity)
- LoRa (5% loss): 2 Kbps throughput (4% of 50 Kbps capacity!)
Solutions: 1. Use UDP for lossy links: CoAP (UDP-based) works better than HTTP (TCP) 2. Tune TCP parameters: Increase initial CWND, adjust retransmission timeout 3. Application-layer retries: Implement custom retry logic at MQTT/CoAP layer
Real Implementation:
# Linux TCP tuning for IoT gatewaysysctl-w net.ipv4.tcp_congestion_control=bbr # Use BBR instead of CUBICsysctl-w net.ipv4.tcp_slow_start_after_idle=0 # Don't reset CWND on idlesysctl-w net.ipv4.tcp_no_metrics_save=1 # Don't cache congestion metrics
Show code
{const container =document.getElementById('kc-net-9');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"An IoT gateway uses TCP to send sensor data over a LoRaWAN backhaul with 5% natural packet loss (due to RF interference, not congestion). The link has 50 Kbps capacity, but measured throughput is only 2 Kbps. What is causing this severe performance degradation?",options: [ {text:"The 5% packet loss requires 5% retransmission overhead",correct:false,feedback:"If only 5% retransmission were needed, throughput would be ~47.5 Kbps (95% of capacity). The 96% throughput loss indicates something far more severe than simple retransmission overhead."}, {text:"TCP congestion control interprets wireless loss as network congestion",correct:true,feedback:"Correct! TCP's congestion control was designed for wired networks where packet loss means congestion. On lossy wireless links, TCP repeatedly halves its congestion window (CWND) with each loss event, eventually throttling to a tiny fraction of capacity. Solution: use UDP-based protocols like CoAP, or tune TCP parameters."}, {text:"LoRaWAN has a 2 Kbps maximum data rate limitation",correct:false,feedback:"LoRaWAN can achieve 0.3-50 Kbps depending on spreading factor. The 50 Kbps capacity mentioned in the problem indicates a higher-speed configuration. The throughput limit is from TCP behavior, not LoRa physical limits."}, {text:"The gateway buffer is too small for TCP's sliding window",correct:false,feedback:"Buffer size affects maximum throughput but wouldn't cause 96% degradation. The specific pattern of wireless loss triggering TCP congestion control is the root cause of this dramatic throughput collapse."} ],difficulty:"hard",topic:"TCP Congestion" })); }}
618.2.2 IPv4 Address Exhaustion and NAT for IoT
The IPv4 Problem:
IPv4 address space: 2Β³Β² = 4,294,967,296 addresses (~4.3 billion)
Unusable addresses: ~590 million (private ranges, reserved, multicast)
Usable public IPv4: ~3.7 billion addresses
Current IoT devices (2024): ~16 billion
Projected (2030): ~30+ billion
Problem: NOT ENOUGH IPv4 addresses for every device!
Network Address Translation (NAT) - The Temporary Fix:
Canβt directly access smart camera from internet
Need port forwarding or VPN
Security risk if misconfigured
NAT traversal complexity:
Requires STUN/TURN servers for peer-to-peer
Adds latency (extra hops)
Some protocols donβt work through NAT (FTP, SIP without ALG)
Port exhaustion:
One public IP = 65535 ports
If 10000 IoT devices each maintain 10 connections:
10000 Γ 10 = 100,000 connections β EXCEEDS port limit!
Result: Connection failures, timeouts
IPv6: The Real Solution:
IPv6 address space: 2ΒΉΒ²βΈ β 3.4 Γ 10Β³βΈ addresses
That's: 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses
= 670,000,000,000,000,000,000,000,000 addresses per square millimeter of Earth!
Every IoT device can have multiple global unicast addresses - no NAT needed!
IPv6 Adoption in IoT (2024): - Cellular IoT (NB-IoT, LTE-M): 100% IPv6 support - Wi-Fi 6: Full IPv6 support - Zigbee, Thread: 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) - LoRaWAN: IPv6 via IPv6-over-LoRaWAN draft standard
Show code
{const container =document.getElementById('kc-net-10');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"A smart home has 25 IoT devices behind a NAT router with a single public IPv4 address (203.0.113.45). A user wants to access their security camera (192.168.1.50) from the internet. What is the PRIMARY challenge with this setup?",options: [ {text:"The camera's private IP address cannot be reached from the internet",correct:true,feedback:"Correct! NAT blocks inbound connections by default. The private address 192.168.1.50 is not routable on the internet - external devices only see 203.0.113.45. Solutions include port forwarding (maps external port to camera), UPnP (automatic port mapping), or cloud relay services (camera connects outbound to cloud, user accesses via cloud)."}, {text:"25 devices exceed the maximum supported by a single NAT router",correct:false,feedback:"A single NAT router can support thousands of devices (limited by port exhaustion at ~65,000 connections). 25 devices is well within normal capacity. The issue is inbound connectivity to a specific device, not the number of devices."}, {text:"IPv4 addresses are too short to uniquely identify 25 devices",correct:false,feedback:"The private address space (192.168.x.x) provides 65,536 addresses per /16 subnet, plenty for 25 devices. IPv4 length is not the issue - NAT's blocking of unsolicited inbound connections is the problem."}, {text:"The camera must have a MAC address registered with the ISP",correct:false,feedback:"ISPs don't require MAC address registration for devices behind NAT. The router's WAN interface MAC is what the ISP sees. The challenge is network address translation blocking inbound traffic, not MAC registration."} ],difficulty:"medium",topic:"NAT" })); }}
618.2.3 Link Layer Protocol Comparison: CSMA vs TDMA vs ALOHA
Different medium access control (MAC) protocols affect IoT network performance.
CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance): Used by: Wi-Fi, Zigbee, Bluetooth
Algorithm:
1. Listen to channel
2. If busy β wait random backoff time
3. If idle β transmit
4. If collision β exponential backoff and retry
Pros:
+ Fair access (all nodes get turns)
+ Efficient at low-medium loads
+ Simple, distributed (no coordinator needed)
Cons:
- Poor at high loads (too many collisions)
- Hidden node problem (can't hear all transmitters)
- Exposed node problem (unnecessary backoff)
Real performance (Wi-Fi):
- 1-10 devices: 70-90% channel utilization
- 50+ devices: 30-50% channel utilization (collisions dominate)
618.2.4 MAC Protocol Challenges: Hidden and Exposed Terminals
CSMA/CA works well in simple scenarios, but wireless networks face unique challenges that donβt exist in wired networks. Two fundamental problemsβhidden terminals and exposed terminalsβcan severely degrade network performance in IoT deployments.
618.2.4.1 The Hidden Terminal Problem
Definition: Two nodes cannot hear each otherβs transmissions but both can reach a common destination, causing undetected collisions at the receiver.
Why It Happens: - Wireless signals attenuate with distance - Physical obstacles (walls, furniture, machinery) block signals - Nodes outside each otherβs carrier sense range
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#ecf0f1', 'clusterBkg': '#ecf0f1', 'clusterBorder': '#2C3E50', 'edgeLabelBackground':'#ffffff'}}}%%
graph LR
A["Node A<br/>(Sensor)"]
B["Node B<br/>(Gateway)"]
C["Node C<br/>(Sensor)"]
A -->|"Can transmit to B"| B
C -->|"Can transmit to B"| B
A -.->|"β Cannot hear C<br/>(out of range)"| C
style A fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff
style B fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
style C fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff
Figure 618.2: Hidden terminal problem with nodes A and C both transmitting to gateway B unaware of each other
The Problem in Action:
Scenario: Smart factory with Wi-Fi sensors
Time 0ms: Node A senses channel β idle (can't hear C)
Node C senses channel β idle (can't hear A)
Time 1ms: Node A starts transmitting to Gateway B
Node C starts transmitting to Gateway B
Time 2ms: COLLISION at Gateway B!
- Gateway B receives garbled data from both A and C
- A and C think transmission succeeded (no collision detection)
- Both A and C cannot hear each other's carrier signal
Result: Both frames lost, but nodes don't know it
No retransmission until timeout (wasted time and energy)
Real-World IoT Impact:
Scenario
Hidden Terminal Effect
Performance Loss
Smart home (2-story house)
Upstairs sensors canβt hear downstairs β collisions at Wi-Fi AP
20-40% packet loss
Zigbee mesh (walls)
Nodes in different rooms β collisions at coordinator
15-30% throughput reduction
Industrial WSN (metal machinery)
Metal blocks RF β severe hidden terminals
40-60% retransmissions
Wi-Fi in dense deployment
50+ APs in building β overlapping coverage areas
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#ecf0f1'}}}%%
sequenceDiagram
participant A as Node A (Sender)
participant B as Gateway B (Receiver)
participant C as Node C (Hidden Terminal)
Note over A,C: Initial State: All nodes idle
A->>B: RTS (Request to Send)<br/>Duration: 100 bytes
Note over C: C hears RTS β sets NAV timer<br/>(Network Allocation Vector)
B->>A: CTS (Clear to Send)<br/>Duration: 100 bytes
B->>C: CTS (broadcast)
Note over C: C hears CTS β updates NAV timer
Note over C: C defers transmission<br/>for NAV duration
A->>B: DATA (actual frame)
Note over C: C still waiting (NAV active)
B->>A: ACK (acknowledgment)
Note over A,C: All nodes can now transmit
Step 1: Node A sends RTS (Request to Send) to Gateway B
- RTS includes: duration of upcoming transmission
- All nodes hearing RTS (even if they can't hear A) set NAV timer
Step 2: Gateway B responds with CTS (Clear to Send)
- CTS also includes transmission duration
- All nodes hearing CTS (including hidden Node C) set NAV timer
- Crucially: Node C hears CTS even if it couldn't hear RTS!
Step 3: Node A transmits DATA frame
- Hidden Node C stays silent (NAV timer active)
- No collision at Gateway B
Step 4: Gateway B sends ACK (acknowledgment)
- Transmission complete
- All NAV timers expire β nodes can compete for channel again
RTS/CTS Trade-offs:
Overhead Calculation (Wi-Fi example):
Without RTS/CTS:
- DATA frame: 1500 bytes
- ACK: 14 bytes
- Total airtime: ~120 ΞΌs (at 100 Mbps)
With RTS/CTS:
- RTS: 20 bytes β 1.6 ΞΌs
- CTS: 14 bytes β 1.1 ΞΌs
- DATA: 1500 bytes β 120 ΞΌs
- ACK: 14 bytes β 1.1 ΞΌs
- Total airtime: ~124 ΞΌs
Overhead: 4 ΞΌs / 124 ΞΌs = 3.2% (small!)
But if hidden terminals cause 30% collisions:
- Without RTS/CTS: 30% retransmissions β 156 ΞΌs average (collision + retry)
- With RTS/CTS: 3.2% overhead β 124 ΞΌs (no collisions)
RTS/CTS wins when collision rate > ~10%!
When to Enable RTS/CTS:
IoT Deployment
Enable RTS/CTS?
Reasoning
Small smart home (< 10 devices)
β No
Low collision risk, overhead not worth it
Large smart building (50+ Wi-Fi devices)
β Yes
Hidden terminals common, reduces collisions
Zigbee mesh (many walls)
β Yes
Physical obstacles create hidden terminals
Industrial IoT (metal machinery)
β Yes
Severe RF blocking β many hidden terminals
LoRaWAN
β N/A
Uses ALOHA, not CSMA (no RTS/CTS)
Bluetooth mesh
β Yes
Dense deployments with obstacles
618.2.4.2 The Exposed Terminal Problem
Definition: A node unnecessarily defers transmission when its transmission would not cause a collision, reducing channel efficiency.
Why It Happens: - Node overhears a transmission not directed at its intended receiver - CSMA/CA conservatively assumes all transmissions will collide - Spatial reuse is prevented
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#ecf0f1', 'clusterBkg': '#ecf0f1', 'clusterBorder': '#2C3E50', 'edgeLabelBackground':'#ffffff'}}}%%
graph LR
A["Node A<br/>(Receiver)"]
B["Node B<br/>(Sender)"]
C["Node C<br/>(Sender)"]
D["Node D<br/>(Receiver)"]
B -->|"Transmitting to A"| A
C -.->|"β Could transmit to D<br/>(no collision)"| D
C -->|"β Hears B β defers<br/>(unnecessary!)"| B
style A fill:#16A085,stroke:#2C3E50,stroke-width:3px,color:#fff
style B fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff
style C fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
style D fill:#16A085,stroke:#2C3E50,stroke-width:3px,color:#fff
Figure 618.4: Exposed terminal problem where node C unnecessarily defers though D is out of Bβs range
The Problem in Action:
Scenario: Zigbee smart lighting network
Configuration:
- Node B (light switch) transmitting to Node A (controller)
- Node C (motion sensor) wants to transmit to Node D (different controller)
- Node C can hear Node B, but Node D cannot
Time 0ms: Node B starts transmitting to Node A
Time 1ms: Node C senses channel β BUSY (hears B)
Node C defers transmission
Problem: Node C COULD transmit to Node D safely!
- Node D is far from Node B (won't hear B's transmission)
- C β D transmission wouldn't collide with B β A
- But CSMA/CA doesn't allow spatial reuse
Result: Channel is underutilized
Node C waits unnecessarily β increased latency
Real-World IoT Impact:
Scenario
Exposed Terminal Effect
Efficiency Loss
Linear sensor array
Sensors at opposite ends defer unnecessarily
30-50% channel underutilization
Multi-floor building Wi-Fi
Devices on different floors could transmit simultaneously
20-40% throughput loss
Factory floor WSN
Sensors in different zones defer to each other
25-35% latency increase
Parking lot sensors
Distant sensors wait for nearby transmissions
15-30% reduced spatial reuse
Why Exposed Terminals Matter Less Than Hidden Terminals:
Hidden Terminal: CAUSES COLLISIONS β data loss, retransmissions, wasted energy
Severity: HIGH (actual failures)
Exposed Terminal: REDUCES EFFICIENCY β channel underutilization, higher latency
Severity: MEDIUM (performance degradation, not failures)
Engineering Priority:
1. Solve hidden terminals first (RTS/CTS)
2. Accept some exposed terminal inefficiency as acceptable trade-off
3. Use directional antennas or TDMA for mission-critical deployments
618.2.4.3 MAC Protocol Comparison: Handling Hidden/Exposed Terminals
MAC Protocol
Hidden Terminal Solution
Exposed Terminal Solution
IoT Use Cases
CSMA/CA
β Poor (collisions common)
β Poor (spatial reuse limited)
Wi-Fi, Zigbee (add RTS/CTS for improvements)
CSMA/CA + RTS/CTS
β Good (handshake prevents collisions)
β Poor (still defers unnecessarily)
Dense Wi-Fi, industrial Zigbee
TDMA
β Excellent (no collisions, time slots)
β Excellent (spatial reuse via slot assignment)
Cellular IoT, mission-critical WSN
ALOHA
β Terrible (no carrier sensing at all!)
β Good (transmits anytime β spatial reuse)
LoRaWAN (works due to sparse traffic)
FDMA
β Excellent (different frequencies)
β Excellent (simultaneous transmission)
Cellular (frequency bands per user)
Show code
{const container =document.getElementById('kc-net-11');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"A Zigbee sensor network in a warehouse has nodes A, B, and C. Node A is transmitting to gateway G. Node C wants to send to G but cannot hear A (blocked by metal shelving). Node B can hear both A and C. What problem will occur and what is the solution?",options: [ {text:"Exposed terminal - B unnecessarily defers; solution is directional antennas",correct:false,feedback:"This describes a hidden terminal problem, not exposed terminal. In exposed terminal, a node defers when it could safely transmit. Here, C will transmit causing a collision because it cannot hear A - the opposite problem."}, {text:"Hidden terminal - C causes collision at G; solution is RTS/CTS handshake",correct:true,feedback:"Correct! Node C cannot hear A's transmission, so it thinks the channel is idle. When C transmits to G, both A and C signals collide at the gateway. RTS/CTS solves this: G broadcasts CTS which C CAN hear, telling it to defer. B's ability to hear both is irrelevant to this collision."}, {text:"Channel congestion - too many nodes; solution is add more gateways",correct:false,feedback:"With only 3 nodes, congestion is not the issue. The specific problem is that C cannot detect A's transmission due to physical obstruction, causing undetected collisions at the gateway."}, {text:"Frequency interference - metal causes reflection; solution is change to 5 GHz",correct:false,feedback:"Zigbee only operates at 2.4 GHz and sub-GHz bands, not 5 GHz. The metal shelving blocks signals creating a hidden terminal scenario, not frequency interference. RTS/CTS handshaking addresses this at the MAC layer."} ],difficulty:"hard",topic:"MAC Protocols" })); }}
Real-World Mitigation Strategies:
Strategy 1: Network Planning (Design Phase)
- Site survey to identify hidden terminal zones
- Strategic AP/gateway placement to minimize coverage holes
- Use 5 GHz Wi-Fi (better wall penetration than 2.4 GHz for hidden terminals)
Strategy 2: Protocol Configuration (Deployment Phase)
- Enable RTS/CTS for networks with > 20 devices or physical obstacles
- Adjust CSMA/CA backoff parameters (increase contention window)
- Use mesh routing to provide multiple paths (avoids single collision point)
Strategy 3: Advanced Techniques (Enterprise IoT)
- Beamforming (directional antennas reduce hidden terminals)
- MU-MIMO (Wi-Fi 6) - simultaneous transmission to multiple devices
- TDMA scheduling for deterministic traffic (industrial IoT)
- Frequency hopping (Bluetooth) - collision on one channel doesn't affect others
Case Study: Wi-Fi Smart Factory Deployment
Initial Deployment (no RTS/CTS):
- 80 Wi-Fi sensors across factory floor
- Metal machinery creates hidden terminals
- Measured performance:
* 45% packet loss during peak traffic
* 3-5 second latency for critical alerts
* 60% retransmission rate
After Enabling RTS/CTS + Network Redesign:
- RTS/CTS enabled on all APs
- Added 2 additional APs to reduce hidden terminal zones
- Mesh routing for redundancy
- Measured performance:
* 5% packet loss (acceptable)
* 200-500ms latency for alerts (excellent)
* 8% retransmission rate (normal)
Cost: $2000 for 2 additional APs
Benefit: $50,000/year in reduced downtime from missed alerts
TDMA (Time Division Multiple Access): Used by: Cellular (GSM, LTE), some industrial WSN
Algorithm:
1. Coordinator assigns time slots to nodes
2. Each node transmits only in its slot
3. No collisions possible
Example: 10ms frame, 10 nodes
Node 1: 0-1ms
Node 2: 1-2ms
...
Node 10: 9-10ms
Repeat every 10ms
Pros:
+ No collisions β predictable, high efficiency
+ Deterministic latency (max = frame duration)
+ Low power (sleep when not your slot)
Cons:
- Requires time synchronization (GPS, PTP)
- Coordinator needed (single point of failure)
- Wasted slots if node has no data
- Scalability issues (more nodes = longer frames)
Real performance (LTE):
- 50+ devices: 85-95% channel utilization (even with many devices)
ALOHA / Slotted ALOHA: Used by: LoRaWAN Class A, Sigfox
Pure ALOHA:
1. Transmit whenever you have data
2. If collision β wait random time, retry
3. No carrier sensing
Slotted ALOHA:
1. Time divided into slots
2. Transmit only at slot boundaries
3. Still no carrier sensing
Throughput comparison:
Pure ALOHA: Max 18% channel utilization (!)
Slotted ALOHA: Max 36% channel utilization
CSMA/CA: Max 70-90% channel utilization
TDMA: Max 85-95% channel utilization
Why use ALOHA for LoRaWAN?
+ Ultra-simple (no coordination, no synchronization)
+ Low power (no listening, just transmit)
+ Works for infrequent traffic (0.5% duty cycle)
+ Scales to 1000s of nodes (if traffic is sparse)
Choosing MAC Protocol for IoT:
Use Case
Traffic Pattern
Best MAC
Why
Smart meter (1 msg/hour)
Infrequent, periodic
ALOHA (LoRaWAN)
Simple, low power, scales well for sparse traffic
Industrial sensor (100 Hz)
Frequent, deterministic
TDMA
Predictable latency, no collisions, mission-critical
Smart home devices
Bursty, on-demand
CSMA (Wi-Fi, Zigbee)
Fair access, efficient for dynamic traffic
Real-time video
Continuous, high-rate
TDMA (LTE)
Guaranteed bandwidth, low latency
618.2.5 MTU, MSS, and Fragmentation in Constrained Networks
Maximum Transmission Unit (MTU): Maximum packet size a network can carry without fragmentation.
Common MTU sizes:
Ethernet: 1500 bytes (most wired LANs)
Wi-Fi: 1500 bytes (matches Ethernet for compatibility)
6LoWPAN: 127 bytes (IEEE 802.15.4 frame size)
LoRaWAN: 51-242 bytes (depends on spreading factor and region)
NB-IoT: 1358 bytes
PPPoE: 1492 bytes (Ethernet 1500 - 8 for PPP header)
Maximum Segment Size (MSS): Maximum TCP payload size (MTU - IP header - TCP header).
Scenario: HTTP request from 6LoWPAN sensor to cloud server
HTTP GET request size: 400 bytes
6LoWPAN MTU: 127 bytes
Required fragments: ceil(400 / 127) = 4 fragments
Fragment transmission:
- Fragment 1/4: 127 bytes
- Fragment 2/4: 127 bytes
- Fragment 3/4: 127 bytes
- Fragment 4/4: 19 bytes
If ANY fragment is lost β ENTIRE datagram lost!
Packet loss: 5% per fragment
Success probability: (0.95)β΄ = 81.5%
Effective loss rate: 18.5% (!)
Compare to no fragmentation (single 127-byte packet):
Packet loss: 5%
Much better!
Mitigation Strategies:
Path MTU Discovery: Discover smallest MTU along path
Send packets with DF (Don't Fragment) bit set
If too large β get ICMP "Fragmentation Needed" error
Reduce packet size and retry
Application-level chunking: Send multiple small requests
Instead of: 1Γ 400-byte HTTP request
Use: 4Γ 100-byte HTTP requests (each fits in one 6LoWPAN frame)
Protocol choice:
Avoid TCP for constrained networks (large headers, fragmentation)
Use CoAP (UDP-based, small headers, built-in chunking)
618.2.6 Quality of Service (QoS) for IoT Traffic Differentiation
Not all IoT data is equal - some requires priority handling.
DiffServ (Differentiated Services) Model:
IPv4/IPv6 packets have DSCP (Differentiated Services Code Point) field:
ESP32 example - marking CoAP packets for fire alarm:
// Set DSCP to EF (Expedited Forwarding) for fire alarmint dscp =0x2E<<2;// Shift left 2 bits for TOS fieldsetsockopt(sock, IPPROTO_IP, IP_TOS,&dscp,sizeof(dscp));// Regular temperature reading uses default (Best Effort)
Router Configuration (Cisco example):
! Define class for IoT alarm traffic
class-map match-any IOT_ALARMS
match dscp ef
! Define policy - guarantee 10% bandwidth, low latency queue
policy-map IOT_QOS
class IOT_ALARMS
priority percent 10
! Apply to WAN interface
interface GigabitEthernet0/0
service-policy output IOT_QOS
Measured Impact:
Without QoS (fire alarm competes with firmware download):
- Alarm latency: 5-50 seconds (unacceptable!)
- Jitter: Β±20 seconds
- Occasional drops during congestion
With QoS (EF class for alarms):
- Alarm latency: 50-200ms (excellent)
- Jitter: Β±10ms
- Zero drops even during congestion
Show code
{const container =document.getElementById('kc-net-12');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"An industrial IoT system has fire alarms, video cameras, and firmware updates sharing a 10 Mbps link. During a firmware update, a fire alarm takes 45 seconds to reach the monitoring station. After implementing QoS, alarm latency drops to 150ms. What QoS mechanism achieved this?",options: [ {text:"Increasing the link bandwidth to 100 Mbps",correct:false,feedback:"Adding bandwidth is not a QoS mechanism - it's infrastructure upgrade. QoS works within existing bandwidth constraints by prioritizing traffic. The 10 Mbps link can deliver alarms in milliseconds when priority queuing is properly configured."}, {text:"DSCP marking with Expedited Forwarding (EF) priority queue",correct:true,feedback:"Correct! DSCP EF (Expedited Forwarding, code 46/0x2E) places alarm packets in a strict priority queue. Even when firmware downloads consume bandwidth, alarm packets skip to the front of the queue. The router processes EF packets first, achieving sub-second delivery regardless of other traffic."}, {text:"Compressing the alarm packets to reduce transmission time",correct:false,feedback:"Alarm packets are already tiny (typically <100 bytes). Compression wouldn't help. The 45-second delay was caused by the alarm waiting in queue behind firmware data. Priority queuing (EF) solves this by letting alarms bypass the queue."}, {text:"Using UDP instead of TCP for alarm transmission",correct:false,feedback:"UDP vs TCP affects reliability and overhead, but wouldn't solve the queuing delay. Even UDP packets wait in network queues during congestion. QoS priority marking (DSCP EF) ensures alarms get processed first regardless of transport protocol."} ],difficulty:"medium",topic:"Quality of Service" })); }}
618.3 Summary
TCP congestion control interprets wireless packet loss as network congestion, causing severe throughput degradation on lossy IoT links
NAT allows IPv4 sharing but blocks inbound connections and creates complexity for peer-to-peer IoT
MAC protocols differ significantly: CSMA is fair but collision-prone; TDMA is deterministic but requires coordination; ALOHA is simple but low efficiency
Hidden terminals cause collisions that CSMA cannot detect - solve with RTS/CTS handshaking
QoS with DSCP marking ensures critical IoT traffic (alarms) gets priority over bulk transfers
Fragmentation increases effective loss rate - design for MTU constraints rather than fragmenting
618.4 Whatβs Next
Continue to the Labs chapter for hands-on network simulation exercises.