By the end of this chapter, you will be able to:
Before diving into this chapter, you should be familiar with:
Meet the Sensor Squad!
Temperature Terry, Light Lucy, Motion Marley, Pressure Pete, and their best friend Signal Sam are a team of tiny sensors living in a smart house. But they have a problem – how do they send their important messages to the Big Computer in the cloud?
Simple Story:
One day, Temperature Terry measured that the kitchen was getting dangerously hot! “I need to tell someone before the cookies burn!” Terry said. But Terry couldn’t just shout – computers don’t have ears! Instead, Terry wrote a tiny digital letter with his message: “Kitchen is 85°C (185°F) – TOO HOT!”
But wait – how does the letter know where to go? That’s where addresses come in! Just like your house has a street address so the mail carrier knows where to deliver letters, every device has a special number called an IP address. Terry’s address might be “192.168.1.25” – kind of like “25 Sensor Street, Kitchen District!”
Signal Sam helped Terry send the letter through the house’s Wi-Fi network. The letter hopped from Terry to the Wi-Fi router (like a local post office), then zoomed through the internet (like a mail truck on the highway), until it reached the Big Computer in the cloud. The cloud sent back a message to the smart oven: “Turn off!” The cookies were saved!
Fun Facts:
Try This at Home:
Ask a grown-up to help you find your home Wi-Fi router. Count how many devices are connected to it - your tablet, phones, smart TV, maybe even a smart speaker! Each one has its own special address. You can see them by looking at the “connected devices” list in the router’s app. That’s your very own home network!
The Communication Networks part of the module is organised to move from general networking ideas to technology families and then to IoT-specific protocols:
If you ever feel lost in a later networking chapter, you can return to this page to refresh the big picture before diving back into the details.
Protocol Deep Dives:
Learning Hubs:
Analogy: Networking is like a postal system for digital messages. Just like mail needs an address, a route, and a delivery method, digital data needs IP addresses, routing, and protocols to get from your sensor to the cloud.
In everyday terms:
Think of sending a package – each layer has ONE job and doesn’t worry about others:
This variant shows the same protocol layers but visualizes what happens to your data as it travels down and up the stack. Each layer wraps (encapsulates) data with its own header.
Key Insight: Your 16-byte temperature reading becomes a ~100+ byte transmission after all headers are added. This overhead is why IoT protocols like CoAP minimize header sizes!
IPv4 vs IPv6 Addressing:
| Aspect | IPv4 | IPv6 |
|---|---|---|
| Example | 192.168.1.100 | 2001:0db8:85a3::8a2e:0370:7334 |
| Structure | Network.Subnet.Subnet.Device | Much longer address space |
| Parts | 4 octets (32 bits) | 8 groups of 4 hex digits (128 bits) |
| Address Space | 4.3 billion addresses | 340 undecillion addresses |
| Analogy | Country.City.Street.House | Planet.Country.City.Street.Apt.Room |
| IoT Suitability | Running out (needs NAT) | Enough for every IoT device! |
| Network Type | Range | Speed | Power | Example Use |
|---|---|---|---|---|
| Wi-Fi | ~50m | Fast (Mbps) | High | Smart TV, cameras |
| Bluetooth | ~10m | Medium | Low | Wearables, speakers |
| Zigbee | ~100m | Slow | Very Low | Smart lights, sensors |
| LoRaWAN | ~15km | Very Slow | Ultra Low | Agriculture, cities |
| Ethernet | ~100m | Very Fast | N/A (wired) | Industrial, servers |
Your Smart Thermostat Sending Data:
Before continuing, make sure you understand:
Enhance your learning with resources across the module’s learning hubs:
Knowledge Map: Explore networking concepts visualization to see how addressing, protocols, and topologies interconnect
Quizzes: Test your understanding with Networking Fundamentals Quiz Bank covering OSI layers, IP addressing, and protocol selection
Simulations: Try hands-on tools in the Simulation Hub:
Video Learning: Watch IoT Networking video series for visual explanations of packet routing, NAT, and gateway operations
Knowledge Gaps: Identify common misconceptions in Networking Troubleshooting - discover why “more bandwidth always means better performance” is false for IoT
These integrated resources provide multiple learning pathways - visual, hands-on, and self-assessment - to reinforce the networking fundamentals covered in this chapter.
As IoT deployments scale to thousands or millions of devices, the choice between IPv4 and IPv6 becomes critical. This framework helps you evaluate which addressing scheme fits your project.
| Criterion | IPv4 (with NAT) | IPv6 (Native) |
|---|---|---|
| Address Space | 4.3 billion addresses (exhausted) | 340 undecillion (effectively unlimited) |
| Device Scalability | Limited by NAT table size (~64,000 per router) | No limit (every device gets unique address) |
| End-to-End Connectivity | Requires NAT traversal (complex) | Direct peer-to-peer (simple) |
| Header Overhead | 20 bytes (min) | 40 bytes (larger BUT simpler processing) |
| Security | IPsec optional | IPsec mandatory (built-in encryption) |
| Router Processing | NAT adds latency (1-5ms software NAT) | Stateless routing (faster) |
| Current Adoption | Universal (100% compatibility) | 35-40% internet, 80%+ cellular IoT |
| Mobile IoT Support | Requires carrier NAT (CGNAT) issues | Native support in LTE-M/NB-IoT |
| Device Provisioning | DHCP complexity, port forwarding config | SLAAC auto-configuration |
| Implementation Complexity | High (NAT configuration, port forwarding, UPnP) | Low (plug-and-play addressing) |
Decision Tree:
Q1: How many devices will you deploy?
Q2: Do devices need to be directly addressable from the internet?
Q3: Are you using cellular IoT connectivity (NB-IoT, LTE-M)?
Q4: Do you need built-in IPsec encryption?
Real-World Examples:
Example 1: Smart Home (30 devices, Wi-Fi, behind single router)
Example 2: Smart Agriculture (10,000 soil sensors, cellular NB-IoT)
Example 3: Industrial IoT (500 machines, factory Ethernet, isolated network)
Example 4: Smart City (1,000,000 streetlights, parking sensors, cameras)
IPv4 NAT Limitations at Scale:
NAT Port Exhaustion Example:
For 100,000 device deployment: - IPv4 approach: Need 100,000 ÷ 12,902 = 8 public IPs with complex load balancing - IPv6 approach: Single /64 subnet provides 18 quintillion addresses (1 per device, no multiplexing)
Transition Strategies (Dual-Stack):
For mixed deployments, run both protocols:
Configuration Example (ESP32):
// Support both IPv4 and IPv6
WiFi.begin(ssid, password);
// Wait for both addresses
while (!WiFi.isConnected()) {
delay(500);
}
IPAddress ipv4 = WiFi.localIP();
IPv6Address ipv6 = WiFi.localIPv6();
Serial.print("IPv4: ");
Serial.println(ipv4);
Serial.print("IPv6: ");
Serial.println(ipv6);Cost Comparison:
IPv4 with NAT (1,000 devices):
IPv6 Native (1,000 devices):
Key Insight: IPv6 is not just “more addresses” – it fundamentally simplifies IoT networking at scale by eliminating NAT, enabling peer-to-peer connectivity, and reducing configuration overhead. For deployments >1,000 devices or using cellular IoT, IPv6 is not optional – it’s required.
The Myth: Many beginners assume Wi-Fi is the best choice for all IoT devices because it’s fast, widely available, and familiar from smartphones and laptops.
The Reality: Wi-Fi is often the worst choice for battery-powered IoT sensors due to power consumption.
Quantified Impact:
Real-World Example: A temperature sensor sending readings every 5 minutes:
Why This Matters: Wi-Fi’s “always listening” architecture drains batteries fast. For 10,000 agricultural sensors across 100 acres, choosing Wi-Fi over LoRaWAN means replacing batteries 15x more often – costing $150,000/year extra in maintenance.
When Wi-Fi Makes Sense: Mains-powered devices (cameras, smart speakers), high-bandwidth needs (video), existing Wi-Fi infrastructure, low-latency requirements (<50ms).
The Right Approach: Match protocol to power budget, not familiarity. Battery-powered = Bluetooth LE, Zigbee, or LoRaWAN. Mains-powered = Wi-Fi or Ethernet.
IoT devices are only as useful as their ability to share data. A temperature sensor that cannot transmit readings, a motion detector that cannot trigger alerts, or an actuator that cannot receive commands – all become expensive paperweights. Networking is the connective tissue that turns individual sensors into a coordinated system. Two technical choices drive most IoT networking decisions: IP addressing (how devices are identified and routed to) and protocol selection (how data is packaged and delivered). The calculations below show just how much scale matters for the first choice.
IPv6 Address Space Calculation
The IPv4 vs IPv6 table above showed that IPv6 has “340 undecillion” addresses. Here is the exact derivation, so you can see why that number is so consequential for IoT at scale:
\[\text{IPv4 addresses} = 2^{32} = 4{,}294{,}967{,}296 \approx 4.3 \text{ billion}\]
\[\text{IPv6 addresses} = 2^{128} = 340{,}282{,}366{,}920{,}938{,}463{,}463{,}374{,}607{,}431{,}768{,}211{,}456\]
The ratio tells the story:
\[\frac{\text{IPv6}}{\text{IPv4}} = \frac{2^{128}}{2^{32}} = 2^{96} = 7.9 \times 10^{28}\]
That’s 79 octillion times larger. To visualize: if every grain of sand on Earth (≈7.5×10^18) had an IPv4 internet, IPv6 could give each grain 10 billion such internets.
For IoT scale: with 75 billion projected devices by 2030, IPv6 allocates:
\[\frac{2^{128}}{75 \times 10^9} \approx 4.5 \times 10^{27} \text{ addresses per device}\]
This explains why IPv6 enables every IoT sensor to have a globally routable address without NAT, fundamentally changing IoT network architecture from the NAT-dependent IPv4 model.
A 100 Mbps Ethernet link may only deliver 60–70 Mbps throughput due to protocol overhead, retransmissions, and half-duplex contention. Fix: always use measured throughput rather than link speed for capacity planning.
Latency has four components: propagation (distance/speed of light), transmission (packet size/bandwidth), queuing (buffer wait time), and processing (router/switch forwarding delay). Fix: identify which component dominates latency in your deployment and optimise accordingly.
Wireless IoT networks experience packet loss from RF interference, multipath fading, and hidden nodes — not congestion. Applying TCP-style congestion control to wireless packet loss causes unnecessary throughput reduction. Fix: diagnose the cause of packet loss before applying a remedy.
Now that you have explained core networking concepts, differentiated OSI from TCP/IP, and applied IPv4/IPv6 addressing, the chapters below build directly on these foundations:
| Topic | Chapter | Description |
|---|---|---|
| Protocols and MAC | Networking Basics: Protocols and MAC | Common IoT protocols classified by OSI layer and Medium Access Control strategies for shared wireless channels |
| Hands-On Configuration | Networking Basics: Hands-On Configuration | Practical network configuration, subnetting, security hardening, and systematic troubleshooting workflows |
| Labs and Practice | Networking Basics: Labs and Practice | Interactive Python implementations, Wokwi ESP32 networking simulations, and cumulative knowledge checks |
| Layered Models Deep Dive | Layered Models Fundamentals | Detailed walkthrough of every OSI layer with IoT-specific protocol examples at each level |
| IoT Protocol Landscape | IoT Protocols: Fundamentals | Cross-layer view of MQTT, CoAP, AMQP, and HTTP/2 showing how application protocols map to the transport stack |
| Wireless Technology Families | Mobile Wireless Technologies Basics | Comparative analysis of Wi-Fi, Bluetooth, Zigbee, LoRaWAN, and cellular IoT with protocol selection criteria |