626  Networking Basics: Knowledge Check

626.1 Learning Objectives

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

  • Explain Network Models: Articulate the differences between OSI and TCP/IP models
  • Justify IPv6 Adoption: Explain why IPv6 is essential for IoT deployments
  • Select Transport Protocols: Choose between TCP and UDP based on application requirements
  • Distinguish Address Types: Differentiate between MAC addresses and IP addresses
  • Evaluate Topologies: Compare network topologies and select appropriate ones for IoT use cases
  • Interpret Signal Strength: Understand RSSI values and their implications for IoT devices
  • Apply Protocol Knowledge: Identify ports and protocols used in IoT systems
  • Troubleshoot Connectivity: Apply systematic troubleshooting methodology

626.2 Prerequisites

Before working through these knowledge checks, ensure you have completed:

626.3 Knowledge Check

Test your understanding of networking fundamentals with these questions. Each question includes a detailed answer with practical IoT context.

626.3.1 Question 1: OSI vs TCP/IP Models

What is the main difference between the OSI model and TCP/IP model?

OSI is a 7-layer theoretical framework; TCP/IP is a 4-layer practical implementation actually used on the internet.

OSI Model (7 layers):

  • Application, Presentation, Session, Transport, Network, Data Link, Physical
  • Created by ISO as a reference model
  • More granular separation of concerns

TCP/IP Model (4 layers):

  • Application, Transport, Internet, Link
  • Based on actual internet protocols
  • Combines OSI layers 5-7 into single Application layer
  • Combines OSI layers 1-2 into Link layer

For IoT:

  • TCP/IP is what you actually implement
  • OSI helps understand where different protocols fit
  • Many IoT protocols simplify further (e.g., BLE stack)

Example:

MQTT (Application) -> TCP (Transport) -> IP (Internet) -> Wi-Fi (Link)

626.3.2 Question 2: IPv6 for IoT

Why is IPv6 essential for IoT?

IPv6 provides enough addresses for billions of IoT devices, while IPv4 has run out.

IPv4 limitations:

  • Only 4.3 billion addresses (2^32 = 4,294,967,296)
  • Already exhausted globally
  • Requires NAT (Network Address Translation) which complicates direct device access

IPv6 advantages for IoT:

  • 340 undecillion addresses (2^128 = 3.4 x 10^38)
  • Every device gets unique global address
  • No NAT needed - simpler, more secure
  • Built-in IPsec security
  • Auto-configuration (SLAAC)
  • Header compression with 6LoWPAN for constrained devices

Example:

IPv4: 192.168.1.100 (behind NAT, not globally addressable)
IPv6: 2001:0db8:85a3::8a2e:0370:7334 (globally unique)

6LoWPAN adapts IPv6 for IEEE 802.15.4 networks (Zigbee, Thread), compressing 40-byte header to ~6 bytes.

626.3.3 Question 3: UDP vs TCP Selection

When should you use UDP instead of TCP for IoT?

Use UDP when low latency is more important than guaranteed delivery, especially for real-time sensor data where occasional loss is acceptable.

Use UDP for:

  • Periodic sensor readings (temperature every 10 seconds - if one packet is lost, next reading comes soon)
  • Real-time applications (voice, video streaming)
  • DNS queries (single request-response, retry if needed)
  • Multicast/broadcast (DHCP discover, mDNS)
  • Low-power devices (less overhead = longer battery life)

Use TCP for:

  • Firmware updates (every byte must arrive correctly)
  • Configuration changes (critical commands)
  • File transfers
  • When order matters (sequential commands)

Trade-offs:

TCP:
  + Guaranteed delivery
  + In-order packets
  - Higher overhead (20-byte header vs 8-byte UDP)
  - Connection setup latency (3-way handshake)
  - Retransmissions add delay

UDP:
  + Lower latency
  + Lower overhead
  + Simpler (no connection state)
  - Packets may be lost
  - May arrive out of order

IoT protocols handle this smartly:

  • MQTT can run over TCP (reliable) or UDP (fast)
  • CoAP uses UDP but adds application-level confirmations when needed

