18  Hands-On Networking Labs

In 60 Seconds

These hands-on labs teach you to measure the six key network health metrics (bandwidth, throughput, goodput, latency, jitter, packet loss) and to construct protocol data units from scratch—headers, checksums, sequence numbers, and ACK mechanisms. Building and breaking networks in a simulator develops the debugging intuition that separates theoretical knowledge from practical expertise.

MVU — Minimum Viable Understanding

Hands-on networking labs let you build and break things in a simulator so you learn what textbooks cannot teach. The Performance Lab teaches you to measure the six metrics that define network health (bandwidth, throughput, goodput, latency, jitter, packet loss), while the Packet Simulator Lab has you construct protocol data units from scratch—headers, checksums, sequence numbers, and ACK mechanisms—giving you the debugging intuition that separates theory from practice.

Characters: Sammy the Sensor, Lila the LED, Max the Microcontroller, Bella the Battery

Sammy is sending a temperature reading to Max on the other side of the playground. But how do they know the message arrived safely?

“It’s like passing notes in class!” says Lila. “You write the note (that’s the payload), put it in an envelope with a name on it (that’s the header), and wait for a thumbs-up back (that’s the ACK).”

Max explains: “And if I don’t give a thumbs-up? Sammy sends the same note again — that’s called a retransmission!”

Bella adds: “I time how long each note takes. If it usually takes 2 seconds but suddenly takes 10, something is wrong — that’s latency and jitter! I also count how many notes never arrive at all — that’s the packet loss rate.”

Sammy finishes up: “Oh, and we add up all the letters in the note and write the total on the back. If Max adds them up and gets a different number, the note got smudged — that’s a checksum!”

In these labs, you will build your own note-passing system on a simulated ESP32 and measure how well it works — just like the Sensor Squad!

Networking labs are hands-on exercises where you build and test small networking programs instead of just reading about them. Think of it like the difference between reading a recipe and actually cooking a meal.

Why labs matter for IoT:

  • Theory isn’t enough: You can memorize that “TCP uses acknowledgments,” but building an acknowledgment system yourself teaches you why timeouts, retries, and sequence numbers are needed.
  • Debugging is a skill: Real IoT devices lose packets, experience delays, and encounter corrupt data. Labs let you experience and fix these problems in a safe simulator.
  • ESP32 + Wokwi: We use the ESP32 microcontroller (the same chip in many IoT products) inside a free browser-based simulator called Wokwi — no hardware purchase needed.

What you’ll do:

  1. Performance Lab: Measure how fast data travels, how much gets through, and what happens when the network gets busy.
  2. Packet Simulator Lab: Build your own packets with headers, checksums, and sequence numbers — the building blocks of every network protocol.

If you’re new to programming, don’t worry — every lab has complete code you can run first, then modify step by step.

18.1 Learning Objectives

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

  • Build network simulators using ESP32 and Wokwi
  • Measure network performance including latency, throughput, goodput, and packet loss
  • Implement basic packet protocols with sequence numbers and acknowledgments
  • Calculate checksums and verify data integrity at the receiver
  • Distinguish between bandwidth, throughput, and goodput in practical measurements
  • Debug network issues using simulation tools and systematic experimentation

18.2 Overview

These hands-on labs provide practical experience with fundamental networking concepts using the Wokwi ESP32 simulator. Each lab includes circuit diagrams, complete code, and challenge exercises to deepen your understanding.

18.2.1 Lab Workflow

The following diagram shows the typical workflow you will follow in each lab — from understanding the concept, to running the simulation, to analyzing results and tackling challenge exercises.

Lab workflow diagram showing four phases: Concept Review where you study the networking theory, Simulation Setup where you configure the Wokwi ESP32 environment, Run and Observe where you execute experiments and collect measurements, and Analyze and Extend where you interpret results and attempt challenge exercises

18.2.2 Packet Encapsulation Pipeline

Every networking lab involves constructing and interpreting packets. The diagram below shows how raw sensor data is wrapped in protocol layers—each adding its own header—before transmission, and then unwrapped at the receiver.

Packet encapsulation pipeline showing how raw sensor data at the application layer is wrapped by transport, network, and link layers, each adding a header. The complete frame includes a link trailer with CRC for error detection. At the receiver, headers are stripped in reverse order to recover the original sensor data.

