616  Networking Knowledge Checks

616.1 Learning Objectives

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

  • Test your understanding of core networking concepts
  • Apply networking knowledge to real-world IoT scenarios
  • Identify common misconceptions in protocol selection and network design

616.2 Videos

NoteNetworking Fundamentals (Part 1)
Networking Fundamentals (Part 1)
From Lesson 4 β€” core concepts used throughout IoT networking.
NoteNetworking Fundamentals (Part 2)
Networking Fundamentals (Part 2)
From Lesson 4 β€” building blocks for layered models and protocols.

616.3 Knowledge Check

Test your understanding of fundamental concepts.

Question: You need to connect 500 battery-powered soil moisture sensors across a 10 kmΒ² farm. Each sensor sends tiny updates every 15 minutes, and there’s limited infrastructure. Which wireless option best fits?

πŸ’‘ Explanation: C. LoRaWAN targets long range + low data rate + low power, which matches sparse, battery-operated farm sensing.

Question: The IPv6 prefix fe80::/10 refers to which address type?

πŸ’‘ Explanation: B. Link-local addresses are for on-link communication and are not routed across L3 boundaries.

Question: Why can’t sensors using only fe80::/10 addresses reliably communicate across different floors/VLANs in a building?

πŸ’‘ Explanation: B. fe80::/10 traffic is scoped to a single link; each floor/VLAN is typically a different link.

Question: Under overload at a gateway, which transport provides built-in flow control that can slow senders instead of silently dropping packets?

πŸ’‘ Explanation: B. TCP’s sliding window/backpressure throttles senders when receivers can’t keep up; UDP has no equivalent mechanism.

616.4 Understanding Check: IoT Protocol Selection

Scenario: You’re designing a network for a 10 kmΒ² farm with 500 soil moisture sensors. Each sensor sends 50 bytes every 15 minutes. The farm has no cellular coverage, limited power infrastructure, and sensors must run on batteries for multiple years.

Think about: 1. What are the critical network requirements? (Range: 2-15 km per gateway, Data rate: ~50 bytes/15 min = ultra-low bandwidth, Power: multi-year battery life) 2. Which wireless technologies can achieve 10 kmΒ² coverage without extensive infrastructure? (Wi-Fi: 50-100m, BLE: 10-50m, LoRa: 2-15 km) 3. How does transmission power affect battery life? (Wi-Fi: 150-300 mA TX = weeks, BLE: 15-30 mA = months, LoRa: 30-40 mA but 50ms TX time = years)

Key Insight: LoRaWAN is specifically designed for wide-area, low-power sensor networks. It uses LoRa at the physical layer (long-range CSS modulation) and LoRaWAN for MAC/network management (Class A/B/C behavior, join + security, ADR, and network routing via gateways to a network server). Application data is typically a compact binary payload that the network server exposes to applications via integrations (often MQTT/HTTP). With a small number of gateways (often 1–3 depending on terrain), a 10 kmΒ² farm can be covered while supporting multi-year battery life (depending on message rate, payload size, and battery capacity).

Verify Your Understanding: - Why would Wi-Fi require 100+ access points for this deployment? (50-100m range per AP) - How does LoRa achieve years of battery life despite using 30-40 mA transmit current? (50-100ms TX time vs seconds for Wi-Fi, plus deep sleep between transmissions) - What’s the protocol overhead difference between HTTP and CoAP for 50-byte payloads? (HTTP: ~500 bytes total, CoAP: ~54 bytes total)

Scenario: A 5-floor smart building has 2,000 IoT sensors. The network engineer discovers all sensors are using IPv6 addresses starting with fe80:: (like fe80::1, fe80::2). Sensors on Floor 3 cannot communicate with sensors on Floor 5, and no sensor can reach the cloud server at 2001:db8:5555::1.

Think about: 1. What type of IPv6 address is fe80::/10? (Link-local - auto-configured, non-routable) 2. Why can Floor 3 sensors communicate with each other but not Floor 5? (Same L2 segment vs different L2 segments) 3. What happens when a router receives a packet destined for fe80:: addresses? (Router drops it - these addresses never leave local segment)