626.3.4 Question 4: MAC vs IP Addresses

What is the difference between a MAC address and an IP address?

MAC addresses identify hardware (Layer 2, local network); IP addresses identify location in network (Layer 3, can route across networks).

MAC Address (Media Access Control):

  • Layer 2 (Data Link)
  • 48 bits (6 bytes): AA:BB:CC:DD:EE:FF
  • Burned into hardware (NIC) by manufacturer
  • Local scope: Only matters on local network segment
  • First 3 bytes = OUI (vendor), last 3 bytes = unique ID
  • Cannot route across networks

IP Address:

  • Layer 3 (Network)
  • IPv4: 32 bits (192.168.1.100), IPv6: 128 bits
  • Assigned by network (DHCP or static)
  • Global scope: Can route across the internet
  • Changes when device moves networks
  • Can route packets across multiple networks

Analogy:

  • MAC = Your home address (fixed, identifies building)
  • IP = Your mailing address (changes if you move)

In practice:

ARP (Address Resolution Protocol) maps IP -> MAC
Example:
  "Who has IP 192.168.1.100?" -> "I do, my MAC is DC:A6:32:AB:CD:EF"

Why both?

  • Routers use IP addresses to forward between networks
  • Switches use MAC addresses to forward within a network
  • Each layer has different responsibilities

626.3.5 Question 5: Network Topology Selection

Which network topology is best for IoT and why?

It depends on the application, but mesh topology is often preferred for IoT due to self-healing and extended range.

Topology comparison:

Star Topology:

  • Pros: Simple, low latency
  • Pros: Easy to add devices
  • Cons: Hub is single point of failure
  • Cons: Range limited to hub
  • Best for: Wi-Fi home networks, cellular IoT

Mesh Topology:

  • Pros: Self-healing (reroutes around failures)
  • Pros: Extended range (multi-hop)
  • Pros: No single point of failure
  • Cons: Complex routing
  • Cons: Higher power (relay traffic)
  • Best for: Zigbee, Thread, Bluetooth Mesh, LoRa networks

Tree/Hierarchical:

  • Pros: Scalable
  • Pros: Efficient aggregation
  • Cons: Intermediate node failure affects subtree
  • Best for: Industrial IoT, building automation

Decision factors:

  1. Coverage area: Mesh for large areas
  2. Reliability: Mesh for critical applications
  3. Power: Star for battery devices (no relaying)
  4. Scalability: Tree for thousands of devices
  5. Cost: Star is cheapest (one gateway)

Example:

Smart Home: Star (Wi-Fi to router)
Smart Building: Mesh (Zigbee sensors throughout)
Industrial: Tree (hierarchical aggregators)

626.3.6 Question 6: Understanding RSSI

What does RSSI measure and what values are good?

RSSI (Received Signal Strength Indicator) measures Wi-Fi signal strength in dBm (decibel-milliwatts). Higher (less negative) is better.

RSSI Scale:

-30 dBm: Excellent (right next to access point)
-50 dBm: Very Good
-67 dBm: Good (typical home/office use)
-70 dBm: Fair (minimum for reliable connection)
-80 dBm: Poor (frequent disconnections)
-90 dBm: Unusable (no stable connection)

Why it matters for IoT:

  • Battery life: Weak signal -> device transmits at higher power -> drains battery faster
  • Data rate: Weak signal -> lower speeds
  • Reliability: Weak signal -> packet loss, retransmissions
  • Connection stability: Below -70 dBm, expect issues

dBm is logarithmic:

-30 dBm = 1 mW
-40 dBm = 0.1 mW (10x weaker)
-50 dBm = 0.01 mW (100x weaker)
Every 3 dB = 2x power difference

Improving RSSI:

  • Move closer to access point
  • Remove obstacles (walls, metal)
  • Use external antenna
  • Add Wi-Fi extenders/mesh
  • Switch to less congested channel

Check RSSI in code:

int rssi = WiFi.RSSI();
Serial.print("Signal: ");
Serial.print(rssi);
Serial.println(" dBm");

626.3.7 Question 7: IoT Protocol Ports

What ports do MQTT and CoAP use?

MQTT: 1883 (plain), 8883 (TLS) | CoAP: 5683 (plain), 5684 (DTLS)

MQTT (Message Queuing Telemetry Transport):

  • Port 1883: MQTT over TCP (unencrypted)
  • Port 8883: MQTT over TLS/SSL (encrypted)
  • Transport: TCP (reliable delivery)
  • Use: General IoT messaging, telemetry

CoAP (Constrained Application Protocol):

  • Port 5683: CoAP over UDP (unencrypted)
  • Port 5684: CoAP over DTLS (encrypted)
  • Transport: UDP (lightweight)
  • Use: Constrained devices, low-power sensors

Other important IoT ports:

80   - HTTP
443  - HTTPS
22   - SSH
23   - Telnet (avoid - insecure!)
502  - Modbus TCP
5353 - mDNS (local device discovery)

Security best practice:

  • Always use encrypted ports in production (8883 for MQTT, 5684 for CoAP)
  • Plain ports (1883, 5683) only for development/testing
  • Why: IoT devices are prime attack targets

Example configuration:

# Development (unencrypted)
client.connect("mqtt.example.com", 1883)

# Production (encrypted)
client.tls_set(ca_certs="ca.crt")
client.connect("mqtt.example.com", 8883)

626.3.8 Question 8: NAT and IoT Challenges

What is NAT and why is it problematic for IoT?

NAT (Network Address Translation) allows multiple devices to share one public IP, but makes direct device-to-device communication difficult.

How NAT works:

Home Network (Private IPs):
  - Sensor: 192.168.1.100
  - Camera: 192.168.1.101
  - Phone: 192.168.1.102
     |
  Router (NAT)
     |
Internet (One Public IP): 203.0.113.42

Why NAT exists:

  • IPv4 address exhaustion (only 4.3 billion addresses)
  • Allows billions of devices to share limited public IPs

Problems for IoT:

  1. No direct inbound connections:
    • Can’t directly access home camera from internet
    • Workarounds: Port forwarding, VPN, cloud relay
  2. Complicates peer-to-peer:
    • Devices in different homes can’t connect directly
    • Need STUN/TURN servers or cloud intermediary
  3. Breaks some protocols:
    • Protocols that embed IP addresses in payload
    • Some IoT protocols assume end-to-end connectivity
  4. Security vs. obscurity:
    • NAT provides some security (devices hidden behind router)
    • But it’s obscurity, not real security

Solutions:

IPv6: Every device gets global address, no NAT needed
Port Forwarding: Manually map external port to device
UPnP/NAT-PMP: Automatic port forwarding (security risk!)
Cloud Services: Devices connect out, cloud relays
VPN: Secure tunnel into home network

Example issue:

Can't do this:
  Phone (internet) -> Camera (192.168.1.101) X

Must do:
  Phone -> Cloud Server -> Camera
  or
  Phone -> VPN -> Home Network -> Camera

626.3.9 Question 9: Gateway vs Router

What is the difference between a gateway and a router?

A router connects networks at Layer 3 (IP); a gateway can translate between different protocols/technologies (often at higher layers).

Router:

  • Layer 3 (Network layer)
  • Forwards packets between networks using IP addresses
  • Makes routing decisions (which path to take)
  • All routers operate the same way (IP protocol)
  • Example: Home Wi-Fi router connecting LAN to internet

Gateway:

  • Multi-layer (can be Layer 7, Application)
  • Translates between different protocols/systems
  • Protocol conversion, data transformation
  • More intelligent than simple routing
  • Example: IoT gateway converting Zigbee to Wi-Fi, or MQTT to HTTP

In IoT context:

IoT Gateway:

Sensors (Zigbee, BLE) -> Gateway -> Cloud (MQTT, HTTP)