In the Packet Simulator Lab, you will implement this pipeline on the ESP32: defining your own header structure, computing checksums over the payload, and adding sequence numbers for reliable delivery.

18.3 Lab Chapters

This module is divided into focused lab chapters:

Lab Description Time Difficulty
Network Performance Measurement Measure bandwidth, throughput, latency, jitter, and congestion using LED indicators ~30 min Intermediate
Packet Simulator Build packets with headers, payloads, and checksums; visualize transmission states ~30 min Intermediate

18.5 Quick Start Guide

18.5.1 Prerequisites

Before starting these labs, ensure you have:

  1. Basic understanding of networking concepts (covered in Networking Basics)
  2. Familiarity with ESP32 and Arduino programming
  3. Access to the Wokwi online simulator (no installation needed)

18.6 Key Concepts Covered

The two labs cover complementary aspects of networking: performance metrics tell you how well the network is behaving, while packet structure determines how data is organized for reliable delivery. Together, they form the foundation for understanding any IoT communication protocol.

Concept relationship diagram showing how Performance Metrics like bandwidth, throughput, latency, jitter, and congestion relate to Packet Structure elements like headers, payloads, checksums, sequence numbers, and ACK/NACK, with arrows indicating that packet structure choices directly affect measured performance

18.6.1 Performance Measurement Lab

Concept Description Why It Matters for IoT
Bandwidth Maximum theoretical data rate (bits/second) Sets the upper bound for how much sensor data you can transmit
Throughput Actual measured data rate achieved Real-world performance is always lower than bandwidth
Latency Time for data to travel source to destination Critical for time-sensitive actuator commands and control loops
Jitter Variation in latency over time High jitter breaks real-time audio/video and PID control
Goodput Application-layer useful data rate After headers and retransmissions, how much useful data gets through
Congestion Network overload causing delays and losses Common in dense IoT deployments with hundreds of sensors

18.6.2 Packet Simulator Lab

Concept Description Why It Matters for IoT
Packet Header Metadata: version, type, length, sequence Every protocol uses headers; understanding them enables debugging
Payload The actual data being transmitted Keeping payloads small saves energy on constrained devices
Checksum Mathematical verification for data integrity Corrupt data leads to wrong sensor readings and bad decisions
ACK/NACK Acknowledgment protocols for reliability Without ACKs, you never know if the gateway received your data
Sequence Numbers Ordering and duplicate detection Essential when packets arrive out of order or are retransmitted

Try It: Goodput Efficiency Calculator

Adjust the payload size and protocol stack to see how packet overhead affects real-world network efficiency.

18.7 Knowledge Check

Test your understanding of the networking lab concepts before diving into the hands-on exercises.

Common Pitfalls

  1. Confusing bandwidth with throughput: Bandwidth is the maximum theoretical capacity of a link (e.g., 250 kbps for IEEE 802.15.4), while throughput is the actual measured data rate, which is always lower due to protocol overhead, retransmissions, and contention. In IoT, real throughput can be as low as 10–30% of bandwidth.

  2. Ignoring protocol overhead in IoT calculations: On constrained networks like LoRaWAN or Zigbee, a 20-byte header on a 50-byte payload means 29% overhead. Many students calculate performance using raw payload size and are surprised when real-world goodput is significantly lower.

  3. Assuming packet loss means hardware failure: In wireless IoT environments, 1–5% packet loss is normal due to interference, multipath fading, and collisions. Your protocols must handle this gracefully with retransmissions and timeouts — don’t debug hardware when the issue is environmental.

  4. Running a single test and drawing conclusions: Network performance varies with time of day, interference, and competing traffic. Always run multiple iterations and compute averages, minimums, maximums, and standard deviations in your lab measurements.

  5. Forgetting byte order (endianness): The ESP32 is a little-endian processor, but most network protocols use big-endian (network byte order). If your multi-byte header fields (e.g., packet length, sequence number) are not converted with htons() / ntohs(), the receiver will interpret completely wrong values. This is the most common “it works on one device but fails between two” bug.

Common Mistake: Treating Goodput = Throughput in Packet Overhead Calculations