Key Insight: Link-local addresses (fe80::/10) are designed for auto-configuration and local communication only - they NEVER get routed beyond the Layer 2 network segment. Each floor is typically a separate L2 segment, so building-wide monitoring is impossible with link-local addresses. Sensors need either Global Unicast addresses (2000::/3 from ISP, like 2001:db8:1234:1::42) for internet routing, or Unique Local addresses (fd00::/8, like fd12:3456:789a:1::42) for private network routing within the building.

Verify Your Understanding: - How would you fix this addressing problem? (Assign global unicast or unique local addresses to sensors) - Can 6LoWPAN compression help with IPv6 address length concerns? (Yes - reduces 40-byte header to 2-4 bytes) - What’s the difference between ::1 suffix in fe80::1 vs ::1 alone? (fe80::1 is valid link-local; ::1 alone is loopback)

πŸ’‘ Explanation: Option B is correct - Link-local addresses cannot be routed:

IPv6 Address Types Explained:

Prefix Type Routable? Use Case
fe80::/10 Link-local ❌ NO Auto-config, local only
fc00::/7 Unique Local ❌ NO Private networks
2000::/3 Global Unicast βœ“ YES Internet-routable
ff00::/8 Multicast Depends One-to-many
::1/128 Loopback ❌ NO Host-only

Important: fe80:: addresses NEVER leave the local L2 segment!

Why This Is Critical for Buildings:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '12px'}}}%%
graph TB
    Cloud["☁️ Cloud Server<br/>2001:db8:5555::1<br/>(Global Unicast)"]

    subgraph Floor5["Floor 5 - Own L2 Segment"]
        S5a["Sensor A<br/>fe80::1<br/>(Link-Local)"]
        S5b["Sensor B<br/>fe80::2"]
    end

    subgraph Floor4["Floor 4 - Own L2 Segment"]
        S4a["Sensor A<br/>fe80::1<br/>(Link-Local)"]
        S4b["Sensor B<br/>fe80::2"]
    end

    subgraph Floor3["Floor 3 - Own L2 Segment"]
        S3a["Sensor A<br/>fe80::1<br/>(Link-Local)"]
        S3b["Sensor B<br/>fe80::2"]
    end

    S5a -.->|"❌ Cannot route<br/>(different L2)"| S4a
    S4a -.->|"❌ Cannot route<br/>(different L2)"| S3a
    S3a -.->|❌ Cannot reach| Cloud
    S5a -.->|❌ Cannot reach| Cloud

    S3a -->|"βœ“ Local only<br/>(same L2)"| S3b
    S4a -->|βœ“ Local only| S4b
    S5a -->|βœ“ Local only| S5b

    style S5a fill:#E74C3C,stroke:#C0392B,color:#fff
    style S4a fill:#E74C3C,stroke:#C0392B,color:#fff
    style S3a fill:#E74C3C,stroke:#C0392B,color:#fff
    style S5b fill:#2C3E50,stroke:#16A085,color:#fff
    style S4b fill:#2C3E50,stroke:#16A085,color:#fff
    style S3b fill:#2C3E50,stroke:#16A085,color:#fff
    style Cloud fill:#16A085,stroke:#2C3E50,color:#fff

Figure 616.1: Link-local IPv6 addresses cannot route across floors or reach cloud server

{fig-alt=β€œDiagram showing link-local IPv6 addressing problem in multi-floor building where sensors using fe80:: addresses cannot communicate across different L2 network segments or reach cloud server requiring global unicast addresses”}