Functions:
  - Protocol translation (Zigbee <-> Wi-Fi)
  - Data aggregation (combine sensor readings)
  - Edge processing (filter, analyze locally)
  - Security (encrypt, authenticate)
  - Local storage (buffer when offline)

Router:

IoT Devices (Wi-Fi) -> Router -> Internet

Functions:
  - IP packet forwarding
  - NAT (private IPs <-> public IP)
  - DHCP (assign IP addresses)
  - Firewall

Key difference:

  • Router: Layer 3, same protocol both sides (IP)
  • Gateway: Higher layer, different protocols each side

Example:

Smart home hub (Zigbee/Z-Wave sensors -> Cloud API) = Gateway
Wi-Fi router (LAN -> WAN) = Router

Many IoT devices act as both - they route IP packets AND translate protocols.

626.3.10 Question 10: Wi-Fi Troubleshooting

How do you troubleshoot when an IoT device won’t connect to Wi-Fi?

Use systematic layer-by-layer troubleshooting, starting from Physical layer up to Application.

Troubleshooting Steps:

1. Physical Layer (Layer 1):

- Check power - is device on?
- Check RSSI - is signal strong enough? (>-70 dBm)
- Check distance - too far from access point?
- Check obstacles - metal, concrete blocking signal?
- Check antenna - connected properly?

2. Data Link Layer (Layer 2):

- Correct SSID? (case-sensitive)
- Correct password? (case-sensitive)
- Wi-Fi channel congestion? Try changing AP channel
- MAC filter enabled on router? Whitelist device
- 2.4 GHz vs 5 GHz? (ESP32 only supports 2.4 GHz)

3. Network Layer (Layer 3):

- Did device get IP address? (check DHCP)
- IP conflict? (another device has same IP)
- Correct subnet mask?
- Can ping gateway?

4. Transport/Application:

- Firewall blocking ports?
- DNS working? (can resolve google.com?)
- Internet reachable? (ping 8.8.8.8)

Diagnostic commands:

ESP32 Serial Monitor:

Serial.println(WiFi.status());  // Check connection status
Serial.println(WiFi.RSSI());    // Signal strength
Serial.println(WiFi.localIP()); // Got IP?
Serial.println(WiFi.gatewayIP()); // Gateway reachable?

Computer/Phone:

ping 8.8.8.8          # Internet connectivity
ping 192.168.1.1      # Gateway reachable
nslookup google.com   # DNS working
ipconfig /all         # (Windows) Network config
ifconfig              # (Linux/Mac) Network config

Common issues and fixes:

Problem Solution
Weak signal (-80 dBm) Move closer, add antenna, use extender
Wrong password Check case, special characters
No IP address Check DHCP on router, try static IP
Can’t ping gateway Check subnet, gateway IP
Can’t reach internet Check DNS, firewall
Frequent disconnects Interference, change Wi-Fi channel

Systematic approach:

Device won't connect
  |
Can see Wi-Fi network? -> No -> Physical issue (range, antenna)
  | Yes
Gets IP address? -> No -> DHCP issue, credentials
  | Yes
Can ping gateway? -> No -> Routing, subnet issue
  | Yes
Can ping 8.8.8.8? -> No -> Internet/ISP issue
  | Yes
Can resolve DNS? -> No -> DNS server issue
  | Yes
Application works!

626.4 Summary

This knowledge check covered the essential networking concepts every IoT developer needs:

Key Takeaways:

  • Network Models: OSI provides theoretical framework; TCP/IP is practical implementation
  • IPv6: Essential for IoT’s billions of devices - solves address exhaustion
  • Transport Selection: UDP for low latency/power; TCP for reliability
  • Addressing: MAC for local identification; IP for global routing
  • Topologies: Mesh for reliability and range; Star for simplicity
  • Signal Strength: RSSI above -70 dBm for reliable connections
  • Ports: Use encrypted ports (8883, 5684) in production
  • Troubleshooting: Layer-by-layer approach from Physical to Application

626.5 What’s Next

Continue your assessment journey:

Or explore related topics:

Return to Networking Basics: Assessment Overview for navigation.