The Error: “My sensor sends 1,000 bytes/second of data, so I need 1,000 bytes/second of throughput.”

Why It’s Wrong: Every packet has headers that don’t carry useful application data. The ratio of payload to total packet size determines goodput (useful data rate) vs throughput (total data rate).

Real Measurement from Lab 1 (Performance Lab):

Setup:

  • Application sends: 1,000 bytes/second of sensor readings
  • Transport: TCP
  • Network: IPv4
  • Link: Ethernet

Packet Structure for 100-byte payload:

┌─────────────────────────────────────────┐
│ Ethernet Header: 14 bytes               │
├─────────────────────────────────────────┤
│ IP Header: 20 bytes                     │
├─────────────────────────────────────────┤
│ TCP Header: 20 bytes                    │
├─────────────────────────────────────────┤
│ Application Payload: 100 bytes          │ ← Goodput (useful data)
├─────────────────────────────────────────┤
│ Ethernet Trailer (FCS): 4 bytes         │
└─────────────────────────────────────────┘

Total packet size: 14 + 20 + 20 + 100 + 4 = 158 bytes
Overhead: 58 bytes (37%)
Goodput efficiency: 100/158 = 63%

For 1,000 bytes/second of application data:

Packets needed: 1,000 / 100 = 10 packets/second
Throughput required: 10 × 158 = 1,580 bytes/second
Actual network load: 1,580 × 8 = 12,640 bps (~12.6 Kbps)

But wait—we forgot interframe gaps!

Ethernet requires 12-byte interframe gap (IFG) between packets:

Total per packet: 158 + 12 = 170 bytes
Throughput: 10 × 170 = 1,700 bytes/second = 13.6 Kbps
Overhead: 70% more than payload!

Worst Case: Small Packets

Same 1,000 bytes/second, but as 10-byte payloads (e.g., temperature + humidity):

Packets needed: 1,000 / 10 = 100 packets/second
Per-packet overhead: 14 + 20 + 20 + 10 + 4 + 12 = 80 bytes
Total throughput: 100 × 80 = 8,000 bytes/second = 64 Kbps

Goodput efficiency: 10/80 = 12.5%
Network overhead: 700% more than payload!

Lab Measurement Reality Check:

Performance Lab Experiment:

  1. Send 10,000 bytes application data
  2. Measure throughput with Wireshark
  3. Compare goodput vs throughput

Results:

Payload Size Goodput Measured Throughput Efficiency Overhead (% of payload)
1,000 bytes 10 KB/s 15.8 KB/s 63% 58%
100 bytes 10 KB/s 17 KB/s 59% 70%
10 bytes 10 KB/s 80 KB/s 12.5% 700%

Key Lesson: Smaller packets = worse efficiency.

IoT Protocol Optimization Strategies:

Bad Practice (what beginners do):

// Send temperature reading immediately upon change
void onTemperatureChange(float temp) {
    sendPacket(&temp, sizeof(float));  // 4 bytes payload
    // Results in 4 + 54 overhead = 58 bytes/packet
    // Efficiency: 4/58 = 6.9%
}

Good Practice (aggregate before sending):

#define BATCH_SIZE 25
float readings[BATCH_SIZE];
int readingCount = 0;

void onTemperatureChange(float temp) {
    readings[readingCount++] = temp;

    if (readingCount >= BATCH_SIZE) {
        sendPacket(readings, readingCount * sizeof(float));
        // 100 bytes payload vs 54 overhead
        // Efficiency: 100/154 = 65%
        readingCount = 0;
    }
}

Improvement: 65% / 6.9% = 9.4× better network efficiency by batching.

Real-World Impact on Wireless IoT:

For battery-powered sensor on Wi-Fi: - Radio TX current: 170 mA at 3.3 V - Energy per packet: 0.170 A × 3.3 V × 5 ms = 2.8 mJ

Option A (immediate send, 4-byte packets): - Packets needed for 1,000 bytes: 250 packets - Energy: 250 × 2.8 mJ = 700 mJ

Option B (batched, 100-byte packets): - Packets needed: 10 packets - Energy: 10 × 2.8 mJ = 28 mJ

Battery life impact: 700/28 = 25× longer battery life just by reducing overhead!

Protocol Selection Based on Overhead:

Protocol Header Size Best For Avoid For
TCP/IP 40 bytes Payloads > 100 bytes Tiny sensor readings
UDP/IP 28 bytes Medium payloads Critical reliability
CoAP/UDP 32 bytes IoT constrained devices High-bandwidth
MQTT/TCP 40 + 2-5 Pub/sub messaging Real-time control
6LoWPAN 2-40 (compressed) IEEE 802.15.4 networks High throughput

Rule of Thumb from Lab Experience:

  • Payload > 200 bytes: Overhead < 20% (acceptable)
  • Payload 50-200 bytes: Overhead 20-50% (plan for it)
  • Payload < 50 bytes: Overhead > 50% (aggregate or use efficient protocol)

Bottom Line: Never assume “1 KB application data = 1 KB network bandwidth.” Always calculate total packet size including headers, trailers, and interframe gaps. The Performance Lab makes this visible through measurement.

Try It: Radio Energy vs. Packet Size Calculator

See how batching sensor readings dramatically reduces Wi-Fi radio energy consumption.

For a sensor transmitting 1,000 bytes/second with 10-byte payloads over Ethernet:

Packet structure per 10-byte payload: $ = 14, $ $ = 20, $ $ = 20, $ $ = 10, $ $ = 4, $ $ = 12, $ $ = 14 + 20 + 20 + 10 + 4 + 12 = 80, $

Throughput calculation: $ = = 100, $ $ = 100 = 8{,}000, = 64, $ $ = = 12.5% $ $ = = 700% $

For battery-powered devices at 170 mA TX current and 3.3 V with 5 ms per packet, energy per packet = 0.170 A × 3.3 V × 0.005 s = 2.8 mJ. At 100 packets/s, TX power draw = 100 × 2.8 mJ = 280 mW, giving 0.280 W × 24 h = 6.7 Wh/day of radio transmit energy. With larger 100-byte payloads, only 10 packets/s are needed, reducing TX power to 28 mW and radio energy to 0.67 Wh/day — a 10× radio energy reduction just by batching data before transmission.

18.8 Review Activities

18.8.1 Match the Concept

18.8.2 Order the Steps

18.9 Summary

18.9.1 Key Takeaways

These hands-on labs bridge the gap between networking theory and practical IoT system building:

  • Performance Measurement Lab: You will measure bandwidth, throughput, latency, jitter, goodput, and congestion — the six essential metrics for evaluating any IoT network. Understanding these metrics helps you choose the right protocol and diagnose problems in deployed systems.
  • Packet Simulator Lab: You will construct packets from scratch with headers, payloads, checksums, sequence numbers, and ACK/NACK mechanisms — the fundamental building blocks underlying every networking protocol from MQTT to CoAP to TCP/IP.
  • Practical debugging skills: By running experiments in Wokwi’s ESP32 simulator, you gain experience with the same kinds of problems (packet loss, corruption, delay variation) that real IoT deployments face, but in a safe, reproducible environment.
  • Iterative experimentation: Each lab includes challenge exercises that encourage you to modify parameters (e.g., packet size, error rate, timeout values) and observe the effects — building intuition that cannot be gained from reading alone.
Lab Completion Checklist

Before moving on, ensure you can:

18.10 What’s Next

After completing these labs, the following chapters build directly on the measurement and packet-construction skills you have developed.

Topic Chapter Description
Packet Journey Game networking-fund-game.html Consolidate all networking concepts through an interactive gamified adventure that traces a packet from sensor to cloud
Networking Fundamentals networking-fund-basics.html Review the theoretical foundations — OSI model, IP addressing, and protocol roles — that underpin every lab exercise
Network Topologies network-topologies-intro.html Explore how mesh, star, tree, and hybrid topologies affect the latency and goodput you measured in the Performance Lab
Transport Protocols transport-protocols-overview.html Compare TCP, UDP, and CoAP reliability mechanisms and calculate how ACK overhead affects throughput on constrained IoT links
Application Protocols app-protocols-mqtt.html Apply packet structure knowledge to MQTT framing — inspect CONNECT, PUBLISH, and PUBACK packet headers in detail
Routing and RPL routing-rpl-intro.html Extend your understanding of sequence numbers and acknowledgments to multi-hop mesh routing in large-scale IoT deployments