Problem: - Sensors can communicate within floor (same L2 segment) - Sensors CANNOT reach other floors (different segments) - Sensors CANNOT reach cloud (requires global address) - Building-wide monitoring is IMPOSSIBLE

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '13px'}}}%%
graph TB
    Cloud["☁️ Cloud Server<br/>2001:db8:5555::1"]

    subgraph Floor5["Floor 5 (fe80::/64)"]
        S5a["Sensor A<br/>fe80::1"]
        S5b["Sensor B<br/>fe80::2"]
    end

    subgraph Floor4["Floor 4 (fe80::/64)"]
        S4a["Sensor A<br/>fe80::1"]
        S4b["Sensor B<br/>fe80::2"]
    end

    subgraph Floor3["Floor 3 (fe80::/64)"]
        S3a["Sensor A<br/>fe80::1"]
        S3b["Sensor B<br/>fe80::2"]
    end

    S5a -.->|❌ Cannot route| S4a
    S4a -.->|❌ Cannot route| S3a
    S3a -.->|❌ Cannot reach| Cloud
    S5a -.->|❌ Cannot reach| Cloud

    S3a -->|βœ“ Local only| S3b
    S4a -->|βœ“ Local only| S4b
    S5a -->|βœ“ Local only| S5b

    style S5a fill:#E74C3C,stroke:#C0392B,color:#fff
    style S4a fill:#E74C3C,stroke:#C0392B,color:#fff
    style S3a fill:#E74C3C,stroke:#C0392B,color:#fff
    style S5b fill:#2C3E50,stroke:#16A085,color:#fff
    style S4b fill:#2C3E50,stroke:#16A085,color:#fff
    style S3b fill:#2C3E50,stroke:#16A085,color:#fff
    style Cloud fill:#16A085,stroke:#2C3E50,color:#fff

Figure 616.2: Multi-floor building showing link-local scope limitation for cross-floor routing

Correct Addressing for IoT:

Option 1: Global Unicast (Internet-routable)
- Obtain IPv6 prefix from ISP
- Example: 2001:db8:1234::/48 allocated to building
- Floor 1: 2001:db8:1234:1::/64
- Floor 2: 2001:db8:1234:2::/64
- Sensor: 2001:db8:1234:1::42 (globally reachable)

Option 2: Unique Local (Private network)
- Use fd00::/8 prefix (randomly generated)
- Example: fd12:3456:789a::/48 for building
- Routable within building, NAT64 for internet
- Sensor: fd12:3456:789a:1::42

Why Other Options Are Wrong:

A - Address length: - IPv6 addresses are 128 bits, but this is handled by 6LoWPAN compression - Header compression reduces IPv6 overhead from 40 bytes to 2-4 bytes - Address length is NOT the issue

C - ::1 loopback: - ::1 is loopback only when the ENTIRE address is ::1 - fe80::1 is a valid link-local address (just happens to end in 1) - NOT the same as loopback

D - Multicast prefix: - ff00::/8 is multicast, not fe80::/10 - fe80:: is definitely unicast (link-local) - Incorrect prefix identification

Scenario: An industrial gateway receives sensor data via CoAP (UDP) and forwards to cloud via MQTT (TCP). Under peak load (100 sensors Γ— 10 msg/sec = 1000 msg/sec), the gateway drops 15% of incoming CoAP messages, but MQTT delivery to cloud stays at 100%.

Think about: 1. What happens when UDP packets arrive faster than the gateway can process them? (Buffer fills up β†’ packets dropped, no feedback to sender) 2. How does TCP handle the same situation? (Receive window shrinks β†’ sender slows down automatically, zero packet loss) 3. Why doesn’t the gateway drop MQTT packets? (TCP flow control: gateway tells cloud β€œslow down” via window size)

Key Insight: UDP is connectionless with no flow control mechanism. When the gateway’s 64 KB receive buffer fills (holds ~640 100-byte messages), new UDP packets are silently dropped with no notification to senders. TCP, however, uses sliding window flow control - when buffer fills, TCP advertises smaller window size, cloud automatically slows transmission, gateway processes backlog, then window increases again. Result: TCP achieves 100% delivery (just slower), while UDP experiences 15%+ packet loss under same load.

Verify Your Understanding: - If processing takes 2ms per message and gateway receives 1000 msg/sec, when does buffer overflow occur? (After 1.28 seconds: 640-message buffer fills) - Does CoAP have more or less overhead than MQTT? (Less: CoAP 4 bytes + UDP 8 bytes vs MQTT 2-14 bytes + TCP 20+ bytes) - How could you prevent UDP packet loss? (Rate limiting at sensors, larger buffer, application-layer flow control, or switch to TCP)

πŸ’‘ Explanation: Option A is correct - UDP lacks flow control:

TCP vs UDP Flow Control:

TCP (MQTT to Cloud):
─────────────────────────────────────────────────
1. Sender transmits data
2. Receiver acknowledges
3. If receiver buffer full β†’ ACK delayed
4. Sender detects delay β†’ slows down
5. Congestion window adapts to network conditions
6. Result: 100% delivery (throttled, but complete)

UDP (CoAP from Sensors):
─────────────────────────────────────────────────
1. Sender transmits data
2. No acknowledgment expected
3. If receiver buffer full β†’ PACKET DROPPED
4. Sender doesn't know packet was lost
5. No automatic retransmission
6. Result: 15% packet loss under load

Gateway Buffer Dynamics:

Peak Load Scenario:
- 100 sensors sending 10 CoAP messages/second = 1000 msg/s
- Gateway receive buffer: 64 KB
- Average CoAP message: 100 bytes
- Buffer capacity: ~640 messages

If processing takes 2ms per message:
- Gateway can process: 500 msg/s
- Incoming: 1000 msg/s
- Backlog: 500 msg/s Γ— t

After 1.28 seconds:
- Buffer full (640 messages accumulated)
- New messages DROPPED (no flow control)
- 50% loss rate until load decreases

Why MQTT (TCP) Doesn’t Drop:

TCP Flow Control Mechanism:
1. Gateway receive buffer fills up
2. TCP window size reduces (advertises smaller window)
3. Cloud sender slows transmission
4. Gateway processes backlog
5. Window size increases, sender speeds up
6. Self-regulating system, no drops

Even at 100% buffer utilization:
- TCP: 0% packet loss (just slower)
- UDP: 15%+ packet loss

Why Other Options Are Wrong:

B - CoAP overhead: - CoAP has LESS overhead than MQTT (4 bytes vs 2-14 bytes minimum) - UDP header: 8 bytes vs TCP header: 20+ bytes - Processing overhead is LOWER for CoAP, not higher

C - TCP packet size: - Larger packets = MORE processing per packet - TCP packets are often larger due to header overhead - This would slow TCP, not speed it up

D - MQTT QoS prioritization: - QoS levels don’t affect gateway processing priority - QoS is about delivery guarantees, not traffic prioritization - Gateway processes all incoming traffic equally

Scenario: A smart home has both Zigbee sensors and Wi-Fi devices operating at 2.4 GHz. When streaming 4K video over Wi-Fi, Zigbee temperature sensors stop responding. Wi-Fi is configured to channel 6 (2437 MHz, 22 MHz wide), and Zigbee is using channel 16 (2430 MHz, 2 MHz wide).

Think about: 1. Do Wi-Fi channel 6 and Zigbee channel 16 overlap in frequency? (Yes! Wi-Fi Ch 6 spans 2426-2448 MHz, Zigbee Ch 16 is 2430 MHz - direct interference) 2. How much stronger is Wi-Fi compared to Zigbee? (Wi-Fi: 100-500 mW, Zigbee: 1-20 mW = 10-25Γ— power difference) 3. Which Wi-Fi channels don’t overlap with which Zigbee channels? (Wi-Fi Ch 1 β†’ Zigbee Ch 15,20,25,26; Wi-Fi Ch 11 β†’ Zigbee Ch 11-14,25,26)

Key Insight: Wi-Fi channels are 22 MHz wide while Zigbee channels are only 2 MHz wide. Wi-Fi channel 6 (2426-2448 MHz) directly overlaps Zigbee channels 13-19, causing the high-power Wi-Fi video stream to drown out low-power Zigbee sensors. The solution is channel separation: configure Wi-Fi to channel 1 or 11, then use Zigbee channels that don’t overlap (e.g., Wi-Fi Ch 1 + Zigbee Ch 25). This provides interference-free coexistence in the same 2.4 GHz band.

Verify Your Understanding: - Why can’t you upgrade Zigbee to 5 GHz? (Zigbee standard only supports 2.4 GHz and sub-GHz 868/915 MHz) - Would increasing Zigbee power help? (No - Wi-Fi is still 10-25Γ— stronger, and you’d violate regulatory limits) - Could you coordinate Zigbee and Wi-Fi transmissions? (No coordination protocol exists between these independent standards)

πŸ’‘ Explanation: Option D is correct - Channel separation eliminates interference:

2.4 GHz Band Overlap:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3'}}}%%
gantt
    title 2.4 GHz Spectrum: Wi-Fi vs Zigbee Channel Overlap
    dateFormat X
    axisFormat %s MHz

    section Wi-Fi (22 MHz wide)
    Ch 1 (2412)    :active, w1, 0, 22
    Ch 6 (2437)    :active, w6, 25, 22
    Ch 11 (2462)   :active, w11, 50, 22

    section Zigbee (2 MHz wide)
    Ch 11-14       :done, z11, 0, 8
    Ch 15-16       :crit, z15, 10, 4
    Ch 17-19       :crit, z17, 16, 6
    Ch 20-22       :done, z20, 25, 6
    Ch 23-24       :crit, z23, 33, 4
    Ch 25-26       :done, z25, 50, 4

Figure 616.3: 2.4 GHz spectrum showing Wi-Fi and Zigbee channel overlap for interference planning

{fig-alt=β€œSpectrum diagram showing 2.4 GHz band with Wi-Fi channels 1, 6, 11 as 22 MHz wide blocks and Zigbee channels 11-26 as 2 MHz blocks, highlighting overlapping vs non-overlapping channel combinations for interference-free coexistence”}

Interference-free combinations: - Wi-Fi Ch 1 + Zigbee Ch 15, 20, 25, 26 βœ“ - Wi-Fi Ch 11 + Zigbee Ch 11-14, 25, 26 βœ“

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '12px'}}}%%
gantt
    title 2.4 GHz Spectrum: Wi-Fi vs Zigbee Channel Overlap
    dateFormat X
    axisFormat %s

    section Wi-Fi Channels
    Wi-Fi Ch 1 (2412 MHz)   :active, wifi1, 0, 22
    Wi-Fi Ch 6 (2437 MHz)   :active, wifi6, 25, 22
    Wi-Fi Ch 11 (2462 MHz)  :active, wifi11, 50, 22

    section Zigbee Channels
    Zigbee 11-14           :done, zb11, 0, 16
    Zigbee 15-16           :crit, zb15, 17, 6
    Zigbee 17-19           :crit, zb17, 24, 9
    Zigbee 20-22           :done, zb20, 34, 9
    Zigbee 23-24           :crit, zb23, 44, 6
    Zigbee 25-26           :done, zb25, 51, 6

Figure 616.4: Channel placement showing Wi-Fi and Zigbee non-overlapping configurations

Why This Works:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TB
    subgraph BEFORE["Before: Overlapping Channels"]
        direction LR
        W1["Wi-Fi Ch 6<br/>High power, 4K video"]
        Z1["Zigbee Ch 16<br/>INTERFERENCE!"]
        W1 -.->|"Overlap"| Z1
    end

    subgraph AFTER["After: Separated Channels"]
        direction LR
        W2["Wi-Fi Ch 1<br/>Lower spectrum"]
        GAP["Spectrum Gap<br/>(No overlap)"]
        Z2["Zigbee Ch 25<br/>Clean signal"]
        W2 -.-> GAP -.-> Z2
    end

    BEFORE -->|"Channel Planning"| AFTER

    style W1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style Z1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style W2 fill:#16A085,stroke:#2C3E50,color:#fff
    style GAP fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style Z2 fill:#16A085,stroke:#2C3E50,color:#fff

Figure 616.5

Why Other Options Are Wrong:

A - Zigbee 5 GHz: - Zigbee standard ONLY supports 2.4 GHz (and sub-GHz 868/915) - No 5 GHz Zigbee hardware exists - Protocol limitation, not device choice

B - Increase Zigbee power: - Zigbee max power: 1-20 mW - Wi-Fi typical power: 100-500 mW - Wi-Fi is 10-25Γ— stronger - Increasing Zigbee power won’t overcome Wi-Fi β€œshouting” - Also violates regulatory limits

C - Round-robin scheduling: - No coordination protocol exists between Wi-Fi and Zigbee - They’re independent standards from different organizations - Would require custom firmware on ALL devices - Not practical for consumer smart home

616.5 Summary

This chapter provides practice questions covering protocol selection, addressing schemes, IPv6, UDP vs TCP, and wireless coexistence. Use these to reinforce your understanding before moving to advanced topics.

616.6 What’s Next

Continue to the MAC Protocols chapter for a deep dive into advanced networking concepts including hidden terminals, congestion control, and QoS.